# Agent Harness Engineering, Loop Engineering und Graph Engineering
> *„Blaming the model for orchestration failures is like blaming the builder when the crane collapses. It's a harness issue, not a model issue."*
> — beamnxw, X, 25.07.2026
## Überblick
Harness Engineering, Loop Engineering und Graph Engineering bezeichnen drei voneinander unterscheidbare Architektur-Ebenen agentischer KI-Systeme, die in der Praxis häufig vermischt werden. Alle drei beeinflussen die Zuverlässigkeit eines Agentensystems, adressieren aber unterschiedliche Entwurfsfragen. Das mentale Modell des Artikels lautet: **environment → feedback → flow**.
| Ebene | Frage | Kurzantwort |
|---|---|---|
| Harness Engineering | Womit arbeitet das Modell? | Baut die Maschinerie *um* das Modell (Umgebung) |
| Loop Engineering | Wie wird Arbeit überprüft und wiederholt? | Entwirft den Work-and-Feedback-Zyklus (Rückmeldung) |
| Graph Engineering | Was darf als Nächstes laufen? | Macht die Workflow-Topologie explizit (Fluss) |
## 1. Agent Harness Engineering
**Definition:** Der *Agent Harness* ist die Gesamtheit von Code, Konfiguration und Ausführungslogik außerhalb des Modells — nach LangChain: Agent = Modell + Harness. OpenAIs Agents SDK beschreibt denselben Kern als Runtime: Der Runner ruft das Modell, führt Tool-Aufrufe aus, verwaltet Handoffs und State und stoppt erst bei einer echten Terminalbedingung.
**Merksatz:** Entfernt man das Modell aus dem Architekturdiagramm, ist alles Verbleibende Teil des Harness.
**Wann Harness Engineering entscheidend ist:** bei langlaufenden Aufgaben. Anthropic fand etwa bei Multi-Session-Coding, dass Kontext-Kompaktierung allein nicht reichte — erst ein Harness aus Initializer, Progress-File, Git-Historie und inkrementeller Arbeitsdisziplin machte Sessions fortsetzbar.
**Verwandte Wiki-Seite:** [[architecture-triade.md]] (Harness als Fundamentschicht der Triade)
## 2. Loop Engineering
**Definition:** Entwurf der wiederholten Arbeits- und Rückmeldezyklen um den Agenten. Jeder toolnutzende Agent hat eine eingebettete Basis-Schleife (Modell aufrufen → Ergebnis prüfen → Tools ausführen → Beobachtungen zurückgeben → wiederholen). Loop Engineering beginnt, wo bewusst weitere Zyklen darum gestapelt werden.
**Loop-Typen:**
- **Verification Loop** — Artefakt erzeugen, deterministisch prüfen/bewerten, nur bei Fehlern wiederholen
- **Event-driven Loop** — Agent erwacht bei Schedule, Webhook oder neuem Dokument
- **Improvement Loop** — Traces/Fehler analysieren, Instruktionen/Tools anpassen, Version vergleichen
**Anatomie einer gut konstruierten Schleife:**
1.**Trigger** — was einen Zyklus startet (Anfrage, Zeitplan, fehlgeschlagener Test, Feedback)
2.**Goal** — konkreter Zielzustand, kein vages „werde besser"
3.**State & Memory** — was der nächste Zyklus wissen muss, ohne alles zu wiederholen
4.**Action Policy** — was der Agent ändern, aufrufen, delegieren, ausgeben darf
5.**Evidence** — Tests, Schema-Validierung, Zitate, Diffs, Metriken, Human Review
6.**Feedback** — kompakte, handhabbare Beschreibung, warum die Evidenz fehlschlug
7.**Stopping Rule** — Erfolg, Budgetlimit, Timeout, nicht behebbarer Fehler, Eskalation
**Kernprinzip:** *Loop on evidence, not on confidence.* „Der Agent sagt, er ist fertig" ist keine Stoppbedingung; „Tests grün, Links valide, Schema gültig, Reviewer zugestimmt" schon.
**Abgrenzung zum Prompt Engineering:** Ein Prompt sagt dem Modell, was es *während* eines Aufrufs tun soll. Ein Loop legt fest, was das System *danach* tut. Trade-off: Kosten und Latenz. Faustregel (Anthropic): einfachste funktionierende Architektur wählen; Loops nur dort, wo Fehlerkosten > Verifikationskosten.
**Definition:** Explizite Modellierung des Workflows als gerichteter Graph bzw. Zustandsmaschine. Knoten repräsentieren Arbeitsschritte, Kanten erlaubte Übergänge (Sequenz, bedingte Verzweigung, paralleles Fan-out, Joins, Zyklen, menschliche Interrupts). Der State traversiert den Graphen; die Topologie macht den Kontrollfluss prüfbar.
**Praxis-Bezug:** LangGraph (Low-Level-Orchestrierung für langlaufende, zustandsbehaftete Agenten, durable Execution, Human-in-the-Loop) und Microsoft AutoGen/GraphFlow (exakte Kontrolle über Agenten-Reihenfolge, deterministische Verzweigung, mehrstufige Prozesse mit Zyklen).
**Entscheidungen des Graph Engineers:**
- **Node Boundaries** — deterministische Funktion vs. LLM-Aufruf vs. Spezialagent vs. Human Review
- **Durability** — Checkpoint-Positionen, Wiederaufnahme nach Unterbrechung
**Wichtige Abgrenzung:** Graph Engineering hier = Engineering *graphbasierter Ausführung* — nicht Knowledge-Graph-Engineering (Entitäten und Relationen in Daten).
**Wann sich der Aufwand lohnt:** bei bedeutsamen Verzweigungen, Parallelarbeit, Freigaben, Recovery-Pfaden oder mehreren Spezialagenten. Warnung: Ein Graph kann Annahmen zu früh einfrieren.
## 3.1 Aktueller Praxis-Claim: Claude-Code-Teams und Graph Engineering
Ein X-Post von [@seeconvm](https://x.com/seeconvm/status/2096406550839537729) zitiert den Head of Claude Code mit der Aussage, 85 % der Engineers liefen mit Dutzenden oder Hunderten Agenten; die passende Methode sei „graph engineering“. Der verlinkte Teaser **Graph Engineering: Stop Chaining Your Agents** kritisiert lineare Agentenketten und stellt Graphen als Alternative dar.
Das ist ein aktuelles Praxis-Signal, keine verifizierte Anthropic-Statistik: Der Abruf liefert weder den vollständigen Beitrag noch eine Primärquelle für die 85-%-Zahl. Inhaltlich passt der Claim zur hier beschriebenen Graph-Ebene: Nicht mehr Agenten um ihrer selbst willen, sondern explizite Topologie, Parallelisierung und Join-/Routing-Regeln. Der „Output eines ganzen Teams durch einen Engineer“-Satz bleibt ein Produktivitäts- und Marketing-Claim.
Die Schichten sind verschachtelt: **Der Graph läuft im Harness; ein oder mehrere Loops leben im Graph; der Harness liefert State, Tools und Evaluatoren für die Loops.** Die Kategorien überlappen wie Software-Schichten — aber jede Ebene gibt dem Team einen anderen Hebel, wenn das System versagt.
- **Codex** — Compiler: übersetzt Shapes/Topologie in ausführbaren Code
- **beamnxw** — benennt erstmals die Umgebungsschicht darunter: **Harness Engineering (*environment*)**
**Bemerkenswerte Deckung:** Die in der Diskussion als „Bermuda-Dreieck" der Praxis beschriebene Restarbeit — State-Management, Auth, Token-Budgets, Rate-Limits, Logging — entspricht fast 1:1 beamnxws Harness-Komponenten (Persistence, Execution Control, Safety/Governance, Observability). Die Schicht war empirisch bereits identifiziert, bevor sie einen Namen hatte. Damit wird der Stack vollständig: **Harness → Loop → Graph, Codex als Compiler quer darüber.**
Auch das „10/90-Prinzip" wird gestützt: Die 90 % verteilen sich auf Loop-, Graph- und Harness-Arbeit; die 10 % Boilerplate fallen dem Compiler zu.
## 5. Kritik und Einordnung
- **Nicht orthogonal:** Ein Harness als Runtime enthält definitionsgemäß Loops, und der Graph ist eine optionale Architektur-Wette, keine Pflichtebene. Die „drei Ebenen" sind eine Nützlichkeits-Heuristik, keine saubere Schichtentrennung.
- **Synthese, nicht Forschung:** Der Artikel aggregiert Bekanntes (LangChain, OpenAI Agents SDK, AutoGen GraphFlow, Anthropic-Guides) zu einer Terminologie-Klärung. Sein Wert liegt in Begriffs-Hygiene und der Diagnose-Tabelle, nicht in neuen Erkenntnissen.
- **Praktischer Nutzen:** Die Ebene-nach-Symptom-Tabelle ist ein brauchbares Debugging-Werkzeug; die Kernaussage „Blame the layer that owns the failure, not the model" adressiert einen realen, häufigen Denkfehler.
## 6. Typische Fehler
1.**Graph bauen, bevor man die Arbeit versteht** — erst Traces aus einem einfachen Harness sammeln, dann stabile Pfade formalisieren.
2.**Dasselbe Modell schreiben und bewerten lassen** — Self-Review hat geteilte Blindspots; deterministische Checks bevorzugen, Reviewer-Kontext trennen, Human Approval bei hohen Auswirkungen.
3.**„Versuch's weiter" als Loop-Spezifikation** — unbegrenzte Retries sind ein Kostenleck; jeder Loop braucht messbares Ziel, frische Evidenz, Maximalversuche, Eskalationspfad.
4.**Harness als Sammelbecken** — mehr Tools und mehr Memory sind nicht automatisch besser.
5.**Das Modell für Orchestrierungsfehler verantwortlich machen** — kein Modell kompensiert verlässlich veralteten State, mehrdeutige Tool-Schemas, kaputte APIs oder fehlende Exit-Bedingungen.
## Quellen
- beamnxw (@beamnxw): *Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering*, X, 25.07.2026 — <https://x.com/beamnxw/article/2081022966645535079>
- [[../llm/deepseek-v4-pro-ga-harness-open-source.md]] — DeepSeek Harness v0.1 (Open-Source-Agent-Harness, Rivale zu Claude Code) + Deep-Dive-Video (Stephen G. Pope, 21.08.2026)
- [[nvidia-agenten-3d-scene-prep.md]] — NVIDIA-Referenzarchitektur: Codex orchestriert, Hermes-Subagents über NemoClaw, Omniverse Libraries als Werkzeugschicht — Harness-Pattern in einem Physical-AI-Kontext, inkl. Validierungs-Gate
