Token-Kosten explodieren. Nicht weil die Modelle teurer werden – sondern weil KI-Agenten nicht mehr 15 Minuten arbeiten und aufhören. Sie laufen Tage, Wochen, parallel, autonom, über hunderte Context Windows hinweg. Ein einzelner Agent-Lauf verschlingt heute routinemäßig 40.000 Tokens allein durch System-Prompt-Wiederholung. Zehn Loop-Cycles können den 50-fachen Token-Verbrauch eines linearen Durchlaufs verursachen.
Und die wichtigste Erkenntnis ist keine Kostenfrage: Nicht das Modell entscheidet über Erfolg oder Scheitern eines KI-Agenten – sondern die Infrastruktur, die ihn orchestriert.
Jenseits einer Mindest-Fähigkeitsschwelle bringt ein besserer Harness mehr als ein besseres Modell. LangChain steigerte die Trefferquote seines Coding-Agenten von 52,8 % auf 66,5 % – ohne ein einziges Modell-Upgrade. Nur die Umgebung änderte sich.
Technische Führungskräfte (CTOs, Engineering-Leiter:innen), Software-Architekt:innen und TYPO3-Entwickler:innen, die verstehen wollen, warum Harness Engineering der strategische Hebel für produktive KI-Agenten ist – und wie sie ihre Projekte darauf vorbereiten.
Inhaltsverzeichnis
Evolution
Prompt → Context → Harness Engineering
Token-Explosion
Parallele Agents, Tage/Wochen-Laufzeit
Harness Engineering
Anthropics Architektur, 5 Säulen
Plattformen
Factory AI, Paperclip, Agent Teams
Qualitätskriterien
Checkliste, Evaluation, SWE-bench
Forschung & Governance
Stanford, MIT, OpenAI, Deloitte
TYPO3
Content Blocks, Schema API, Projektregeln
Fazit
Drei Takeaways, nächste Schritte
Von Prompt Engineering zu Harness Engineering
Die Art, wie wir mit KI-Modellen arbeiten, hat sich in drei Stufen entwickelt. Jede Stufe reagiert auf die Grenzen der vorherigen:
Prompt Engineering war die erste Disziplin. Wir formulierten Eingaben so geschickt, dass Modelle bessere Ausgaben produzierten – ein einzelner, sorgfältig konstruierter Prompt für eine einzelne Antwort.
Context Engineering löste Prompt Engineering dort ab, wo Systeme in Produktion gingen. Andrej Karpathy vergleicht das Context Window mit dem RAM eines neuen Betriebssystems: Es muss kuratiert werden, nicht nur gefüllt. Tobi Lütke, CEO von Shopify, definierte Context Engineering als „die Kunst, allen Kontext bereitzustellen, damit die Aufgabe plausibel lösbar wird." Der Fokus verschob sich von der einzelnen Anweisung auf das dynamische System, das Instruktionen, Gesprächsverlauf, Tool-Outputs und Gedächtnis zusammenstellt.
Harness Engineering geht noch einen Schritt weiter. Es steuert nicht nur, was im Context Window steht – sondern wie Agenten über viele Context Windows hinweg arbeiten, Zustand bewahren, Fehler beheben und Fortschritt dokumentieren. Ein Harness ist die Infrastruktur, die einen Agenten umgibt: Memory-Systeme, Zustandsverwaltung, Fehlerbehandlung, Tool-Auswahl und Kontext-Management.
| Feature | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| Fokus | Einzelner Prompt | Gesamter Kontext pro Aufruf | Infrastruktur über Sessions |
| Metapher | Einen guten Brief schreiben | RAM des LLM-Betriebssystems kuratieren | Arbeitsumgebung für Schichtarbeiter:innen bauen |
| Zeithorizont | Ein Aufruf | Eine Session | Stunden, Tage, Wochen |
| Kontrolliert | Wortlaut der Anweisung | Was ins Context Window kommt | Memory, State, Tools, Error Recovery |
| Analogie | Gute Frage stellen | Richtigen Kontext bereitstellen | Schichtübergabe organisieren |
Warum Token-Kosten jetzt explodieren
Die erste Generation von KI-Agenten arbeitete in einer einzigen Session: Prompt rein, Antwort raus, fertig. Die aktuelle Generation arbeitet anders. Agents laufen nicht mehr 15 Minuten – sie laufen Tage und Wochen, parallel, über hunderte Context Windows hinweg.
Von Minuten zu Wochen
Claude Code unterstützt asynchrone Background Agents, die im Hintergrund forschen, analysieren und Code generieren, während Entwickler:innen an anderen Aufgaben arbeiten. Mit Agent Teams (experimentell seit Opus 4.6) orchestrieren mehrere Claude-Code-Sessions kollaborativ an einem gemeinsamen Projekt – mit direkter Kommunikation zwischen den Agents.
Warum Tokens eskalieren
KI-Agenten konsumieren 3 bis 10-mal mehr LLM-Aufrufe als einfache Chatbots. Eine einzelne Nutzer:innen-Anfrage löst Planung, Tool-Auswahl, Ausführung und Verifikation aus. Die Kosten eskalieren aus vier Gründen:
System-Prompt-Wiederholung
Der vollständige System-Prompt wird bei jedem API-Aufruf mitgesendet. Ein 10-Schritt-Agent mit 4.000-Token-System-Prompt verbraucht über 40.000 Input-Tokens allein durch Kontext-Akkumulation.
Output-Token-Premium
Output-Tokens kosten 3 bis 8-mal mehr als Input-Tokens. Agents, die ausführliche Chain-of-Thought-Begründungen generieren, zahlen dieses Premium bei jedem Schritt.
Loop-Cycles
Ein Reflexion- oder ReAct-Loop multipliziert den Token-Verbrauch mit jedem Zyklus. Bei identischen Tasks dokumentiert die Forschung bis zu 10-fache Varianz – allein durch unterschiedliche Lösungspfade.
Token-Spiralen
Agenten geben nicht auf, wenn sie stecken bleiben. Sie wiederholen fehlgeschlagene Ansätze mit minimalen Variationen – und jede Iteration kostet erneut volle Input- und Output-Tokens.
Die Zahlen
Die folgende Tabelle fasst aktuelle Kostendaten zusammen:
| Metrik | Wert | Quelle |
|---|---|---|
| Durchschnittliche Kosten Claude Code/Tag | ~$6 pro Entwickler:in | Anthropic |
| 90. Perzentil Claude Code/Tag | <$12 | Anthropic |
| Team-Kosten/Monat (Sonnet 4.6) | $100–200 pro Entwickler:in | Anthropic |
| Token-Varianz bei identischen Tasks | Bis zu 10x | OpenReview |
| Enterprise-Agent-Deployments | $50.000–200.000 p.a. | TechAhead |
Token-Fluss in einem Multi-Agent-Setup: Kosten multiplizieren sich durch Parallelisierung und Loop-Cycles
Was ist Agent Harness Engineering?
Der Begriff Agent Harness beschreibt die Infrastruktur, die einen KI-Agenten umgibt und steuert. Anthropic hat dieses Konzept im November 2025 formalisiert, als das Team feststellte: Selbst Frontier-Modelle wie Opus 4.5 scheitern an komplexen Projekten, wenn man sie ohne Harness in einer Schleife laufen lässt.
Das Kernproblem
Stellen Sie sich ein Softwareprojekt vor, das von Ingenieur:innen in Schichten besetzt wird – und jede neue Person kommt ohne jede Erinnerung an die vorherige Schicht. Genau so arbeiten Agenten über Context Windows hinweg. Ohne Harness treten zwei Fehlermuster auf:
- One-Shot-Versuch: Der Agent versucht, alles auf einmal zu implementieren, läuft aus dem Context Window und hinterlässt halbfertige, undokumentierte Features.
- Vorzeitige Fertigmeldung: Nach einigen Features erklärt der Agent das Projekt für abgeschlossen.
Anthropics Zwei-Komponenten-Lösung
Anthropic löst dies mit einer zweigeteilten Architektur:
Initializer Agent – Session 1
Einmalige Einrichtung: Struktur, Progress-File und erster Commit
Coding Agent – Session N
Wiederholt sich pro Session – ein Feature, ein Commit
Der Initializer Agent setzt in der ersten Session die Umgebung auf: eine umfassende Feature-Liste als JSON (alle Features initial mit "passes": false), ein init.sh-Script zum Starten des Dev-Servers, eine claude-progress.txt für Fortschrittsnotizen und einen initialen Git-Commit.
Jeder Coding Agent beginnt seine Session mit einem festen Protokoll: Progress-File und Git-Logs lesen, Dev-Server starten, grundlegende Funktionalität testen, dann ein einzelnes Feature implementieren und End-to-End verifizieren. Am Ende: Git-Commit mit beschreibender Nachricht und Progress-Update.
Die fünf Säulen eines Harness
External Memory
Informationsspeicher und -abruf jenseits des Context Windows. Feature-Listen, Progress-Files, Git-History – alles, was einem Agent erlaubt, den Zustand des Projekts zu rekonstruieren.
State Management
Fortschritt über Turns, Sessions und Context-Grenzen hinweg persistieren. Ohne State Management beginnt jeder Agent bei null.
Error Recovery
Fehlgeschlagene Tool-Aufrufe abfangen, Retry-Logik implementieren. Git-basierte Rollbacks erlauben dem Agent, fehlerhafte Änderungen rückgängig zu machen.
Tool Selection
Welche Werkzeuge dem Agent zur Verfügung stehen und wie ihre Schnittstellen gestaltet sind. Princeton-Forschung zu Agent-Computer Interfaces zeigt: Jedes Tool sollte genau eine Aktion ausführen.
Context Management
Was ins Context Window kommt und welche Eviction-Strategien gelten. Server-Side Compaction, selektive Kontext-Injektion und inkrementeller Fortschritt statt Überladung.
Plattformen im Überblick
Drei Ansätze zeigen, wie unterschiedlich Multi-Agent-Orchestrierung heute umgesetzt wird.
Factory AI: Agent-Native Softwareentwicklung
Factory AI verfolgt das Konzept Agent-Native Software Development mit spezialisierten Agents namens „Droids": ein Knowledge Droid für technische Recherche und Onboarding, ein Code Droid für merge-fertige Pull Requests, ein Reliability Droid für Incident-Response und Root-Cause-Analysen und ein Product Droid für Feature-Planung und Spezifikationen.
Die Plattform integriert sich in IDEs, Browser, CLI und Slack/Teams. Für Enterprise-Kund:innen bietet Factory SSO, dediziertes Compute und Compliance-Zertifizierungen (SOC II, DSGVO).
Frühe Nutzer:innen berichten von erheblichen Qualitätsproblemen: Code, der Best Practices nicht folgt und manuelle Nacharbeit erfordert. Token-Verbrauch wird als „schwarzes Loch" beschrieben – das gesamte Testguthaben verbraucht für ein einzelnes Feature. Grundlegende Funktionen wie Benutzerauthentifizierung wiesen bei Tests eklatante Fehler auf.
Paperclip: Open-Source für „Zero-Human Companies"
Paperclip verfolgt einen radikal anderen Ansatz: eine Open-Source-Orchestrierungsplattform für vollständig autonom agierende Unternehmen. AI-Agents werden in einer Unternehmenshierarchie organisiert – mit Rollen, Berichtslinien und Jobbeschreibungen.
Das System basiert auf Heartbeats: Agents wachen in definierten Intervallen auf, prüfen ihre Arbeit und handeln. Delegation fließt automatisch entlang des Organigramms. Jeder Agent erhält ein monatliches Budget mit automatischen Spending-Caps. Governance erfolgt über Approval Gates, Budget-Kontrollen und vollständige Audit-Logs.
Mit über 23.500 GitHub Stars, MIT-Lizenz und einem einzigen Node.js-Prozess mit eingebetteter PostgreSQL-Datenbank ist Paperclip bewusst einfach gehalten.
Multi-Agent-Frameworks im Vergleich
Die folgende Tabelle vergleicht die wichtigsten Multi-Agent-Ansätze:
| Merkmal | Factory AI | Paperclip | Claude Code Agent Teams | AutoGen (Microsoft) |
|---|---|---|---|---|
| Ansatz | Spezialisierte Droids | Unternehmens-Hierarchie | Kollaborative Sessions | Multi-Agent-Konversationen |
| Lizenz | Proprietär | MIT (Open Source) | Proprietär | MIT (Open Source) |
| Orchestrierung | Plattform-gesteuert | Heartbeat + Delegation | Shared Task List | Directed Graph |
| Budget-Kontrolle | Token-basiert | Monatliches Agent-Budget | Effort-Parameter pro Subagent | Keine native Kontrolle |
| Reife | Früh (Qualitätskritik) | Früh (aktive Entwicklung) | Experimentell (Opus 4.6) | Stabil (Best Paper ICLR'24) |
| Zielgruppe | Enterprise-Teams | Autonome Unternehmen | Entwickler:innen | Forscher:innen + Entwickler:innen |
Woran erkennt man ein gutes Harness-System?
Ein Harness ist kein Produkt, das man kauft – es ist eine Architektur, die man baut. Die folgenden Kriterien trennen funktionierende Systeme von Token-Verbrennungsmaschinen:
Inkrementeller Fortschritt
Ein Feature pro Session. Der Agent versucht nie, das gesamte Projekt auf einmal zu implementieren. Anthropic nennt dies den entscheidenden Faktor gegen die „One-Shot-Falle".
Clean State nach jeder Session
Am Ende jeder Session ist der Code merge-fähig: keine offenen Bugs, ordentliche Dokumentation, ein beschreibender Git-Commit. Wie Code, den ein:e gute:r Entwickler:in zur Review einreichen würde.
Automatische Verifikation
Ohne explizites Testing markieren Agents Features vorschnell als fertig. Browser-Automation (Puppeteer, Playwright) für End-to-End-Tests ist kritisch – Code-basierte Tests allein reichen nicht.
Strukturierte Progress-Files
Feature-Listen als JSON (schwerer vom Agent zu manipulieren als Markdown), Progress-Notizen und Git-History bilden zusammen das Langzeitgedächtnis über Sessions hinweg.
Token-Budget-Kontrolle
Effort-Parameter pro Subagent (low/medium/high/max), monatliche Spending-Caps und deterministische Token-Budgets verhindern unkontrollierte Kostenexplosionen.
Error Recovery
Git-basierte Rollbacks, Retry-Logik für fehlgeschlagene Tool-Aufrufe und die Fähigkeit, einen kaputten Zustand zu erkennen und zu reparieren, bevor neue Features implementiert werden.
Evaluation: Ergebnisse messen, nicht Pfade
Anthropic empfiehlt in „Demystifying evals for AI agents" einen pragmatischen Start: 20 bis 50 Tasks, abgeleitet aus echten Fehlern, genügen als Grundlage. Die Bewertung folgt drei Säulen nach dem Google-Cloud-Framework:
| Säule | Was wird gemessen? | Methode |
|---|---|---|
| Agent Success & Quality | Task-Completion, Ergebnisqualität | Code-basierte Grader (Unit-Tests), Model-basierte Grader (LLM-Judges) |
| Process & Trajectory | Reasoning-Logik, Tool-Auswahl | Pfadanalyse, aber: valide Ergebnisse über unerwartete Wege akzeptieren |
| Trust & Safety | Zuverlässigkeit unter nicht-idealen Bedingungen | Edge-Case-Testing, Fehlerinjektionen |
Frontier-Modelle finden oft valide Lösungswege, die Designer:innen nicht vorhergesehen haben. Messen Sie, was der Agent produziert – nicht wie er dorthin kommt. Auf SWE-bench Verified verbesserten sich die besten Agents von 4,4 % auf über 71,7 % Genauigkeit in nur einem Jahr.
Microsofts AXIS-Framework (ACL 2025) zeigt einen weiteren Hebel: API-first Agent-Computer Interfaces statt UI-basierter Interaktion reduzieren die Task-Completion-Zeit um 65 bis 70 % und den kognitiven Overhead um 38 bis 53 %.
Forschung und Governance
Die Forschungslage zeigt ein klares Bild: KI-Agenten werden rapide leistungsfähiger, aber die Governance hinkt hinterher.
Der SWE-bench-Sprung
Stanford HAIs AI Index Report 2025 dokumentiert eine der schnellsten Leistungssteigerungen in der KI-Geschichte: Auf dem SWE-bench-Benchmark für Software-Engineering lösten AI-Systeme 2023 noch 4,4 % der Coding-Probleme – 2024 waren es 71,7 %. Ein Sprung von 48,9 Prozentpunkten in zwölf Monaten.
Enterprise-Adoption vs. Governance-Lücke
Die Kluft zwischen Adoption und Governance ist erheblich:
| Kennzahl | Wert | Quelle |
|---|---|---|
| Corporate AI-Adoption | 78 % (2024, vs. 55 % in 2023) | Stanford HAI |
| Unternehmen mit AI-Agent-Experimenten | 62 % | Deloitte 2026 |
| Unternehmen mit reifer Agent-Governance | Nur 20 % | Deloitte 2026 |
| Unternehmen mit messbarem Bottom-Line-Impact | ~20 % | McKinsey 2025 |
| Organisationen, die Workflows um KI redesignen | 34 % | Deloitte 2026 |
McKinsey bringt das Paradox auf den Punkt: Fast acht von zehn Unternehmen nutzen generative KI, aber ebenso viele berichten von keinem signifikanten Einfluss auf den Unternehmenserfolg. Der Grund: Die meisten Deployments bleiben oberflächlich – Assistenz-Tools statt tief integrierter Agenten.
OpenAIs Governance-Framework
OpenAI hat im Dezember 2023 sieben Praktiken für die Steuerung agentischer Systeme vorgeschlagen – ein Framework, das für jeden Harness-Entwurf relevant ist:
- Klare Verantwortungszuweisung – Menschen haften für direkte Schäden
- Action Ledgers – Transparenz über Agent-Operationen
- Human Approval Gates – Menschliche Review bei kritischen Entscheidungen
- Capability Boundaries – Definierte Grenzen für System-Impact
- Staged Deployment – Schrittweiser Rollout mit Monitoring
- Reversibility Design – Aktionen wo möglich reversibel gestalten
- Shutdown Capabilities – Zuverlässige Mechanismen zum Anhalten
Koordination auf Populationsebene
MITs Ripple Effect Protocol (REP) adressiert ein Problem jenseits einzelner Agents: die Koordination ganzer Agent-Populationen. Statt vollständiger Informationen tauschen Agents leichtgewichtige „Sensitivitäten" aus – Signale, die beschreiben, wie sich Entscheidungen bei Umgebungsänderungen verschieben würden. Das Ergebnis: 41 bis 100 % bessere Koordination in Supply-Chain-, Präferenz- und Ressourcen-Szenarien.
TYPO3-Projekte harness-optimieren
Harness Engineering wirkt nicht nur bei Greenfield-Projekten. Bestehende TYPO3-Codebasen können gezielt vorbereitet werden, damit KI-Agenten mit weniger Kontext präziser arbeiten. Der vollständige Deep-Dive mit Code-Beispielen findet sich in unserem dedizierten Artikel.
Die stärksten Hebel im Überblick:
| Hebel | Ersetzt | KI-Gewinn |
|---|---|---|
| Content Blocks | TCA-Streuung über 4+ Dateien | Eine YAML-Datei statt vier – TCA, SQL und Formulare werden generiert |
| PHP 8.4 Property Hooks | Getter/Setter-Serien | ~85 % weniger Boilerplate pro Property |
| DataHandler als Schreibpfad | Direkte SQL-Updates | Workspaces, Berechtigungen und FAL-Relationen korrekt verarbeitet |
| Schema API (v13.2+) | $GLOBALS['TCA']-Array-Zugriffe | Typisiertes OOP statt Array-Navigation |
| .cursorrules / AGENTS.md | Implizites Teamwissen | Persistente Projektregeln reduzieren Varianz zwischen Sessions |
| PHPStan + CI-Gates | Manuelle Code-Reviews | Mechanische Absicherung für Agent-generierten Code |
TYPO3 KI-fit machen
Was der TYPO3-Core bereits für KI-Lesbarkeit tut – und was Sie in Ihrem Projekt ergänzen sollten. Mit Schema API, Content Blocks, Property Hooks, DataHandler und Harness Engineering.
Fazit
Harness Engineering ist kein Buzzword und kein optionales Feature. Es ist die Disziplin, die darüber entscheidet, ob KI-Agenten produktiv arbeiten oder Tokens verbrennen.
Nicht die Teams mit den meisten Entwickler:innen gewinnen 2026 – sondern die, deren Harness-Architektur KI-Agenten zuverlässig orchestriert.
Wenn Sie Ihre bestehende Codebasis darauf prüfen wollen, wo KI-Agenten heute noch gebremst werden, ist ein fokussierter Architektur-Review der schnellste Startpunkt.