Loop-Engineering auf Enterprise-Niveau: Von Laptop-Loops zu verwalteten Laufzeitumgebungen

In der ersten Juniwoche 2026 ordnete sich die Diskussion über KI-gestützte Programmierung um eine zentrale Idee neu. Peter Steinberger, Schöpfer des OpenClaw-Agentenprojekts, postete, dass die entscheidende Fähigkeit nicht mehr das Prompten von Coding-Agenten sei, sondern das Design der Loops, die diese steuern; Boris Cherny, Leiter von Claude Code bei Anthropic, beschrieb seine eigene Arbeit ähnlich: „Mein Job ist es, Loops zu schreiben.“ Addy Osmanis viel beachteter Essay gab dieser Praxis einen Namen – Loop Engineering – und eine Anatomie: Automatisierungen, Worktrees, Skills, Konnektoren, Sub-Agenten und externer Status. Die Idee ist real und verdient es, ernst genommen zu werden. Doch in der aktuellen Praxis ist es ein Muster für Einzelentwickler auf ihren Laptops – und die Lücke zwischen einem Loop in Ihrem Terminal und einem Loop, den ein Unternehmen unbeaufsichtigt um 3 Uhr morgens ausführen kann, ist genau das Thema dieses Beitrags.

Noor, eine Staff Engineer, baute den Loop, den heute jeder beschreibt: eine morgendliche Automatisierung, die nächtliche CI-Fehler und offene Issues ausliest, Korrekturen in isolierten Checkouts entwirft, diese von einem zweiten Agenten prüfen lässt, PRs öffnet und eine saubere Statusdatei hinterlässt, die festhält, was erledigt ist und was als Nächstes ansteht. Drei Wochen lang war es das beste Tool im Team – dann wurde es zum Gegenstand dreier unangenehmer Meetings. Die Finanzabteilung fragte, warum die Token-Kosten an einem Wochenende in die Höhe geschossen waren: Der Loop hatte zwei Tage lang enthusiastisch versucht, eine defekte Testumgebung zu reparieren, ohne dass jemand zusah. Die Sicherheitsabteilung fragte, wo die Zugangsdaten des Loops gespeichert waren: in einer Konfigurationsdatei auf Noors Laptop, die ihre persönlichen Token enthielt und um 6 Uhr morgens unter ihrer Identität lief. Und ihr Director stellte die Frage, auf die es keine Antwort gab: Vier weitere Ingenieure hatten das Muster kopiert, jeder auf seine eigene Weise – wie viele Loops hatte das Unternehmen also, worauf konnte jeder zugreifen und wer hatte das alles genehmigt? Der Loop funktionierte. Die Laufzeitumgebung war ein Laptop, und alles, was schiefging, ließ sich darauf zurückführen.

Dieser Beitrag nimmt Loop Engineering als eigenständige Disziplin ernst – was es ist, warum es tatsächlich die nächste Ebene der Softwareentwicklung darstellt und wo seine Tücken liegen – und führt dann die Analyse durch, nach der Noors Director implizit gefragt hatte: jedes Primitive des Loops, übersetzt von der Laptop-Konvention hin zu einer verwalteten Infrastruktur. Das Vokabular folgt Osmanis Essay und der begleitenden Diskussion; der Enterprise-Teil orientiert sich an der Agent Harness-Dokumentation von TrueFoundry. Die ehrliche Zusammenfassung der Lücke lässt sich in einem Satz ausdrücken: Loops sind ein Laufzeitproblem im Gewand eines Workflows.

1. Was Loop Engineering eigentlich ist

Wenn man den Diskurs auf das Wesentliche reduziert, ist die Definition kompakt. Zwei Jahre lang bedeutete die Arbeit mit einem Coding-Agenten, ihn an die Hand zu nehmen: Man schreibt einen Prompt, liest das Ergebnis, schreibt erneut – der Mensch ist der Loop. Loop Engineering ersetzt dies durch ein durchdachtes System: Etwas findet die Arbeit (ein Zeitplan, der CI-Prozesse, Issues oder Fehler-Feeds scannt), übergibt sie an einen Agenten, prüft das Ergebnis mit einem Verifizierer, der nicht der Ersteller ist, protokolliert das Geschehene in einem Status, der über die Konversation hinaus Bestand hat, und entscheidet, was als Nächstes zu tun ist. Man baut es einmal; danach steuert es die Agenten automatisch. Osmani ordnet es „eine Etage über“ dem Harness Engineering ein – der Harness führt einen Agenten durch eine Aufgabe; der Loop entscheidet, welche Aufgaben anstehen, wann sie ausgeführt werden und was als erledigt gilt. Manche Autoren beschreiben es als zwei verschachtelte Loops: einen inneren Loop, der Arbeit gemäß einer Spezifikation verrichtet, und einen äußeren Loop, der die Umgebung beobachtet und die nächste Spezifikation schreibt.

Wenn Ihnen das aus dieser Serie bekannt vorkommt, sollte es das auch – der Loop ist das Plan→Aktion→Beobachtung-Muster, das eine Ebene nach oben gehoben wurde, mit derselben Anatomie, die wir in unserem Deep Dive zum Thema Harness auseinandergenommen haben: Abbruchbedingungen (hier: „ausführen, bis die Tests bestehen“, beurteilt durch ein separates Modell), Fehlerbehandlung und Status. Simon Willison schrieb bereits im September 2025 über das Design agentischer Loops; was sich Mitte 2026 änderte, wie Osmani anmerkt, ist, dass die Primitiven aufhörten, eine Ansammlung persönlicher Bash-Skripte zu sein, und begannen, Teil von Produkten zu werden – genau der Moment, in dem eine Praxis aufhört, ein Hack zu sein, und zur Infrastruktur wird. Infrastruktur, wie wir sehen werden, mit den Anforderungen, die Infrastruktur eben mit sich bringt.

2. Die Anatomie: Sechs Primitive

Osmanis Analyse – die sich nahezu deckungsgleich auf die Codex-App und Claude Code übertragen lässt, wobei diese Konvergenz seine interessanteste Beobachtung ist – unterteilt den Loop in sechs Teile. Automatisierungen sind das Herzstück: Prompts, die nach Zeitplan ausgeführt werden, Erkennung und Triage übernehmen und Ergebnisse in einem Posteingang zusammenführen; dazu kommen „Run-until-done“-Primitive, bei denen ein Ziel so lange verfolgt wird, bis eine überprüfbare Bedingung erfüllt ist. Isolierte Arbeitsbereiche (im Falle der Programmierung Git-Worktrees) verhindern, dass parallele Agenten bei der Bearbeitung derselben Dateien kollidieren. Fähigkeiten – das SKILL.md-Muster – kodifizieren Projektwissen einmalig, damit der Loop nicht in jedem Zyklus Ihre Konventionen neu ableiten muss. Konnektoren, die auf MCP basieren, binden den Loop an reale Systeme an – das ist der Unterschied zwischen einem Agenten, der sagt „Hier ist die Lösung“, und einem Loop, der den PR öffnet und das Ticket aktualisiert. Unteragenten trennen den Ersteller vom Prüfer, denn das Modell, das den Code geschrieben hat, bewertet seine eigene Arbeit zu wohlwollend. Und externer Status speichert, was erledigt ist und was als Nächstes ansteht, da das Modell zwischen den Durchläufen alles vergisst und das Gedächtnis außerhalb des Kontexts liegen muss.

Zwei Dinge fallen auf, bevor wir diese Liste übersetzen. Erstens ist fast nichts davon neuartige Maschinerie – Zeitpläne, Isolierung, verpacktes Wissen, Integrationen, Delegation und dauerhafter Status sind die ältesten Konzepte im Betrieb, die lediglich neu um ein Modell herum angeordnet wurden. Zweitens, und das ist wichtiger: Jedes Primitiv ist eine Berechtigungserteilung. Eine Automatisierung ist eine dauerhafte Erlaubnis, nach Zeitplan zu handeln; ein Konnektor ist ein dauerhafter Zugriff auf ein reales System; ein Unteragent ist eine delegierte Identität. Auf einem Laptop sind diese Berechtigungen unsichtbar. Im Maßstab eines Unternehmens sind sie die entscheidende Frage.

3. Eine ehrliche Einschätzung, wann sich Loops lohnen

Die Diskussion ist erst wenige Tage alt und hat bereits einen gesunden skeptischen Flügel, der Gehör finden sollte, bevor wir zur Unternehmensübersetzung übergehen – denn eine schlechte Idee in eine verwaltete Infrastruktur zu übersetzen, führt nur zu verwalteter Verschwendung. Die Bedingungen der Praktiker selbst, unter denen sich Loops auszahlen, wie sie sich in frühen Kommentaren herauskristallisierten: Die Aufgabe wiederholt sich (ein Loop amortisiert die Designkosten über mehrere Durchläufe; für eine einmalige Aufgabe ist ein guter Prompt schneller); die Überprüfung ist automatisierbar („alle Tests bestanden und Lint ist sauber“ ist eine echte Abbruchbedingung, „sieht gut aus“ nicht); das Token-Budget kann die Verschwendung verkraften (Osmanis eigener Essay beginnt mit der Kostenwarnung, und Noors Wochenendrechnung ist der klassische Vorfall); und der Agent verfügt bereits über die Werkzeuge, die für die Aufgabe erforderlich sind. Fehlt nur einer dieser Punkte, kostet der Loop mehr, als er einbringt.

Es gibt zudem eine tieferliegende Warnung, die bei der Begeisterung für Brute-Force-Loops oft übersehen wird: Fehlerraten summieren sich. Ein Loop, der fünf Schritte verkettet, von denen jeder zu 95 % zuverlässig ist, läuft nur in etwa drei Vierteln der Fälle sauber durch – und die Fehler eines unbeaufsichtigten Loops summieren sich im Status, auf dem der nächste Durchlauf aufbaut. Deshalb ist die Trennung von Ersteller und Prüfer tragend und nicht nur dekorativ, und deshalb ist Willisons alter Witz – ein Agent als ein LLM, das in einer Endlosschleife seine Umgebung zerstört – das sollte man sich als Erinnerung über den Automatisierungs-Tab kleben. Das ist kein Argument gegen Schleifen, sondern die Feststellung, dass eine Schleife ein Produktionssystem ist – und genau so behandeln wir sie im weiteren Verlauf dieses Beitrags.

4. Die Enterprise-Lücke: Der Laptop ist die falsche Laufzeitumgebung

Betrachten wir nun Noors drei Meetings als technisches Review. Lebenszyklus: Ihre Schleife lief lokal auf ihrem Rechner – sie bricht ab, sobald der Laptop zugeklappt wird, übersteht keinen Absturz während der Ausführung und kann nicht für eine dreitägige Genehmigungsphase pausieren, da es keine dauerhafte Infrastruktur für den Prozess gibt. Ein frühes Playbook hat genau hier die Grenze gezogen: Sobald eine Schleife nachts um 3 Uhr ohne offenes Terminal laufen, Abstürze überstehen und unbegrenzt auf eine menschliche Reaktion warten muss, verlässt man den Bereich der einfachen Tools und betritt den Bereich der Laufzeitumgebungen. Zugangsdaten: Die Schleife lief unter Noors Identität – mit ihren Tokens in einer Klartext-Konfiguration, die ihre Berechtigungen nach Zeitplan nutzte und in keinem Audit-Log von Noor selbst zu unterscheiden war; eine dauerhaft laufende Automatisierung, die die Schlüssel einer Person besitzt, ist das Problem der nicht-menschlichen Identität im Kleinen. Kosten: Nichts stand zwischen der Schleife und der Abrechnung des Anbieters – kein Budget, kein Ratenlimit, keine Zuordnung pro Ausführung; die Kosten wurden erst auf der Rechnung entdeckt. Inventar: fünf Ingenieure, fünf verschiedene Kopien, kein zentrales Verzeichnis – unsere Governance für Coding-Agenten und die Geschichte der unkontrollierten Agenten-Ausbreitung, die durch die Hintertür der Produktivitäts-Tools Einzug hält.

Nichts davon sind Fehler im Design der Schleifen; es sind Eigenschaften des Laptops als Laufzeitumgebung, die so lange unsichtbar bleiben, bis die Schleife wichtig genug wird. Die Lösung besteht nicht darin, das Muster zu verbieten – Verbote führen nur zu Schatten-IT –, sondern diesen sechs Grundelementen eine Umgebung zu geben, die für unbeaufsichtigten, mandantenfähigen und auditierten Betrieb ausgelegt ist. Genau diese Übertragung leistet der Rest dieses Beitrags.

5. Die Grundelemente, übertragen auf eine verwaltete Laufzeitumgebung

Hier ist die Übersetzung, Element für Element, mit dem Agent Harness von TrueFoundry als praktischem Beispiel. Fähigkeiten dasselbe SKILL.md-Artefakt, jedoch veröffentlicht im Skills Registry mit Versionierung, Herkunftsnachweis und RBAC, bei Bedarf eingebunden – kodifiziertes Wissen als verwalteter Katalog statt als Ordner auf fünf Laptops. Connectors werden zum MCP Gateway: dieselben MCP-Server, erreichbar über eine Registry mit zentraler Authentifizierung, tool-spezifischem RBAC, Sicherheitsvorgaben und nutzerbezogener OAuth-Delegierung – mit begrenzten, rotierbaren Zugangsdaten statt irgendwelcher Tokens aus Noors Konfigurationsdatei. Sub-Agents werden im Harness zu Sub-Agents: Jeder Prüfer oder Explorer mit eigenem isolierten Kontext, begrenztem Tool-Zugriff und Trace – die Trennung von Ersteller und Prüfer mit einer Identitätsgrenze, nicht nur einer Prompt-Grenze. Isolierte Arbeitsbereiche werden zur Sandboxdes Harness: eine sichere Ausführungsumgebung pro Lauf – das Worktree-Konzept verallgemeinert zu „Jeder Agent erhält seine eigene Maschine.“ Status wird zu einem dauerhaften, plattformseitig gespeicherten Laufzeitstatus, der Abstürze und das Zuklappen von Laptops übersteht. Und Automatisierungen werden zu getriggerten Abläufen: dieselbe Agentendefinition, die nach Zeitplan oder Ereignis via REST-API oder SDK aufgerufen wird, wobei die Ergebnisse in Traces und Benachrichtigungen landen statt in einem Terminal-Verlauf.

Der strukturelle Unterschied, den die Übersetzung bietet, ist der, den der Laptop nicht leisten kann: nirgendwo Schlüssel im Loop. Agentendefinitionen referenzieren Modelle, MCP-Server und Skills über ihren Namen; Provider-Anmeldedaten liegen im AI Gateway, Tool-Authentifizierungen im MCP Gateway – einmalig konfiguriert durch das Plattform-Team. Noors Loop, auf diese Weise neu aufgebaut, läuft als eigenständige Instanz – ein registrierter Agent mit eigener Identität und Berechtigungen – und die Frage „Worauf kann dieser Loop zugreifen?“ wird zu einer Konfigurationsabfrage statt zu einem archäologischen Projekt.

Noors Morgen-Loop als verwaltete Agentendefinition (illustrativ)

agent:
  name: morning-triage-loop
  model: claude-sonnet-4-6            # by name — keys live at the gateway
  instructions: ./triage.md@v4         # versioned scaffold
  skills: [ci-triage-runbook@v2]       # from the Skills Registry, RBAC'd
  mcp_servers: [github, ci, linear]    # via MCP Gateway: scoped, rotatable auth
  subagents:
    - { name: fix-drafter,  mcp_servers: [github] }
    - { name: fix-reviewer, mcp_servers: [] }      # checker ≠ maker, read-only
  harness:
    max_steps: 60
    max_tokens_per_run: 1_500_000      # the weekend incident, capped
  approvals: { merge_pr: pause_for_human }          # waits days if it must
trigger: { schedule: "0 6 * * 1-5" }   # the heartbeat — no laptop required

6. Unbeaufsichtigt durch Design: Freigaben, Leitplanken und Abbruchbedingungen

Das entscheidende Merkmal eines Loops ist, dass niemand zuschaut. Die Aufgabe der Laufzeitumgebung ist es daher, dieses „Niemand schaut zu“ sicher zu machen. Drei Mechanismen übernehmen diese Last. Human-in-the-Loop-Freigaben: Das System hält einen kritischen Tool-Aufruf an – etwa das Mergen eines PRs oder das Ändern eines Produktionssystems – und speichert den Status des Laufs dauerhaft, bis jemand zustimmt; der Loop bricht nicht ab, nur weil ein Mensch das Wochenende genießt. Entscheidend ist: Destruktive Tools werden einmalig zentral im MCP Gateway für das gesamte Unternehmen markiert – die Richtlinie gilt automatisch für jeden Loop, anstatt darauf zu vertrauen, dass sich jeder der fünf Entwickler daran erinnert, sie zu konfigurieren. Leitplanken: Jeder Modell- und Tool-Aufruf durchläuft die Vor- und Nachprüfungen des Gateways – PII-Filter, Inhaltsrichtlinien, benutzerdefinierte Regeln –, sodass ein Loop, der um 6 Uhr morgens echte Tickets bearbeitet, genauso geprüft wird wie eine interaktive Sitzung um 14 Uhr. Abbruchbedingungen: „Run-until-done“ ist nur so sicher wie seine Grenzen. Schrittbegrenzungen, Token-Budgets und die Erkennung von Stillständen sind daher Teil der Konfiguration und keine bloße Hoffnung – der Unterschied zwischen „der Loop hat konvergiert“ und „der Loop stoppte, weil das Budget erschöpft war“, wobei der Trace Ihnen genau verrät, was zutrifft.

‍