--- created: 2026-07-26 updated: 2026-07-26 sources: - other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md tags: [concept, agents, architecture, harness-engineering, loop-engineering, graph-engineering, orchestration, beamnxw] people: [beamnxw] institutions: [langchain, openai, anthropic, microsoft] --- # 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. **Bestandteile eines ernsthaften Harness:** - **Context Injection** — System-Prompt, abgerufene Fakten, Konversationszustand, Skills, Policies - **Action Surfaces** — APIs, Browser, Shells, Code-Interpreter, Datenbanken, MCP-Tools - **Persistence** — Dateien, Checkpoints, Sessions, Progress-Logs, Git-Historie, Langzeitgedächtnis - **Execution Control** — Timeouts, Retries, Budgets, Model-Routing, Subagent-Spawning, Approval-Gates - **Safety & Governance** — Permissions, Isolation, Allow-Lists, Secret-Handling, menschliche Autorisierung - **Observability** — Traces, Tool-I/O, Zustandsübergänge, Kosten, Latenz, Evaluation **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. **Verwandte Wiki-Seite:** [[agent-loops.md]] (Steinberger Loop-Engineering) ## 3. Graph Engineering **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 - **State Schema** — was Knoten lesen/schreiben dürfen; Merging paralleler Updates - **Routing Conditions** — welche Evidenz Arbeit vorwärts, rückwärts, seitwärts oder zur Eskalation schickt - **Concurrency** — was parallel läuft, was joinen muss, koordinierte Ressourcen - **Cycles & Exits** — legale Retries, Maximalversuche, Zyklus-Sicherheit - **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. **Verwandte Wiki-Seiten:** [[graph-based-agents.md]], [[architecture-triade.md]] (Kopadze Shape-Vokabular) ## 4. Zusammenspiel der Ebenen 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. **Diagnose-Tabelle (Symptom → Ebene → wahrscheinlicher Fix):** | Symptom | Ebene | Fix | |---|---|---| | Agent kommt nicht sicher an Daten/Tools | Harness | Tool-Vertrag, Permissions, Sandbox, Context Injection | | Agent vergisst Fortschritt über Sessions | Harness | Durable State, Checkpointing, Progress-Artefakte | | Erster Versuch nah dran, aber unzuverlässig | Loop | Externer Grader, deterministische Tests, begrenzte Retries | | Arbeitet nach Erfolg weiter / stoppt vor Beweis | Loop | Evidenzbasierte Terminalzustände, Budget-Stoppregeln | | Spezialisten müssen in kontrollierter Reihenfolge laufen | Graph | Explizite Knoten, Kanten, Routing, Joins | | Fehler in mehrstufigem Prozess schwer lokalisierbar | Graph + Harness | State-Traces entlang der Graph-Knoten | | Workflow ändert sich zu oft für festes Diagramm | Einfacherer Harness | Kontrolle modellgetrieben lassen, Graph später | ### Einordnung in die Architektur-Diskussion Der Artikel fügt der zuvor diskutierten Triade eine bislang unbenannte Basisschicht hinzu: - **Steinberger** — Loop Engineering, konzeptionell (*feedback*) - **Kopadze** — Graph-Shape-Vokabular, Design-Patterns - **LangGraph** — Graph-Implementation (*flow*) - **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 — - LangChain: *The Anatomy of an Agent Harness*; *The Art of Loop Engineering*; LangChain/LangGraph 1.0 - OpenAI: *Agents SDK*; *A practical guide to building agents* - Microsoft: *AutoGen GraphFlow (Workflows)*; AutoGen Studio - Anthropic: *Building Effective AI Agents* - Kuratiert von Bernd das Bot, übernommen von Hector, 26.07.2026 ## Verwandte Wiki-Seiten - [[architecture-triade.md]] — Steinberger, Kopadze, LangGraph + Codex - [[agent-loops.md]] — Loop-Engineering (Steinberger) - [[graph-based-agents.md]] — Graph-basierte Agenten (LangGraph) - [[architecture-triade.md]] — Kopadze Shape-Vokabular + Architecture Triade - [[../../architecture/agent-orchestration.md]] — Agenten-Orchestrierung