Agent = Model + Harness: Die fünf Ideen, die agentisches Engineering definieren

211 konkurrierende Definitionen hat Simon Willison gesammelt, bevor er sich auf eine festlegte: Ein LLM-Agent führt Werkzeuge in einer Schleife aus, um ein Ziel zu erreichen. Die Definition ist so knapp, dass sie fast enttäuschend wirkt. Aber sie verschiebt die gesamte Frage. Wenn der Agent selbst nur ein Loop ist, dann liegt alles, was zählt, im Drumherum.

Key Takeaways (TL;DR)

• Outer Loop besitzen statt Inner Loop optimieren: Die Verantwortung für das Ergebnis liegt beim Menschen, der die Evidenz prüft und die Freigabe erteilt. Nicht beim Modell.
• Systeme bauen statt Prompts tippen: Loop Engineering ersetzt die manuelle Prompt-Eingabe durch automatisierte Schleifen mit Auslösern, Verifikation und persistentem Zustand.
• Harness über Modellwahl stellen: Die meisten Agenten-Fehler sind Harness-Lücken. Investition in System-Prompts, Hooks und Memory schlägt den Wechsel auf ein besseres Modell.
• Spezifikationen als Multiplikator behandeln: Vage Anforderungen multiplizieren sich über parallele Agenten. TDD wird von guter Praxis zu unverzichtbarer Absicherung.
• Wahrgenommenen Speedup messen statt glauben: Die METR-Studie zeigt, dass Entwickler sich schneller fühlen, obwohl sie es nicht sind. Messung gehört zur Outer Loop.

Basiert auf “Agentic Engineering: Core Ideas” vom daily.dev Agentic AI Hub. Das Original findest du hier: https://daily.dev/agentic-ai-hub

Ein Agent ist ein LLM, eine Schleife und genug Tokens

Nach einem Jahr definitorischem Chaos hat sich die Branche auf eine simple Antwort geeinigt. Willison destillierte seine 211 Fundstücke auf einen Satz. Anthropics “Building Effective Agents” ergänzt eine nützliche Unterscheidung: Workflows führen LLMs durch vorgegebene Code-Pfade, Agenten lassen das Modell seinen eigenen Prozess steuern. Der Ratschlag von Anthropic ist bemerkenswert für ein Unternehmen, das die Modelle verkauft: Greife zur einfacheren Option und füge Komplexität nur dann hinzu, wenn sie die Ergebnisse messbar verbessert.

Thorsten Ball hat in “How to Build an Agent” einen funktionierenden Coding-Agenten in unter 400 Zeilen Go gebaut. Die Begründung: “It’s an LLM, a loop, and enough tokens.” Wenn der Loop selbst ein paar hundert Zeilen Boilerplate ist, dann lebt fast alles, was einen Agenten besser macht als den nächsten, in der Infrastruktur drumherum.

Die Outer Loop gehört dem Menschen, nicht dem Modell

Die nützlichste Zerlegung stammt von Addy Osmani. Die Inner Loop ist der Zyklus des Agenten: untersuchen, implementieren, verifizieren, wiederholen. Dort liegt die Modellfähigkeit, und dort sollte ein Mensch zunehmend nicht sein. Die Outer Loop ist der Ort, an dem ein Mensch entscheidet, ob die Arbeit sicher genug zum Ausliefern ist. Evidenz überquert diese Grenze. Eine Person fällt das Urteil.

“The model may write the line, but the Verdict is mine.”

Osmani komprimiert damit eine Haltung, die unabhängig davon Tradition hat. Willison zitiert gerne ein IBM-Trainingsdia von 1979: “A computer can never be held accountable. Therefore a computer must never make a management decision.” Verantwortung ist nicht übertragbar. Deshalb existiert die Outer Loop.

Was die Outer Loop konkret bedeutet: Qualität sichern durch Checks, die Evidenz produzieren. Das Urteil über Ship oder No-Ship auf Basis dieser Evidenz fällen. Und die Entscheidung im Nachhinein erklären können. Das Versagen, gegen das diese Struktur schützt, ist ein “Trust-Verification Gap”, das sich mit jeder Verbesserung der Agenten vergrößert. Agenten generieren schneller, als Menschen verifizieren können. Die praktische Konsequenz: Platziere dich in der Schleife, die Constraints setzt und Stichproben nimmt. Nicht in der Schleife, die den Code schreibt. Und baue genug Gegendruck auf (Tests, Audit-Logs, Sandboxes), damit die Outer Loop auf echten Daten urteilt.

Das deckt sich mit dem, was die Diskussionen beim CTO Craft Dinner bestätigt haben: Code Review ist der neue Engpass. Nicht weil es zu wenig Reviewer gibt, sondern weil Agenten schneller produzieren als Menschen prüfen können.

Loop Engineering baut das System, statt das Werkzeug zu halten

Loop Engineering ist das konstruktive Gegenstück zur Outer-Loop-Haltung. Hand-Prompting bedeutet, das Werkzeug permanent in der Hand zu halten: Prompt schreiben, Output lesen, nächsten Prompt schreiben. Der Mensch ist der Flaschenhals. Loop Engineering bedeutet, die Maschine einmal zu bauen und sie laufen zu lassen.

Osmani benennt fünf Bausteine: Automations (geplante Discovery und Triage), Worktrees (isolierte parallele Arbeitsbereiche), Skills (wiederverwendbares Projektwissen), Plugins/Connectors (Issue-Tracker, Slack, APIs) und Sub-Agents (getrennte Maker- und Checker-Rollen). Dazu kommt ein sechster: persistenter Zustand auf der Festplatte oder einem Board, weil Modelle zwischen Durchläufen alles vergessen.

Die Entwickler hinter Claude Code haben diesen Übergang bereits vollzogen. Boris Cherny promptet Claude nicht mehr. Er schreibt Schleifen, die Claude prompten. Drei Ebenen der KI-Interaktion, von Prompt Engineering über Context Engineering zu Loop Engineering, markieren den Weg vom Bediener zum Systemarchitekten.

Loops entfernen allerdings nicht die Verantwortung. Sie verschärfen drei Risiken. Unbeaufsichtigte Loops machen unbeaufsichtigte Fehler. Comprehension Debt wächst still. Und kognitive Kapitulation lockt. Osmani formuliert das Ethos so: Baue den Loop. Aber baue ihn wie jemand, der vorhat, der Engineer zu bleiben, nicht nur die Person, die auf Go drückt.

Ein brauchbares Modell mit großartigem Harness schlägt ein großartiges Modell mit schlechtem Harness

Wenn Loop Engineering die Praxis ist, dann ist der Harness das Objekt. Die Gleichung lautet Agent = Model + Harness, und ihre Konsequenz ist ernüchternd: Wenn du nicht das Modell bist, bist du der Harness. Alles, was ein Entwickler kontrolliert (System-Prompts, Tool-Definitionen, Sandboxes, Hooks, Memory-Dateien, Kontextmanagement-Strategie), ist Harness.

Dex Horthys 12-Factor Agents macht den Punkt aus Produktionserfahrung: Die meiste Software, die sich “Agent” nennt, ist in Wahrheit “mostly deterministic code, with LLM steps sprinkled in at just the right points.” Seine zwölf Faktoren laufen darauf hinaus, die eigenen Prompts, das Kontextfenster und den Kontrollfluss zu besitzen, statt den Loop eines Frameworks zu übernehmen. Das zuverlässige Ende des Spektrums sieht mehr nach gewöhnlicher Software aus, als die “autonomer Agent”-Rhetorik vermuten lässt.

Das Enterprise-KI-Experiment mit Faktor 93 hat genau das bestätigt: 420.000 Zeilen Code, 0 Prozent strukturelle Schulden. Der entscheidende Hebel war nicht das Modell, sondern der penibel gepflegte Harness aus Architektur- und Codierrichtlinien.

Zwei Designprinzipien reisen gut. Das Ratchet: Jeder Fehler wird zu einer Regel. Jeder Ausfall liefert eine permanente Verbesserung im Harness (ein Hook, eine Memory-File-Zeile, ein Test), die zum auslösenden Vorfall zurückverfolgbar ist. Und das Prinzip “success is silent, failures are verbose”: Hooks sprechen nur, wenn etwas bricht. Das hält den Feedback-Kanal sauber. Arbeite rückwärts vom gewünschten Verhalten. Wenn du nicht benennen kannst, welchem Verhalten eine Harness-Komponente dient, lösche sie. Und akzeptiere, dass Harnesses verderblich sind. Wenn Modelle besser werden, wird Scaffolding für alte Fehlermodi zu totem Gewicht. Die Komplexität schrumpft nicht. Sie verlagert sich.

Vage Spezifikationen multiplizieren sich über 30 parallele Agenten

Osmani reframed die Aufgabe als Fabrikbau: die Fabrik bauen, die die Software baut. Der Entwickler wird zum Spec-Architekten, Systemdenker und Qualitätsprüfer. TDD verschiebt sich von guter Praxis zu annähernd obligatorisch, weil Agenten darauf optimieren, Tests zu bestehen. Tests müssen kodieren, was passieren soll, nicht was aktuell passiert.

Die schärfste Warnung ist, dass unscharfes Denken sich nicht mehr nur verlangsamt, es multipliziert sich. Eine unklare Spezifikation an dreißig parallele Agenten gefüttert produziert dreißig unterschiedlich falsche Artefakte.

Steve Yegges Sechs-Wellen-Prognose ist die maximalistische Variante derselben Trajektorie und erfrischend offen über die Kosten. Agenten-Flotten “burn lots of LLM tokens, to the tune of $10-$12/hour at current rates.” Ein Stromrechnungspreis, der sich anfühlt wie Junior-Developer-Gehalt. Ob seine 5x-pro-Welle-Arithmetik einer Messung standhält, ist die Frage, die der nächste Abschnitt aufwirft.

An der Frontier stehen Long-Running Agents: Arbeit, die Stunden oder Tage über mehrere Kontextfenster spannt. Drei harte Probleme kehren wieder. Endlicher Kontext und der “Context Rot”, der die Qualität weit vor dem harten Limit verschlechtert. Kein persistentes Gedächtnis, wofür Anthropics Bild passt: “Engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.” Und Self-Grading Bias, bei dem Modelle häufiger “Ja, ich bin fertig” sagen, als sie sollten. Die stabilisierenden Techniken (Zustand auf der Festplatte statt im Kontext, Checkpoint-and-Resume, getrennte Planner/Worker/Judge-Rollen) sind dieselben, die jeden Agenten vertrauenswürdig machen.

19 Prozent langsamer, bei dem Glauben, schneller zu sein

Es lohnt sich, den Enthusiasmus mit Armin Ronachers “The Coming Loop” zu paaren. Ronacher ist grundsätzlich überzeugt, dass der Loop kommt, und grundsätzlich besorgt darüber. Seine Kritik an dem, was Loops heute produzieren, ist konkret. Harness-Level-Loops, die über das eigene “ich bin fertig” des Modells hinaus persistieren, erzeugen Code, der “too defensive, too complex, too local in its reasoning” ist. Modelle vermeiden starke Invarianten und sind, in Karpathys Formulierung, “mortally terrified of exceptions.” Sie fügen Fallbacks hinzu, statt ungültige Zustände unmöglich zu machen.

Das Ergebnis ist Code, der zu lokal denkt, um architektonisch inspiziert zu werden. Ronachers Schlussfolgerung ist nicht “Finger weg”, sondern eine Zwickmühle: Ausstieg ist unmöglich, weil Sicherheitsforscher und Wettbewerber Loops fahren und Verteidiger das auch müssen. Die eigentliche Frage ist nicht, ob man den Loop betritt, sondern ob man dabei das Engineering-Urteil behält.

Eine Messung hat einen harten Treffer gelandet. In der METR-Studie (einer randomisierten kontrollierten Studie) waren erfahrene Entwickler mit KI-Werkzeugen 19 Prozent langsamer. Sie glaubten vor und nach dem Experiment, schneller zu sein. Die Vorbehalte sind dokumentiert: Tooling von Anfang 2025, Chat-basierte Nutzung, Experten auf vertrauter Codebasis. Aber die Meta-Lektion bestätigt die These dieses Artikels in experimenteller Form. Wahrgenommener Speedup ist kein Beleg. Wer die Outer Loop besitzen will, muss auch die Messung besitzen.

5 Schritte zur Umsetzung

1. Outer Loop formalisieren: Definiere explizit, welche Checks ein Agent-Ergebnis durchlaufen muss, bevor es in die Codebasis gemergt wird. Tests, Lint, Review durch einen zweiten Agenten oder einen Menschen.
2. Harness als Artefakt behandeln: Sammle System-Prompts, Tool-Definitionen, Hooks und Memory-Dateien in einem versionierten Verzeichnis. Jeder Agenten-Fehler wird zu einer neuen Regel in diesem Artefakt.
3. Loop statt Prompt bauen: Identifiziere eine wiederkehrende Aufgabe (CI-Fehler-Triage, Dependency-Updates, Test-Migration) und automatisiere sie als Schleife mit harten Iterationsgrenzen und maschineller Verifikation.
4. Spezifikationen vor dem Agenten schärfen: Schreibe Tests, bevor du den Agenten startest. TDD ist nicht optional, wenn dreißig parallele Agenten auf eine Spezifikation losgelassen werden.
5. Wahrgenommene Produktivität messen: Vergleiche geschätzte und tatsächliche Durchlaufzeiten über mindestens vier Wochen. Die METR-Studie zeigt, dass Selbsteinschätzung allein kein verlässlicher Indikator ist.

Wer die Outer Loop nicht besitzt, besitzt das Ergebnis nicht. Das Modell ist austauschbar. Der Harness nicht.