Agent Harnesses: die Infrastruktur hinter verlaesslichen KI-Agents

Viele KI-Agent-Demos sehen anfangs aehnlich aus: starkes Modell anschliessen, ein paar Tools hinzufuegen, einen guten Prompt schreiben und das System an einer Aufgabe arbeiten lassen. Fuer eine Demo kann das reichen. Fuer Production reicht es nicht. Produktive Agents muessen relevanten Kontext behalten, Tools sicher nutzen, sich von Fehlern erholen, Permissions respektieren, ihre Arbeit verifizieren und weiterlaufen, wenn eine Aufgabe laenger dauert als eine einzelne saubere Modellantwort. Das Modell ist wichtig, aber das System um das Modell herum entscheidet, ob der Agent im Alltag nuetzlich ist. Dieses System wird oft Agent Harness, Agent Runtime, Orchestration Layer, Execution Environment oder Agent Scaffolding genannt. In diesem Artikel verwenden wir "Agent Harness" fuer die Runtime- und Orchestrierungsschicht rund um das Modell. Andere Teams verwenden fuer dieselbe Schicht Begriffe wie Agent Framework, Orchestration Layer, Execution Runtime oder Agent Scaffolding.

Was ein Agent Harness ist

Ein Agent Harness ist die Software-Infrastruktur, die aus einem zustandslosen Sprachmodell einen arbeitsfaehigen Agent macht. Das Modell sagt Tokens voraus, plant und fuehrt reasoning-aehnliche Inferenz aus. Das Harness gibt ihm eine kontrollierte Umgebung, in der es handeln kann. Ein Production-Harness umfasst typischerweise:

Orchestrierungs-Loops
Tool-Registrierung und Tool-Ausfuehrung
Context Management
Short-Term- und Long-Term-Memory
State Persistence
Permission Checks
sandboxed execution
Retries und Error Handling
Verification Loops
Tracing und Observability
Model Routing
Subagent Delegation

Ohne diese Schicht bleibt ein KI-Agent meist naeher an einer chatartigen Oberflaeche oder an einem Single-Step-Assistant. Mit dieser Schicht kann er zu einer Workflow-Engine werden. Wenn ein Nutzer etwa bittet, einen Checkout-Bug zu beheben, kann ein Modell vielleicht sagen, wo man schauen sollte. Ein Harness laesst den Agent aber das Repository inspizieren, Dateien durchsuchen, Code editieren, Tests ausfuehren, Fehler lesen, den Patch reparieren, den Diff pruefen und erst stoppen, wenn das Ergebnis verifiziert ist. Diese Differenz ist das Produkt.

Warum das Harness wichtiger wird

KI-Teams lernen gerade, dass zwei Produkte mit demselben Modell sehr unterschiedliche Ergebnisse liefern koennen. Der Grund ist Infrastruktur. Frontier-Modelle verbessern sich schnell. Je mehr Faehigkeiten wie Tool Use, Structured Output, Long Context, Code Generation und reasoning-aehnliche Inferenz bei mehreren Anbietern verfuegbar werden, desto mehr Produktvorteil verschiebt sich in die Umgebung rund um das Modell. Harness-Arbeit kumuliert ebenfalls. Jeder Fehler kann zu einer dauerhaften Systemverbesserung werden:

Schlechte Tool-Argumente fuehren zu haerteren Schemas und Validierung.
Vergessene Entscheidungen fuehren zu besserem Context- und Memory-Design.
Riskante Aenderungen fuehren zu Permission Gates.
Zu fruehe Fertigmeldungen fuehren zu mehr Verifikation.
Teure Wiederholungen fuehren zu besserem Caching oder Routing.
Schwaches Verhalten bei langem Kontext fuehrt zu Compaction und Retrieval.

Prompt-Fixes helfen, aber sie reichen nicht. Belastbares Verhalten entsteht aus Runtime-Design.

Prompt Engineering, Context Engineering und Harness Engineering

Diese Begriffe haengen zusammen, sind aber nicht identisch. Prompt Engineering ist die Instruction-Schicht. Sie sagt dem Modell, welche Rolle es einnehmen soll, welche Constraints wichtig sind und wie es antworten soll. Context Engineering ist die Informationsschicht. Sie entscheidet, was das Modell sieht, wann es das sieht und wie viel davon in das aktuelle Fenster gehoert. Harness Engineering ist die komplette Execution-Schicht. Sie enthaelt Prompts und Kontext, aber auch Tools, State, Safety, Memory, Verifikation, Queues, Observability und Lifecycle Management. Diese Unterscheidung ist wichtig, weil Prompts Verhalten nur anfordern, waehrend Harnesses Verhalten durchsetzen. Ein Prompt kann sagen: "Loesche keine Dateien ohne Erlaubnis." Ein Harness kann destruktive Kommandos blockieren, bis der Nutzer sie genehmigt. Ein Prompt kann sagen: "Pruefe deine Arbeit." Ein Harness kann die Testsuite starten, die Ausgabe inspizieren und den Abschluss verhindern, wenn die Verifikation fehlschlaegt.

Wie ein Agent Harness funktioniert

Die meisten Agent Harnesses laufen in einer Schleife. Zuerst baut das Harness den Modelleingang zusammen. Dazu koennen System Prompt, Developer Instructions, User Request, Tool-Definitionen, Memory, aktueller Task State und ausgewaehlter Kontext aus Dateien oder Datenbanken gehoeren. Dann antwortet das Modell. Es kann Text, strukturierte Daten, Tool Calls oder eine Anfrage zur Delegation an einen anderen Agent liefern. Danach klassifiziert das Harness die Ausgabe. Wenn das Modell eine finale Antwort geliefert hat, kann die Schleife stoppen. Wenn es ein Tool anfordert, validiert das Harness den Aufruf. Validierung ist kritisch. Das Harness prueft, ob die Argumente zum Schema passen, ob das Tool verfuegbar ist, ob die Aktion sicher ist und ob User oder System die notwendige Erlaubnis erteilt haben. Danach laeuft das Tool. Es kann Dateien lesen, Datenbanken abfragen, Dokumente durchsuchen, APIs aufrufen, Code ausfuehren, einen Browser oeffnen oder einen Patch schreiben. Das Ergebnis kommt als Observation zum Modell zurueck. Wenn das Tool fehlschlaegt, sollte der Fehler klar genug verpackt sein, damit das Modell sich erholen kann. Die Schleife laeuft weiter, bis der Agent einen verifizierten Stopp-Punkt erreicht, ein Budgetlimit trifft, menschlichen Input braucht oder unterbrochen wird. Einfach klingt das nur oberflaechlich. Production-Qualitaet steckt in jedem Detail rund um diese Schleife.

Zentrale Teile eines Production-Harnesses

1. Orchestrierungs-Loop

Der Orchestrierungs-Loop steuert die Zuege des Agents. Gaengige Muster:

ReAct: denken, handeln, beobachten, wiederholen
plan and execute: Plan erstellen und dann ausfuehren
generate, test, repair: Ergebnis erzeugen, pruefen, Fehler beheben
gather, act, verify: Kontext sammeln, handeln, Ergebnis pruefen

Der Loop selbst kann technisch klein sein. Schwer ist zu entscheiden, welcher Kontext in welchen Turn gehoert, welche Aktionen erlaubt sind, was Fehler bedeuten und wann eine Aufgabe wirklich fertig ist.

2. Tool-Schicht

Tools sind die Haende des Agents. Gute Tools werden fuer Modelle entworfen, nicht nur fuer Menschen. Menschen koennen verrauschte CLI-Ausgabe, versteckte Defaults, mehrdeutige Flags und partielle Fehler interpretieren. Ein Agent braucht klarere Grenzen. Die Tool-Schicht sollte handhaben:

Namen und Beschreibungen
Argument-Schemas
Permission Checks
Sandboxing
Ausfuehrung
Formatierung der Ergebnisse
Retries
Audit-Logs

Tool-Design entscheidet oft ueber Agent-Qualitaet. Zu viele Tools verwirren das Modell. Vage Parameter erzeugen unzuverlaessige Aufrufe. Breite Permissions erzeugen Risiko. Starke Harnesses exponieren das kleinste nuetzliche Tool-Set fuer den aktuellen Schritt.

3. Context Management

Kontext ist kein Speicher. Kontext ist eine knappe Arbeitsoberflaeche. Grosse Kontextfenster helfen, aber sie ersetzen nicht die Auswahl. Wenn irrelevante Logs, alte Outputs, veraltete Plaene und wiederholter Inhalt das Fenster fuellen, wird das Modell unzuverlaessiger. Production-Harnesses nutzen Strategien wie:

zuerst kleine Indizes laden
exakte Dateien oder Records on demand abrufen
alte Conversation Turns zusammenfassen
alte Tool-Outputs maskieren
Entscheidungen und offene Probleme behalten, aber Rauschen entfernen
Exploration an Subagents delegieren, die kompakte Zusammenfassungen zurueckgeben

Ziel ist nicht maximaler Kontext. Ziel ist der kleinste high-signal Kontext, der dem Modell hilft, den naechsten Schritt richtig auszufuehren.

4. Memory

Memory erlaubt einem Agent, nuetzliche Information ueber Turns und Sessions hinweg mitzunehmen. Short-Term-Memory deckt die aktive Aufgabe ab. Long-Term-Memory speichert dauerhafte Fakten, Praeferenzen, Projektregeln und wiederkehrende Entscheidungen. Working Memory kann aus Progress-Dateien, Todo-Listen oder strukturierten Scratchpads bestehen. Memory darf nicht als Wahrheit behandelt werden. Es sollte als Hinweis behandelt werden. Wenn Memory sagt, dass ein Projekt ein bestimmtes Framework nutzt, sollte der Agent das Projekt trotzdem inspizieren, bevor er framework-spezifische Aenderungen macht. Das verhindert, dass veraltete Memory zu halluzinierter Sicherheit wird. Memory braucht ausserdem Isolation und Review, weil schlechte oder boesartige gespeicherte Fakten spaetere Runs beeinflussen koennen. Ein Production-System sollte vermeiden, dass Memory ueber User-, Team-, Tenant- oder Permission-Grenzen hinweg leakt.

5. State Persistence

Production-Aufgaben ueberleben haeufig mehr als eine einzige Modellantwort. Das Harness sollte verfolgen:

Session ID
Run ID
aktuellen Status
ausstehende Tool Calls
beruehrte Dateien
Child Agents
erteilte Freigaben
Kosten und Token Usage
Endergebnis
Delivery Status

State erlaubt es, eine Aufgabe nach einer Unterbrechung fortzusetzen. Ausserdem schafft er Auditierbarkeit: Was ist passiert, wann, warum und ueber welches Tool.

6. Error Handling

Fehler sind in agentischen Workflows erwartbar. Ein starkes Harness trennt Fehlertypen:

transiente Fehler sollten mit Backoff erneut versucht werden
Tool-Argumentfehler sollten klares Feedback ans Modell geben
Permission-Fehler sollten Freigabe einholen oder einen sicheren Pfad waehlen
unerwartete Fehler sollten mit brauchbaren Diagnosen stoppen

Das ist wichtig, weil mehrstufige Aufgaben Fehler akkumulieren. Selbst eine hohe Erfolgsquote pro Schritt kann ueber eine lange Sequenz hinweg schwach werden. Recovery-Logik ist nicht optional.

7. Guardrails und Permissions

Das Modell kann entscheiden, was es tun moechte. Das Harness muss entscheiden, was es tun darf. Nuetzliche Permission-Grenzen:

read-only vs write access
Workspace Scope
Freigabe fuer destruktive Kommandos
Freigabe fuer Datenbank-Mutationen
Limits fuer externe APIs
Credential-Zugriffsrestriktionen
menschliche Review vor user-facing Aktionen

Diese Schicht muss durch Code durchgesetzt werden, nicht nur durch Prompt-Text. Bei hochriskanten Aktionen sollte die Freigabe vor dem Tool-Run stattfinden, nicht danach.

8. Verification Loops

Verifikation ist der Punkt, an dem Agents verlaesslich werden. Bei Software-Aufgaben kann Verifikation Tests, Type Checks, Linters, Builds, Screenshots, Browser Checks und Diff Review enthalten. Bei Business-Workflows kann sie Schema-Validierung, Datenbank-Constraints, menschliche Review, Confidence Thresholds, Dokument-Zitate und Trace Inspection enthalten. Ein Teil der Verifikation ist deterministisch. Ein anderer Teil nutzt ein Modell als Judge. Deterministische Checks sollten bevorzugt werden, wenn objektive Ground Truth existiert.

9. Observability

Teams muessen sehen koennen, wie Agents sich verhalten. Ein Production-Harness sollte tracen:

Prompts und Modell-Outputs
Tool Calls
Tool Results
Fehler
Retries
Approvals
Token Usage
Latenz
Verification Results
Endergebnisse

Ohne Observability koennen Teams das System nicht verbessern. Sie koennen nur raten, warum es versagt hat.

Subagents und Multi-Agent-Lifecycle-Management

Sobald ein Agent andere Agents spawnen kann, aendert sich das Problem. Subagents sind hilfreich, wenn sich Arbeit aufteilen laesst. Ein Agent kann Dokumentation inspizieren, waehrend ein anderer Code reviewt. Einer testet UI, waehrend ein anderer Backend-Logik patched. Einer recherchiert Quellen, waehrend ein anderer den Entwurf schreibt. Aber Subagents zu starten ist nicht dasselbe wie sie zu verwalten. Multi-Agent-Lifecycle-Management beginnt, wenn die Runtime viele laufende Agents ueber Zeit besitzen muss. Ein ernstes Multi-Agent-System braucht:

dauerhafte Child-Agent-IDs
Parent-Child-Lineage
Run IDs
Rollen und Tiefenlimits
Queues
Cancellation
Steering
Completion Events
Cleanup Policy
Recovery nach Neustarts

Die Kernfrage wird dann: Wo lebt der Child Agent, wem gehoert er, wie meldet er zurueck und was passiert, wenn der Parent schon weitergezogen ist. Einfache Delegation gibt dem Parent eine Zusammenfassung zurueck. Multi-Agent-Lifecycle-Management behandelt Completion als Routing-Problem. Ein Child kann fertig werden, waehrend der Parent aktiv, idle, neugestartet oder verschwunden ist. Die Runtime muss dieses Ergebnis mit intakter Provenance an den richtigen Ort zustellen. Deshalb beginnen fortgeschrittene Agent-Systeme Prozessmanagern zu aehneln. Sie brauchen Identitaet, Lifecycle, Queues, Recovery und Cleanup.

Managed Agents vs. Custom Harnesses

Managed-Agent-Plattformen werden haeufiger. Sie paketieren Harness und Production-Infrastruktur, damit Teams schneller starten koennen. Das kann wertvoll sein, wenn ein Team will:

schneller launchen
eine gehostete Runtime
eingebaute Skalierung
gemanagte Tool-Ausfuehrung
standardisierte Observability
weniger Infrastrukturverantwortung

Aber Managed Agents sind ebenfalls eine Architekturentscheidung. Teams brauchen eventuell trotzdem ein Custom Harness, wenn:

Workflow-Qualitaet zentraler Produktwert ist
Domain-Tools sehr spezifisch sind
Permissions und Audit Trails streng sind
Kosten pro Task zaehlen
langlebige Agents eigene Lifecycle-Regeln brauchen
Vendor Lock-in ein Thema ist
Standard-Agent-Verhalten auf internen Evals unterperformt

Fuer viele Teams ist der praktische Weg weder "alles selbst bauen" noch "nur Managed Runtime nutzen". Er ist stufenweise. Mit vorhandenen Tools anfangen. Evals bauen. Fehlermuster finden. Das Harness dort anpassen, wo wiederholte Fehler oder Oekonomie es rechtfertigen.

Wann euer Team sich damit beschaeftigen sollte

Ihr solltet Harness-Design ernst nehmen, sobald ein KI-Workflow ueber den Prototyp hinausgeht. Deutliche Signale:

Nutzer sind vom Output abhaengig
Fehler erzeugen operativen Schaden
der Workflow beruehrt private oder regulierte Daten
der Agent braucht Tools mit Side Effects
die Aufgabe hat viele Schritte
der Output braucht Verifikation
menschliche Review braucht Audit-Trails
Token-Kosten werden sichtbar
das Verhalten des Agents schwankt unvorhersehbar zwischen Runs

Ab diesem Punkt ist das Modell nur noch ein Teil des Systems. Verlaesslichkeit kommt aus dem Harness.

Wie wir das bei Lunover angehen

Bei Lunover behandeln wir KI-Agents als Production-Softwaresysteme, nicht als Prompt-Experimente. Das bedeutet, wir starten bei Workflow Value. Wir mappen den realen Prozess, Datenquellen, Risiken, Nutzer und Erfolgskriterien, bevor wir bauen. Dann waehlen wir das passende Mass an Harness-Komplexitaet fuer die Aufgabe. Fuer einen einfachen internen Assistant kann das Retrieval, Tool Use und grundlegendes Monitoring bedeuten. Fuer einen kundenorientierten Workflow kann es strengere Permissions, Evals, Fallbacks, Trace Review und menschliche Freigaben erfordern. Fuer langlebige Automation kann es durable State, Job Queues, Recovery und klare Ownership jeder Agent-Aktion brauchen. Ziel ist nicht, den Agent in einer Demo beeindruckend aussehen zu lassen. Ziel ist, das System nach dem Launch nuetzlich zu machen. Wenn euer Team AI-Agents, Copilots, RAG-Systeme oder Workflow-Automation baut, kann Lunover ueber KI-Beratung, Web-App-Entwicklung und Business-Systeme dabei helfen, die Production-Schicht rund um euer Modell zu entwerfen: Tools, Memory, Permissions, Verifikation, Observability und Deployment.