Das KI-Harness hat zehn Komponenten, nicht sieben

Tomasz Tunguz hat gestern Software After AI / Harnessing AI veröffentlicht. Es ist die sauberste Einzelseiten-Architekturzerlegung dessen, was Produktions-KI-Systeme tatsächlich brauchen, die ich dieses Jahr gelesen habe. Sein Kernargument landet in einer Zeile:

Wie ein Mustang ist KI mächtig, aber wild. Was passiert, wenn jedes Unternehmen Zugang zum gleichen Modell hat? Die besten Reiter gewinnen.

Das stimmt, und Tunguz legt sieben Komponenten dar, die ein ernstzunehmendes KI-Harness braucht, um den Reitwettbewerb zu gewinnen. Lies sein Stück. Es sind zwölf Minuten und sollte Pflichtlektüre für jeden CPTO und Head of Engineering sein, der seine Architektur für 2027 plant.

Hier ist der Teil, den ich hinzufügen möchte. Die sieben Komponenten, die Tunguz beschreibt, sind das technische Harness. Sie sind das, was ein Engineer bauen muss. Sie sind, für sich allein, nicht das, was das Harness im Markt gewinnen lässt. Dieselben sieben Komponenten, in derselben Qualität gebaut, werden je nach drei Schichten, die Tunguz untergewichtet oder gar nicht behandelt, dramatisch unterschiedliche Ergebnisse produzieren: die menschliche Leadership-Schicht, die Kundenengagement-Schicht und die Geschäftsmodell-Schicht.

Ich habe in dem Empowerment-Stück, dem Vibe-Coding-Stück, dem GitLab-Act-2-Stück und dem Forward-Deployed-AI-Engineers-Stück auf dieses Argument hingearbeitet. Dieser Artikel verbindet sie mit Tunguz’ Framework und schlägt die vollständige Gestalt vor: Das KI-Harness hat zehn Komponenten, nicht sieben.

Die sieben, die Tunguz benennt

Kurz, damit du folgen kannst, ohne diese Seite zu verlassen. Tunguz’ Framework, mit meinem Einzeiler-Kommentar zu jedem:

#	Komponente	Was es ist	Warum es zählt
1	Kontext & Speicher (Context & Memory)	Custom Retrieval, Kurzzeitgedächtnis, SOP-Datenbanken, die sich mit der Organisation weiterentwickeln	Entscheidet, ob der Agent weiß, was dein Business unter “Vertrag” oder “Incident” versteht
2	Werkzeuge & Aktion (Tools & Action)	Über Registry exponierte Tools, validierte Argumente, Freigabe-Gates, MCP als Bindegewebe	Entscheidet, was der Agent tatsächlich sicher tun kann
3	Orchestrierung & Loop (Orchestration & Loop)	Think-Act-Observe-Zyklen, Sub-Agenten, Planung, Retries, Stop-Bedingungen	Entscheidet, wie der Agent sich von eigenen Fehlern erholt
4	Zustand & Persistenz (State & Persistence)	Checkpoints, Filesysteme, Session-Threads, Artefakt-Speicherung	Entscheidet, ob eine mehrstufige Aufgabe wieder aufgenommen oder neu gestartet wird
5	Sandbox & Compute (Sandbox & Compute)	Isolierte Unix-Workspaces, kontrollierter Egress, Credential-Management	Entscheidet, ob der Agent sicher auf Produktionsdaten laufen darf
6	Observability & Governance (Observability & Governance)	Tracing, Logs, Evals-als-Regressionstests, Human-in-the-Loop	Entscheidet, ob du das System debuggen, ihm vertrauen und es verbessern kannst
7	Kosten- & Workflow-Optimierung (Cost & Workflow Optimisation)	Deterministisches vs. nicht-deterministisches Routing, Modellauswahl	Entscheidet die Stückkosten-Ökonomie jedes Agentenlaufs

Das ist ein straffer, meinungsstarker Stack. Jede dieser Komponenten ist nicht verhandelbar. Lass eine weg, und das Harness hat ein Loch, das unter Produktionslast einen Stressbruch produzieren wird. Wenn du KI-Agenten baust und keine klare architektonische Antwort auf jede dieser sieben hast, ist dein Harness unvollständig.

Aber hier ist die Sache: Wenn jeder ernstzunehmende Anbieter diese sieben baut, ist das Differenzierungsproblem nicht gelöst. Es ist verschoben. “Die besten Reiter gewinnen” ist die richtige Rahmung, aber Tunguz’ Framework sagt dir nur, wie Sattel und Zaumzeug aussehen. Es sagt dir nichts über den Reiter, die Beziehung zum Pferd oder das Preisgeld.

Die drei Schichten, die Tunguz auslässt

8. Leadership und Empowerment

Tunguz’ Framework ist engineering-zentriert: Es beschreibt, was das System braucht. Es schweigt darüber, wer das System betreibt, wie diese Menschen organisiert sind und welche Kultur sie in den Betrieb mitbringen. Das ist eine tragende Auslassung, weil dasselbe Harness je nach dem Team, das es bedient, dramatisch unterschiedliche Ergebnisse produziert.

Ich habe dieses Argument vollständig in Leading AI Is an Empowerment Problem ausgearbeitet, die Kurzfassung ist also diese. Kief Morris’ On-the-Loop-Position - das Harness zu bauen und zu verbessern, statt jedes Artefakt zu inspizieren - ist genau das, was Marty Cagan seit zwanzig Jahren Empowered Product Teams nennt, und genau das, was Reed Hastings bei Netflix Context not Control nennt. Das Harness ist das technische Artefakt. Die Art, wie Menschen sich dazu verhalten, ist das kulturelle Artefakt. Du brauchst beides.

Konkret muss die Leadership-Schicht des Harness abdecken:

Talent Density. Tunguz’ Observability & Governance-Komponente ist nur nützlich, wenn am anderen Ende der Alarme Menschen sitzen, die darauf reagieren können. Empowered Teams mit hoher Talent Density werden das Harness über die Zeit straffen. Feature-Teams werden auf Alarme reagieren und Pflaster shippen. Gleiche Observability, unterschiedliche Evolutionen.
Empowered Ownership. Jede Komponente des Harness braucht einen Owner mit der Autonomie, sie zu verbessern. Kontext & Speicher ohne Owner wird abgestanden. Werkzeuge & Aktion ohne Owner akkumuliert tote und doppelte Tools. Orchestrierung & Loop ohne Owner wird nicht mehr hinterfragt. Das agentische Schwungrad, das Tunguz’ Framework ermöglicht, dreht sich nur, wenn jemand das Drehen besitzt.
Anti-Rationalisierungs-Disziplin. Anthropics Open-Source-Agent-Skills-Framework ist in dieser Sicht ein Harness für die Menschen, die Harnesses bauen. Jede Skill hat einen expliziten Rationalisations-Abschnitt, der die Ausreden vorwegnimmt, die ein Agent oder ein müder Engineer erfinden wird, um den richtigen Prozess zu überspringen. Ohne diese Disziplin in der Art, wie das Team arbeitet, verankert, wird dein Harness über die Zeit leise herabgestuft, und du merkst es erst, wenn die Produktion bricht.

Der mechanische Test ist dieser: Stell dir vor, du tauschst das Engineering-Team, das dein Harness betreibt, von deiner aktuellen Organisation gegen eine Feature-Team-Organisation aus einer Fortune-500-Bürokratie aus, produziert das Harness die gleichen Ergebnisse? Natürlich nicht. Das Harness ist notwendig; das Team, das es betreibt, ist die Variable, die entscheidet, ob du gewinnst. Tunguz’ Framework behandelt das als außerhalb des Scope. Ist es nicht.

9. Kundenengagement und Pattern Promotion

Tunguz’ Framework nimmt implizit an, dass das Harness einmal in eine einzige Umgebung deployed wird. Diese Annahme bricht in dem Moment, in dem du KI-gestützte Software an Enterprises verkaufst. Das Harness muss gegen die Realität des Kunden betrieben werden, nicht gegen deine, und die Architektur muss dafür sorgen, dass dieses Engagement zurück in den Plattformwert kompoundiert, statt in maßgeschneidertem Services-Umsatz zu verschwinden.

Ich habe dieses Argument ausführlich in SaaS ist nicht tot - es nimmt Forward Deployed AI Engineers an Bord gemacht. Das Palantir-Modell ist der Beweis: Forward Deployed Engineers in die Kundenumgebung eingebettet, die das Harness gegen die Daten, Prozesse und Menschen des Kunden bauen, mit einem expliziten wöchentlichen Promotion-Forum, das maßgeschneiderte Patterns zurück in die Plattform zieht. Der Grund, warum Palantir 139% Net Dollar Retention hat und nicht die üblichen SaaS-flachen 110%, ist, dass diese Schicht auf eine Weise kompoundiert, wie es ein installierbares Produkt niemals tut.

Konkret deckt die Kundenengagement-Schicht des Harness ab:

Forward Deployed AI Engineering als Funktion, nicht als abrechenbare Beratung. Senior Engineers plus Agenten, bei Kunden eingebettet, innerhalb des Plattformvertrags bezahlt. Die Ökonomie funktioniert, weil Agenten die Kosten von Services kollabieren lassen; ohne das schaffst du erneut einen Services-Arm mit 30% Bruttomarge, und die Plattform verliert den Fokus.
Pattern-Promotion-Foren. Wöchentliche Kadenz, keine Ausnahmen, drei Fragen: Was haben die FDEs diese Woche gebaut, welche Patterns werden bei den nächsten fünf Kunden auftauchen, wer besitzt das Promoten dieser in die Plattform? Das ist das agentische Schwungrad, das Tunguz’ Framework ermöglicht, angewandt auf Anbieter-Kunden-Engagements statt auf interne Loops.
Kundenseitige Ontology. Tunguz’ Kontext & Speicher-Komponente spricht über Retrieval und SOPs im Abstrakten. In Wirklichkeit ist der wertvollste Kontext das semantische, ausführbare Modell des spezifischen Geschäfts des Kunden - was Palantir die Ontology nennt. Das FDE-Engagement ist, wie das gebaut wird. Ohne die Engagement-Schicht ist deine Kontext & Speicher-Komponente generisch, und die deines Wettbewerbers ist maßgeschneidert und kompoundierend.

Der ehrliche Test, ob dein Harness diese Schicht hat: Wenn ein Kunde unterschreibt, produziert das Harness Wert in Tagen oder in Monaten? Out-of-the-Box-Produkte produzieren Wert in Monaten. FDE-ausgestattete Harnesses produzieren Wert in Tagen. Der Markt wird die zweite Form für die nächsten fünf Jahre hart belohnen.

10. Geschäftsmodell und kompoundierende Wertschöpfung

Tunguz’ siebte Komponente ist Kosten- & Workflow-Optimierung. Das ist eine Stückkosten-Sicht: günstige Modelle für einfache Arbeit, teure Modelle für schwere Arbeit. Sie ist korrekt und notwendig, und sie ist auch nicht das gesamte Geschäftsmodell-Bild. Das Geschäftsmodell muss zur Architektur passen, und Tunguz’ Framework schweigt zur Pricing-Seite.

Die Architektur eines agentischen Harness hat zwei deutlich unterschiedliche ökonomische Regimes:

Die Plattform selbst ist Software mit hohen Fixkosten und niedrigen Grenzkosten. Die Ökonomie ist reines SaaS. Subscriptions sind das richtige Pricing-Primitiv für diese Schicht.
Die Agentenarbeit, die das Harness ausführt, ist variabel-kostenintensive, wertgebundene Compute. Kunden wollen proportional zur geleisteten Arbeit bezahlen, besonders wenn Agenten Aufgaben übernehmen, die früher Headcount erforderten. Consumption ist das richtige Pricing-Primitiv für diese Schicht.

Ein reines Subscription-Geschäftsmodell monetarisiert hochvolumige Agenten-Kunden zu wenig und überfordert geringvolumige. Ein reines Consumption-Modell bestraft Kunden dafür, sich auf die Plattform zu verlassen, und erzeugt schreckliche Umsatz-Vorhersagbarkeit. GitLabs Act-2-Brief ruft genau diesen Hybrid explizit als Überzeugung 9 ihrer Forward-Strategie aus: Subscriptions für das, was Kunden heute haben, Consumption Pricing für die Arbeit, die Agenten leisten, mit mehr Flexibilität zur Vermischung, wenn sich die Art der Arbeit weiterentwickelt. Palantir tut operativ dasselbe. Das ist keine Marketing-Entscheidung; es ist eine architektonische Entscheidung, und sie gehört in das Harness-Framework.

Konkret deckt die Geschäftsmodell-Schicht ab:

Hybrid-Pricing. Subscription für stabilen Plattformwert, Consumption für Agent-Rate-Arbeit, mit einem klaren Pfad von einem zum anderen, sodass Kunden wachsen können, ohne neu zu verhandeln.
Engagement in Plattformverträge eingebettet. Das FDE-Engagement aus der Kundenengagement-Schicht kann nicht als separater SOW verkauft werden, sonst stirbt der Plattform-Feedback-Loop. Backe es in das Plattform-Pricing ein.
OKRs, die Agenten-Metriken mit Geschäftsergebnissen verbinden. Tunguz’ Observability-Komponente liefert dir die Daten. Die Geschäftsmodell-Schicht macht aus diesen Daten das Betriebssystem des Unternehmens. Die Agent-Erfolgsrate pro Workflow muss neben den Produkt-Northstar-Metriken und dem Umsatz stehen, sonst ist das Harness für die Menschen unsichtbar, die entscheiden, wo investiert wird.

Der Test für diese Schicht: Kannst du das Harness wachsen lassen und die Ausgaben des Kunden proportional wachsen lassen, ohne Verhandlungsreibung? Wenn ja, ist dein Geschäftsmodell harness-bewusst. Wenn Renewals einem Zahnziehen gleichen und Expansions frische Beschaffungszyklen erfordern, sind Modell und Architektur nicht aufeinander abgestimmt.

Das Zehn-Komponenten-Harness

Alles zusammen:

Schicht	#	Komponente
Technisch (Tunguz)	1	Kontext & Speicher
	2	Werkzeuge & Aktion
	3	Orchestrierung & Loop
	4	Zustand & Persistenz
	5	Sandbox & Compute
	6	Observability & Governance
	7	Kosten- & Workflow-Optimierung
Mensch / Leadership	8	Leadership und Empowerment
Go-to-Market / Implementierung	9	Kundenengagement und Pattern Promotion
Strategie / Wertschöpfung	10	Geschäftsmodell und kompoundierende Wertschöpfung

Das ist die volle Gestalt. Tunguz hat die technische Architekturhälfte geschrieben. Die anderen drei Komponenten sind das, was ein technisches Harness in ein Business verwandelt, das gewinnt.

Jede davon mappt absichtlich auf eines meiner jüngeren Stücke:

Komponenten 1-7 ⇄ Drei-Schichten-KI-Architektur und Das Skills Framework auf Implementierungsebene.
Komponente 8 ⇄ Leading AI Is an Empowerment Problem und Vibe Coding in Prod Is a Management Problem.
Komponente 9 ⇄ Forward Deployed AI Engineers.
Komponente 10 ⇄ GitLabs Act 2 - Der agentische Umbau wird öffentlich.

Wenn du das Zehn-Komponenten-Harness in 2026-27 operationalisieren willst, sind diese fünf Artikel das operative Playbook, und Tunguz’ Stück ist die architektonische Blaupause darunter.

Wo Tunguz definitiv richtig liegt

Ich will klar sein, dass dieser Artikel Erweiterung ist, nicht Widerlegung. Tunguz’ Framework ist das nützlichste Einzel-Artefakt, das ich dieses Jahr für Engineers gesehen habe, die KI-Systeme planen. Konkret:

Die Rahmung der Harness-Ära ist genau richtig. Der Übergang von “Software mit festen Workflows” zu “KI innerhalb eines Harness” ist gerade die dominante Story in Enterprise-Software, und die Harness-Ära zu benennen ist das richtige Vokabular.
Die sieben Komponenten sind die richtigen sieben. Ich würde keine davon abziehen. Versuche es ohne Zustand & Persistenz und deine mehrstufigen Aufgaben fallen im Maßstab auseinander. Versuche es ohne Sandbox & Compute und du fängst dir in den ersten sechs Produktionsmonaten einen Sicherheitsvorfall ein.
Das Wettbewerbsvorteil-Argument ist korrekt. Wenn Modelle commoditisieren, gewinnen die Reiter. Er trifft das auf den Punkt. Jeder, der sein Stück liest, sollte das verinnerlichen.

Was ich argumentiere, ist, dass die sieben Komponenten notwendig und nicht hinreichend sind. Sobald jeder ernstzunehmende Anbieter dieselben sieben baut, kommt die Differenzierung, die entscheidet, wer den Reiterwettbewerb tatsächlich gewinnt, von den drei Komponenten, die Tunguz untergewichtet. Baue die sieben. Dann baue die nächsten drei.

Ein Neunzig-Tage-Audit mit den zehn Komponenten

Das Nützlichste, was ein CPTO, VP Eng oder Founder, der ein agentisches Produkt führt, dieses Quartal tun kann, ist ein Zehn-Komponenten-Audit gegen die eigene Organisation. Die Form, die in Gesprächen mit Führungskräften, die diese Übung durchlaufen, gut funktioniert hat:

Tage 0-30: Bewerte jede Komponente ehrlich. Gehe alle zehn durch, bewerte jede auf einer Fünferskala, und untermauere die Bewertung mit konkreten Belegen (ein Deploy, ein Kundenergebnis, ein Postmortem). Ziel ist brutale Kalibrierung. Wenn drei deiner Bewertungen bei 4 oder 5 landen, bewertest du dich wahrscheinlich zu freundlich. Die meisten gut geführten Engineering-Organisationen, die diese Übung nicht gemacht haben, werden in mindestens drei der zehn bei 2 oder darunter landen.
Tage 30-60: Investiere in die untersten zwei. Für die meisten Organisationen sind die untersten zwei vorhersehbar. Observability & Governance (Komponente 6) landet niedrig, weil niemand die unglanzvolle Tracing- und Eval-Arbeit machen will. Kundenengagement und Pattern Promotion (Komponente 9) landet niedrig, weil der FDE-style-Move für Boards, die mit reiner SaaS-Ökonomie aufgewachsen sind, kulturell schwer ist. Beide sind genau dort, wo der Hebel versteckt liegt. Wähle die untersten zwei auf deinem Scorecard und investiere dort, bevor du irgendetwas anderes anrührst.
Tage 60-90: Verbinde das Harness mit Geschäftsergebnissen. Verknüpfe die Daten aus den Komponenten 6 und 7 direkt mit den OKRs deines Unternehmens (Komponente 10), und richte das erste wöchentliche Pattern-Promotion-Forum (Komponente 9) ein, sodass das Lernen aus dem Kundenengagement zurück in die Plattform fließt. Die Kadenz früh zu etablieren ist das, was sechs Monate später den Unterschied zwischen einem Schwungrad und einem statischen Produkt ausmacht.

Ein einfacher Test, ob das Audit funktioniert hat: Am Ende von neunzig Tagen solltest du auf jede der zehn Komponenten zeigen können und (a) die Person nennen können, die sie besitzt, (b) den Wert, auf dem sie war, und (c) den Wert, auf dem sie jetzt ist. Wenn diese drei Spalten für jede Zeile gefüllt sind, betreibst du das Zehn-Komponenten-Harness, statt darüber zu lesen. Die sieben, die Tunguz benennt, trackst du vielleicht schon. Die anderen drei sind dort, wo der Hebel versteckt liegt.

Das Fazit

Tunguz hat das richtige Framework im richtigen Moment veröffentlicht. “Die besten Reiter gewinnen” wird die Zeile sein, die jeder im nächsten Jahr zitiert, und die sieben Komponenten sind die richtige Startarchitektur für jedes ernstzunehmende KI-Produktteam in 2026-27.

Das Stück, das meiner Meinung nach fehlt - und das Stück, an dem ich in den letzten sechs Monaten auf dieser Seite gearbeitet habe - ist, dass das technische Harness notwendig und nicht hinreichend ist. Die Teams, die die Harness-Ära gewinnen, werden diejenigen sein, die die menschliche Leadership-Schicht, die Kundenengagement-Schicht und die Geschäftsmodell-Schicht als First-Class-Komponenten desselben Systems behandeln. Baue die sieben, dann baue die nächsten drei. Der Hebel kompoundiert über alle zehn hinweg.

Wenn du Tunguz’ Stück diese Woche liest, paare es mit den fünf Artikeln, die ich oben verlinkt habe. Zusammen sind sie das operative Playbook für die nächsten vierundzwanzig Monate Enterprise-KI. Die Reiter, die alle zehn Komponenten verinnerlichen, nicht nur sieben, sind diejenigen, die das Rennen beenden werden.

Referenzen

Software After AI / Harnessing AI - Tomasz Tunguz - Das Sieben-Komponenten-Framework, das dieses Stück erweitert
Leading AI Is an Empowerment Problem - Die menschliche Leadership-Schicht (Komponente 8)
Vibe Coding in Prod Is a Management Problem - Das Individual-Contributor-Pendant zu Komponente 8
Forward Deployed AI Engineers - Die Kundenengagement-Schicht (Komponente 9)
GitLabs Act 2 - Der agentische Umbau wird öffentlich - Die Geschäftsmodell-Schicht (Komponente 10)
Das Skills Framework - Prozedurale Disziplin innerhalb des technischen Harness
Drei-Schichten-KI-Architektur - Architekturpattern auf Implementierungsebene
The Last Bottleneck - Warum das jetzt zählt