Abstrakte Visualisierung eines Agent-Harness: drei konzentrische Ringe vernetzter Knotenpunkte um einen zentralen Modellkern

Agentic Harness Engineering: Das Framework für zuverlässige KI-Agenten

Warum die Zuverlässigkeitslücke Ihrer KI-Agenten kein Modell-, sondern ein Harness-Problem ist

Zwischen einem überzeugenden Demo-Agenten und einem Produktiv-Agenten, dem man trauen kann, liegt eine Disziplin: Agentic Harness Engineering. Der Harness — die Tool-Registry, Sandbox, Memory, Sub-Agenten, Hooks, Observability und Eval-Schleife rund um das Modell — entscheidet darüber, ob Ihr Agent zuverlässig liefert, überhaupt anhaltbar ist und die Hochrisiko-Pflichten des EU AI Acts ab 2. August 2026 erfüllt. Diese Seite zeigt, was ein Harness ist, wie er aufgebaut wird und welche Muster sich 2026 durchgesetzt haben.

Zusammenfassung
  • Agent = Modell + Harness. Wer nicht das Modell ist, ist der Harness — und ein gutes Harness mit einem soliden Modell schlägt ein großartiges Modell mit einem schlechten Harness.
  • Die Zuverlässigkeitslücke ist eine Harness-Lücke. Anthropic und OpenAI berichten beide: bessere Infrastruktur lieferte mehr Wert als bessere Modelle.
  • Zehn Komponenten bilden den Konsens-Stack: System-Prompt, Tool-Registry, Sandbox, Permission-Modell, Memory, Context Management, Sub-Agenten, Hooks, Observability, Evals.
  • Planner / Generator / Evaluator ist das dominante Muster: Trennung von Planung, Ausführung und Bewertung beseitigt Self-Grading-Bias.
  • EU AI Act Hochrisiko-Pflichten ab 2. August 2026 — Artikel 9–15 verlangen genau die Artefakte, die ein Harness produziert.
  • Zielgruppe: CTOs, Platform-Engineering-Leads, KI-Verantwortliche im Mittelstand und in regulierten Branchen.
1 Mio. LoC in 5 Monaten von 3 Engineers (OpenAI Codex)
58 % → 37 % Überwacht vs. tatsächlich stoppbar
2. Aug. 2026 Hochrisiko-Pflichten EU AI Act

Was ist ein Harness?

Ein Harness ist die strukturierte Laufzeitumgebung, die ein Sprachmodell erst zu einem Agenten macht. Das Modell würfelt Token; der Harness entscheidet, welche Werkzeuge das Modell sehen darf, welche Aktionen es ausführen darf, was es sich merken soll, wann es einen Sub-Agenten ruft, wie sein Output geprüft wird und was passiert, wenn etwas schiefgeht. Die in der Branche geprägte Kurzformel:

„Agent = Modell + Harness. Wer nicht das Modell ist, ist der Harness. Ein solides Modell mit einem großartigen Harness schlägt ein großartiges Modell mit einem schlechten Harness.“

Phil Schmid bietet eine eingängige Analogie: das Modell ist die CPU, der Kontext ist der Arbeitsspeicher, der Harness ist das Betriebssystem — und der Agent ist die Anwendung, die auf alledem läuft. Ohne OS keine Anwendung, egal wie schnell die CPU ist.

Abgrenzung zu verwandten Disziplinen

  • Prompt Engineering formt einen einzelnen Eingabestring für einen einzelnen Modellaufruf.
  • Context Engineering entscheidet, welche Information überhaupt in den Kontext kommt — Retrieval, Komprimierung, Skills, Just-in-Time-Loading.
  • Agent-Frameworks wie LangChain, AutoGen, CrewAI sind Bibliotheken: Bausteine, die Sie zu einem Harness komponieren.
  • Harness Engineering ist die System-Engineering-Disziplin darüber: Entwurf, Instrumentierung, Absicherung und Evaluierung der gesamten Laufzeit, die ein Modell zu einem verlässlichen Mitarbeiter macht. Prompt- und Context-Engineering sind Teildisziplinen innerhalb des Harnesses.

Der Begriff selbst kristallisierte sich zwischen November 2025 und April 2026 heraus. Anthropic publizierte zwei einschlägige Engineering-Posts („Effective harnesses for long-running agents“ und „Harness design for long-running application development“), OpenAI veröffentlichte „Harness engineering: leveraging Codex in an agent-first world“, und Birgitta Böckeler (Thoughtworks) konsolidierte die Diskussion auf martinfowler.com. Die erste begutachtete Arbeit, die den Begriff als Forschungsfeld führt — Lin et al., „Agentic Harness Engineering“ (arXiv:2604.25850) — zeigt, dass sich Harness-Komponenten mittlerweile sogar selbst weiterentwickeln lassen.

Die Anatomie eines Harness

Wer die Engineering-Posts von Anthropic, OpenAI, LangChain und Thoughtworks nebeneinanderlegt, sieht denselben Stack auftauchen. Zehn Komponenten haben sich als Standard etabliert — die Wahl, wie Sie sie ausgestalten, ist Ihr Wettbewerbsvorteil.

1. System-Prompt & Skills

Der einzige Text, den jeder Aufruf sieht. Jede Zeile sollte auf einen vergangenen Fehlschlag zurückführbar sein (Addy Osmanis „Ratchet Principle“); spekulative Regeln sind Rauschen, das die Aufmerksamkeit fragmentiert. Skills mit progressiver Offenlegung erweitern den Prompt nur dann, wenn sie gebraucht werden.

2. Tool-Registry

Welche Werkzeuge bekommt der Agent überhaupt zu sehen? MCP-Server, Datei-Operationen, Suche, Code-Ausführung, Sub-Agent-Spawn. Die Faustregel der Praxis: „Zehn fokussierte Werkzeuge schlagen fünfzig überlappende.“ Überladene Tool-Menüs sind eine der häufigsten Ursachen für unzuverlässige Agenten.

3. Sandbox & Execution

Die Ausführungsumgebung — Container, Browser, isoliertes Dateisystem. Sie begrenzt den Blast Radius einer fehlgesteuerten Aktion. Eine produktive Sandbox erlaubt schnelles Iterieren und macht Rollback billig; ohne sie ist jeder Tool-Call ein Risiko.

4. Permission-Modell

Welche Aktionen darf der Agent autonom ausführen, welche brauchen menschliche Bestätigung, welche sind verboten? Least-Privilege, Allow-/Deny-Listen, Kill-Switch und Human-in-the-Loop-Checkpoints. Dies ist die Komponente, an der Artikel 14 EU AI Act („Menschliche Aufsicht“) konkret wird.

5. Memory & State

Kurzzeitiger Scratchpad (z. B. claude-progress.txt), langfristiger Speicher, und vor allem: Git-Commits als Checkpoints. Anthropic empfiehlt Git nicht aus Tradition, sondern weil es ein geprüfter, durable Recovery-Mechanismus ist, der ohne neue Infrastruktur funktioniert.

6. Context Management

Kontextfenster sind eine Ressource, kein Feature. Komprimierung (Compaction), Reset mit Handoff-Artefakt, Skills mit progressiver Offenlegung und Just-in-Time-Retrieval bekämpfen Context Rot. Anthropic Mar 2026 stellt explizit fest: bei langen Aufgaben schlägt ein sauberer Reset eine weitere Compaction.

7. Sub-Agent-Orchestrierung

Spezialisierte Sub-Agenten für Planung, Ausführung, Bewertung — idealerweise mit Modell-Routing (großes Modell für Planung, kleines für massenhafte Tool-Calls). Die wichtigste Architektur-Entscheidung im Harness und der größte Kostenhebel.

8. Hooks & Middleware

Deterministische Durchsetzung um nicht-deterministische Modellaufrufe: Typecheck, Lint, Policy-Gates, Prüfungen vor und nach jedem Tool-Call. Hooks ersetzen nicht Evals — sie verhindern Klassen von Fehlern, die der Agent gar nicht erst sehen darf.

9. Observability

Logs, Metriken, verteilte Traces. OpenAI hat Codex-Agenten dazu gebracht, ihre eigenen Traces (LogQL/PromQL) zur Laufzeit abzufragen, um ihre eigenen PRs zu verifizieren. Observability ist kein optionales Add-on, sondern die Sensorik, ohne die Evals blind sind.

10. Eval-Loop

Aufgabenspezifische Bewertungen, getrennt vom generierenden Agenten. „Agents reliably skew positive when grading their own work.“ Wer keine Evals hat, hat keinen Harness — nur eine Demo. Hamel Husain: Dokumentation sagt, was zu tun ist; Telemetrie, ob es funktioniert hat; Evals, ob das Ergebnis gut ist.

Planner / Generator / Evaluator: das Drei-Agenten-Muster

Anthropics März-2026-Post „Harness design for long-running application development“ verfestigt das Muster, das sich 2025 in der Praxis als überlegen herausgestellt hat: drei spezialisierte Agenten, die zusammen einen Auftrag erledigen. Self-Grading — ein Agent, der gleichzeitig produziert und bewertet — führt zu systematisch überoptimistischen Urteilen. Die Trennung beseitigt diesen Bias.

Planner

Aufgabe: Den Auftrag in einen Sprint Contract zerlegen, bevor überhaupt Code generiert wird.

Definiert Akzeptanzkriterien, Eingabe-/Ausgabeformate, Constraints. Verhandelt mit dem Nutzer, was „fertig“ heißt. Liefert ein prüfbares Artefakt, an dem der Generator arbeiten kann und der Evaluator messen kann.

Generator

Aufgabe: Den Sprint Contract erfüllen — Code schreiben, Tool-Calls ausführen, Memory pflegen, Checkpoints commiten.

Hat keinen Anreiz, das Ergebnis zu schönen, weil ein anderer Agent darüber urteilt. Maximale Konzentration auf die Aufgabe, klare Handoff-Artefakte am Ende jedes Sprints.

Evaluator

Aufgabe: Gegen die Akzeptanzkriterien des Planners prüfen — mit Tools, Tests, Telemetrie.

Stellt strukturierte Fragen: Sind die Tests grün? Stimmt das beobachtete Verhalten mit der Spec überein? Wenn nein, wo? Bewertet nicht das Bemühen, sondern das Ergebnis.

Der Sprint Contract ist das verbindende Element: ein verhandeltes, schriftliches Verständnis darüber, was in diesem Sprint erreicht werden soll. Der Planner schreibt ihn, der Generator erfüllt ihn, der Evaluator prüft gegen ihn. Für lange Aufgaben — das war Anthropics ursprüngliche Motivation — werden Sprint Contracts zu Handoff-Artefakten zwischen Kontextfenstern: ein neuer Agent übernimmt den Faden, ohne den vollen Kontext zu kennen.

„Separating the agent doing the work from the agent judging it is the single most important architectural decision in a long-running harness.“
Drei spezialisierte KI-Agenten — Planner (Hexagon), Generator (Quadrat), Evaluator (Dreieck) — arbeiten ringförmig über einen geteilten Sprint Contract zusammen
Planner, Generator, Evaluator — drei spezialisierte Agenten verhandeln, erfüllen und prüfen einen geteilten Sprint Contract.

Patterns & Anti-Patterns 2026

Aus den veröffentlichten Engineering-Posts und Konferenzbeiträgen (AI Engineer Europe, NeurIPS 2025) lässt sich destillieren, was sich durchgesetzt hat — und welche Reflexe Sie sich abtrainieren müssen.

Bewährte Patterns

  • Planner / Generator / Evaluator-Trennung — entfernt Self-Grading-Bias.
  • Sprint Contracts vor jedem Sprint — prüfbare Akzeptanzkriterien.
  • Git-as-Checkpoint — durable Recovery ohne Neu-Infrastruktur.
  • Ein einziges Providers-Interface für Auth, Telemetrie, Feature-Flags (OpenAI Codex).
  • Skills mit progressiver Offenlegung — gegen Context Rot.
  • Self-instrumented Agents — Agenten, die ihre eigenen Traces lesen.
  • „Success is silent, failures are verbose.“ — nur verhaltensändernde Tool-Errors hochreichen.

Anti-Patterns

  • „Wait for the next model“ — Harness-Probleme als Modell-Probleme fehldiagnostizieren.
  • Tool-Menü-Bloat — fünfzig überlappende Werkzeuge fragmentieren die Aufmerksamkeit.
  • Self-Grading — derselbe Agent generiert und bewertet.
  • Überregulierte AGENTS.md — Regeln ohne Bezug zu echten Fehlschlägen sind Rauschen.
  • Compaction als Allheilmittel — bei langen Aufgaben schlägt ein Reset jede weitere Komprimierung.
  • Monitoring ohne Containment — die 58 %/37 %-Lücke: man sieht die Probleme, kann sie aber nicht stoppen.
  • Eval-Plattform ohne Skills — Observability kaufen, ohne dem Agenten beizubringen, sie zu nutzen.

Harness Engineering & EU AI Act (ab 2. August 2026)

Die Hochrisiko-Pflichten der Verordnung (EU) 2024/1689 werden ab dem 2. August 2026 wirksam. Wer KI-Agenten in kritischer Infrastruktur, im Personalwesen, in der Strafverfolgung, in Medizin oder im Bildungswesen einsetzt, muss dann die Anforderungen der Artikel 9 bis 15 erfüllen. Die gute Nachricht: ein gut gebauter Harness produziert exakt die Artefakte, die der AI Act verlangt. Die schlechte Nachricht: ohne Harness gibt es nichts zu produzieren.

EU AI Act Artikel Was verlangt wird Wo es im Harness sitzt Status
Art. 9 — Risikomanagement Kontinuierliche Risikobewertung über den gesamten Lebenszyklus. Eval-Loop, Evaluator-Agent, FRIA-Dokumentation Pflicht ab Aug. 2026
Art. 10 — Datenqualität Repräsentative, fehlerfreie, vorurteilsarme Trainings- und Eingabedaten. Tool-Registry-Inputs, Memory/State-Pflege, Datensatz-Provenance Pflicht ab Aug. 2026
Art. 11 — Technische Dokumentation Vollständige technische Dokumentation der Entscheidungslogik. Harness-Architekturdoku, AGENTS.md, Skills-Bibliothek Pflicht ab Aug. 2026
Art. 12 — Logging Automatische Protokollierung von Ereignissen während des Betriebs. Observability-Layer, Distributed Traces, Tool-Call-Logs Pflicht ab Aug. 2026
Art. 13 — Transparenz Verständliche Information für Betreiber. Skill-Beschreibungen, Tool-Karten, Sprint-Contract-Artefakte Pflicht ab Aug. 2026
Art. 14 — Menschliche Aufsicht Effektive Überwachung und Eingriffsmöglichkeit durch Menschen. Permission-Modell, Kill-Switch, Human-in-the-Loop-Checkpoints Pflicht ab Aug. 2026
Art. 15 — Genauigkeit & Robustheit Angemessenes Niveau an Genauigkeit, Robustheit, Cybersecurity. Sandbox, Hooks, deterministische Policy-Gates, Eval-Loop Pflicht ab Aug. 2026

Die Governance-Containment-Lücke

Branchenstudien zeigen 2026 ein konsistentes Muster: 58 % der Unternehmen überwachen ihre KI-Agenten, aber nur 37–40 % können sie tatsächlich anhalten oder eingrenzen. Diese Lücke ist keine technische, sondern eine Harness-Lücke. Wer Artikel 14 („Menschliche Aufsicht“) ernst nimmt, muss Containment einplanen: Kill-Switch, Permission-Gates, Sandbox-Isolation, A2A-Threat-Modeling. Monitoring ohne Containment ist Compliance-Theater.

Artikel 57 verlangt zusätzlich, dass jeder EU-Mitgliedstaat bis zum 2. August 2026 mindestens einen regulatorischen KI-Sandbox betreibt. Wer dort früh experimentiert, kann Harness-Pattern unter Aufsicht erproben — eine Chance, die nur nutzt, wer das Konzept „Harness“ bereits verstanden hat.

Visualisierung von Compliance-Gates: ein chaotischer Knotencluster (Agentenlaufzeit) wird durch translucente Compliance-Schichten in eine geordnete Audit-Struktur überführt
Vom Agenten-Chaos zur Audit-Struktur: Hooks, Logging, Permission-Gates und Evals übersetzen Laufzeit-Komplexität in prüfbare EU-AI-Act-Artefakte.

Produktive Harnesses 2026

Der schnellste Weg, Harness-Engineering zu lernen, ist der Blick auf produktive Systeme — idealerweise mit veröffentlichten Architektur-Posts. Sechs Referenzen sollten 2026 jeder Platform-Engineering-Verantwortliche kennen.

Claude Code (Anthropic)

Anthropic vermarktet Claude Code als „general-purpose agent harness“. Dokumentierte autonome Läufe von über sechs Stunden für Full-Stack-Anwendungen. Referenzimplementierung für Skills, Sub-Agenten, Hooks und Memory mit Git-Checkpoints. Lehrwert: wie ein modernes Harness-Permission-Modell aussieht.

OpenAI Codex App Server

Baute sich selbst: ~1 Mio. LoC, 1.500 zusammengeführte PRs, 3→7 Engineers in 5 Monaten. Durchsatz: 3,5 PRs pro Engineer pro Tag. Lehrwert: ein einziges Providers-Interface, Telemetrie als Compliance-Backbone, Self-querying Agenten.

Cursor

IDE-integrierter Coding-Harness mit eigenem Modell-Routing und Composer-Modus. Lehrwert: wie sich UX-Design und Harness-Design gegenseitig bedingen — ein guter Harness braucht ein Frontend, das Vertrauen aufbaut, nicht nur Tokens streamt.

Cline

Open-Source-Harness mit transparenter Permission-Logik und kompletter Plan/Act-Trennung. Lehrwert: wie Sie ein Harness so bauen, dass jede Aktion vor Ausführung sichtbar wird — relevant für Artikel 14 EU AI Act.

Aider

Git-nativer Coding-Harness, auf Pair-Programming-Workflow optimiert. Lehrwert: Git als einziger persistenter State; minimaler Sandbox; klare Demonstration, dass Komplexität kein Selbstzweck ist.

LangChain DeepAgents

Open-Source-Harness mit Default-Prompts, Planner, Filesystem-Zugriff. Lehrwert: ein guter Einstieg zum Selberbauen — lesbar, gut dokumentiert, bewusst minimal in den Annahmen.

Implementierungs-Roadmap: vom Demo-Agent zum Harness

Wer heute einen funktionierenden Demo-Agent hat und ihn produktiv machen will, kann den Pfad in vier Phasen gehen. Die Reihenfolge ist nicht beliebig — jede Phase liefert die Voraussetzungen für die nächste.

Phase 1: Bestandsaufnahme (Woche 1)

Audit

Inventar von Tool-Registry, Permission-Modell, vorhandenem Logging und vorhandenen Evals. Identifikation der zehn Komponenten — was existiert, was fehlt, was ist halbgar. Mapping auf EU-AI-Act-Artikel 9–15. Ergebnis: Harness-Reifegradbericht.

Phase 2: Eval-Loop (Woche 2–4)

Foundation

Aufgabenspezifische Evals werden gebaut, bevor Architektur geändert wird. Ohne Eval kein Vorher/Nachher-Vergleich. Trennung Generator/Evaluator als erste strukturelle Maßnahme. Ergebnis: reproduzierbarer Pass-Rate-Wert auf einer Goldmenge von Aufgaben.

Phase 3: Permission & Containment (Woche 4–6)

Compliance

Kill-Switch, Permission-Gates, Sandbox-Isolation. Schließt die Governance-Containment-Lücke und macht Artikel 14 EU AI Act erfüllbar. Ergebnis: der Agent ist tatsächlich stoppbar — nicht nur überwachbar.

Phase 4: Sub-Agent-Architektur (Woche 6–10)

Scale

Planner / Generator / Evaluator-Trennung als Architektur. Modell-Routing zur Kostenkontrolle. Skills mit progressiver Offenlegung. Ergebnis: der Harness skaliert über längere Aufgaben, ohne in Context Rot zu kollabieren.

Innobu Harness-Advisory

innobu unterstützt Mittelstand und regulierte Branchen dabei, von einem überzeugenden Demo-Agenten zu einem produktiven, EU-AI-Act-konformen Harness zu kommen. Vier Module, einzeln oder kombinierbar.

Modul 1
Harness-Audit (2–4 Wochen): Reifegrad, Lückenanalyse, priorisierte Roadmap.
Modul 2
Eval & Observability Setup: aufgabenspezifische Evals, Telemetrie-Backbone, Self-querying Agents.
Modul 3
EU-AI-Act-Mapping: Artikel-9–15-Kontrolldokumentation, FRIA-Vorlage, Kill-Switch-Design.
Modul 4
Sub-Agent-Architektur: Planner/Generator/Evaluator-Implementation, Modell-Routing, Sprint-Contract-Templates.

Harness-Audit anfragen →

Strategische Bedeutung für 2026 und danach

Harness Engineering ist 2026 keine optionale Disziplin. Wer KI-Agenten produktiv betreibt — ob für Coding, Kundenservice, Marktkommunikation in der Energiewirtschaft, Kreditprüfung im Mittelstand — trifft hier strategische Entscheidungen, die jahrelang nachwirken.

Wettbewerbsvorteil über Modellgenerationen hinweg

Modelle werden austauschbar; Harness-Investitionen amortisieren sich über jede Modellgeneration. Wer einen sauberen Harness hat, kann das beste verfügbare Modell einsetzen — ohne sich an einen Anbieter zu binden.

Compliance als Nebenprodukt

EU AI Act, NIS2, DORA, Branchenregulatorik — alle verlangen dieselben Bausteine: Logging, menschliche Aufsicht, Risikomanagement, Robustheit. Ein gut gebauter Harness produziert die Evidenz fast nebenbei.

Kostenkontrolle

Sub-Agent-Routing, Compaction, Kontext-Reset und spezialisierte kleine Modelle für Massen-Tool-Calls sind die größten Hebel für die Pro-Aufgabe-Kosten. Ohne Harness keine Kontrolle über diese Hebel.

DACH-Sichtbarkeit

Deutsche Stimmen zur Harness-Engineering-Praxis sind 2026 dünn gesät. Wer früh Produkterfahrung dokumentiert, wird zum Referenzpunkt für Branche und Aufsicht — mit konkreten Konsequenzen für Sandbox-Zugang und Pilotpartnerschaften.

„Die Lücke zwischen dem, was Modelle 2026 können, und dem, was Sie sie tatsächlich tun sehen, ist größtenteils eine Harness-Lücke. Diese Lücke ist Ihre Chance.“
Aufsteigende Plattformen aus vernetzten Knotenpunkten symbolisieren progressive Reife und kumulierende Renditen einer Harness-Investition über Modellgenerationen
Harness-Investitionen amortisieren sich über jede Modellgeneration — während Modelle austauschbar werden, bleibt die Laufzeit-Architektur bestehen.

Weiterführende Ressourcen

Häufige Fragen zum Agentic Harness Engineering

Was ist Agentic Harness Engineering?+

Agentic Harness Engineering ist die Disziplin, die Laufzeitumgebung um ein Sprachmodell — Tool-Registry, Sandbox, Memory, Sub-Agenten, Hooks, Observability, Eval-Loop — so zu entwerfen und zu instrumentieren, dass das Modell zuverlässig als Agent handelt. Die Kurzformel: Agent = Modell + Harness. Wer nicht das Modell ist, ist der Harness — und der Harness entscheidet, ob ein Demo zum Produkt wird.

Was ist der Unterschied zwischen einem Harness und einem Agent-Framework wie LangChain?+

Ein Agent-Framework (LangChain, AutoGen, CrewAI) ist eine Bibliothek mit Bausteinen. Ein Harness ist das vollständige, instrumentierte System, das Sie aus diesen Bausteinen bauen — inklusive Permission-Modell, Evals, Observability, Sub-Agent-Orchestrierung und Recovery-Logik. Frameworks sind Werkzeug, Harnesses sind Produkt. Sie können einen Harness ohne Framework bauen; ein Framework ohne Harness ist nur Code.

Brauche ich für jeden Use-Case eigene Evals?+

Ja. Generische Modell-Benchmarks sagen nichts darüber, ob Ihr Agent Ihre Aufgabe löst. Hamel Husain bringt es auf den Punkt: „Documentation tells the agent what to do. Telemetry tells it whether it worked. Evals tell it whether the output is good.“ Ein Harness ohne aufgabenspezifische Evals ist blind — und produziert keine belastbare Compliance-Evidenz nach Artikel 9 EU AI Act.

Wie hoch ist das Compliance-Risiko ohne Harness?+

Erheblich. Die Hochrisiko-Pflichten des EU AI Acts gelten ab 2. August 2026. Artikel 9–15 verlangen Risikomanagement, Logging, menschliche Aufsicht und Robustheit — genau die Komponenten, die ein Harness liefert. Branchenstudien zeigen eine Governance-Containment-Lücke: 58 % der Unternehmen überwachen Agenten, aber nur 37–40 % können sie tatsächlich anhalten. Strafen reichen bis 35 Mio. Euro oder 7 % des weltweiten Umsatzes.

Wie lange dauert ein Harness-Audit bei innobu?+

Ein typisches Harness-Audit dauert 2–4 Wochen: 1 Woche Bestandsaufnahme (Tool-Registry, Permission-Modell, Logging, vorhandene Evals), 1–2 Wochen Lückenanalyse mit Mapping auf EU-AI-Act-Artikel und 1 Woche Roadmap. Ergebnis: priorisierter Maßnahmenkatalog mit Aufwandschätzung. Für tieferen Eingriff folgen die Module 2–4 unserer Advisory.

Ist Harness Engineering nur für Coding-Agenten relevant?+

Nein. Coding-Agenten sind 2026 der lauteste Anwendungsfall, weil dort die meisten Belege existieren (Claude Code, Codex, Cursor, Cline, Aider). Aber jeder Produktiv-Agent — im Kundenservice, in der Energie-Marktkommunikation, in der Finanzberatung, in HR-Workflows, in der Forschung — braucht dieselben Harness-Komponenten: Tool-Registry, Permission-Modell, Memory, Evals, Observability. Die Domain wechselt, die Disziplin nicht.