NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Ampel auf leuchtendem Loop mit Schild Governed Agent Loop

Was ist ein Governed Agent Loop?

Ein Governed Agent Loop ist ein KI Coding Workflow, in dem ein Agent nur innerhalb eines vorher freigegebenen Scopes arbeitet und jeden Schritt mit nachprüfbarer Evidenz belegt. Der Agent bedient den Ablauf selbst, der Mensch entscheidet über Scope, Risiko und dauerhaftes Projektwissen.

Der Begriff stammt aus der Praxis rund um Coding Agenten wie OpenCode und Claude Code. Er beschreibt keine neue Technik, sondern eine Disziplin: Der Loop bleibt derselbe, aber er bekommt Tore. Freigabe vor Implementierung, deklarierte Validierung, aufgezeichnete Ergebnisse, geprüfte Lerneffekte.

Abzugrenzen ist der Governed Agent Loop vom reinen Agent Looping. Agent Looping erklärt die technische Schleife aus Modellaufruf, Aktion und Beobachtung. Governance beschreibt, wer diese Schleife anhält, wer sie freigibt und was aus ihr dauerhaft im Projekt landet.

Inhalt

Governed Agent Loop mit NCA: Schnelle Hilfe vom Experten

Bei Never Code Alone laufen Coding Agenten produktiv. Claude Code und OpenCode schreiben bei uns Symfony Code, lassen PHPUnit und Cypress laufen, lesen Fehler und korrigieren. Genau dabei sehen wir, wo Governance fehlt: Der Agent baut mehr um als besprochen, meldet grün und niemand kann hinterher sagen, welche Regel eigentlich gegriffen hat.

Wir helfen Teams, diesen Ablauf in den Griff zu bekommen. Über Vibe Coding Consulting bauen wir Scope und Freigabe in bestehende Prozesse ein, über Vibe Coding Training onboarden wir ganze Teams. Die Vibe Coding Best Practices dienen als Nachschlagewerk, Quality Gates für KI Code setzen Regeln automatisch durch. Wo die Validierung fehlt, greifen CI CD Pipelines und automatisiertes KI Code Review. Ist der Schaden schon da, hilft ein Codebase Audit für KI generierten Code.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum mehr Memory das Problem nicht löst

Der übliche Reflex ist bekannt. Der Agent wiederholt einen Fehler, also bekommt er mehr Gedächtnis. Es entstehen MEMORY.md, project-rules.md, agent-notes.md, lessons-learned.md. Irgendwann liegt alles im Kontext: alte Entscheidungen, temporäre Workarounds, kopierte Transkripte, verworfene Ideen und Regeln, an deren Freigabe sich niemand erinnert.

Der Agent hat dann mehr Kontext. Besseren Kontext hat er nicht. Das eigentliche Problem ist nicht das Vergessen, sondern die fehlende Unterscheidung. Ein Transkript ist kein Gedächtnis. Eine Notiz ist keine Regel. Ein Fund ist keine Vorgabe. Und ein erfolgreicher Patch ist noch lange keine Projektkonvention.

Genau hier setzt die Idee des Governed Agent Loop an. Statt einem wachsenden Haufen Kontext bekommt der Agent einen Ablauf mit klaren Übergängen: Aufgabe, Planvorschlag, menschliche Freigabe, gezielter Abruf von Wissen, Umsetzung, Prüfung, festgehaltene Evidenz, überprüftes Lernen. Wer das mit Context Window Management kombiniert, spart nebenbei Tokens.

Die vier Ebenen von Agenten Wissen

Ein sauberer Loop braucht mehr als eine Datei. Er braucht Ebenen mit unterschiedlicher Haltbarkeit. Wer alles in eine Memory Datei kippt, verliert die Herkunft der Information. Und ohne Herkunft ist keine Information vertrauenswürdig.

Die Ebenen bauen aufeinander auf. Was in der Session steht, ist flüchtig. Was zum Finding wird, ist belegte Beobachtung. Was als Vorschlag formuliert wird, wartet auf eine Entscheidung. Und nur was ein Mensch freigibt, wird dauerhafte Guidance im Projekt.

Ebenen im Governed Agent Loop

Ebene Inhalt Haltbarkeit
Session Annahmen, Checkpoints, offene Fragen, Zwischenentscheidungen Flüchtig, wird nach der Aufgabe gelöscht
Finding Belegte Beobachtung aus der Umsetzung, noch ohne Bewertung Bleibt als Evidenz, wird geprüft
Proposal Vorschlag zur Änderung der Projektregeln, mit Empfehlung Wartet auf menschliche Entscheidung
Guidance Freigegebene Projektregel, die künftige Aufgaben steuert Dauerhaft, bis jemand sie ersetzt oder löscht

Scope zuerst: Das Work Brief vor dem Code

Ein Coding Agent sollte nicht damit anfangen, ein Ticket zu lesen und kreativ zu ergänzen, was im Ticket fehlt. Er sollte mit einem expliziten Work Brief starten. Darin stehen Ziel, erlaubter Scope, ausdrückliche Non Goals, betroffene Bereiche, geforderte Validierung und offene Annahmen.

Der Mensch antwortet darauf ganz normal. Freigegeben. Oder: Nein, die Repository Schicht bleibt unangetastet. Oder: Freigegeben, aber die öffentliche API bleibt unverändert. Der Agent hält fest, welche konkrete Revision freigegeben wurde.

Der wichtige Punkt: Eine Freigabe gilt für ein konkretes Work Brief, nicht dauerhaft für eine Ticket Nummer, deren Bedeutung sich still verschieben kann. Ändert sich der Plan wesentlich, muss der Agent neu vorlegen. Das klingt nach Bürokratie, bis ein Agent ein technisch beeindruckendes Refactoring liefert, das niemand bestellt hat.

Code: 
          
Ziel:
Ungültige Statuswechsel bei Bestellungen ablehnen.

Scope:
Order State Validierung und die zugehörigen Tests.

Non Goals:
Keine Umgestaltung des Order Aggregats.
Keine Änderung der öffentlichen API.

Validierung:
composer phpstan
composer test

Validierung wird vorher deklariert, nicht hinterher erfunden

Wenn ein Agent fertig meldet, ist das kein Beleg. Die geforderten Prüfbefehle stehen bereits im Work Brief. Der Agent führt genau diese Befehle aus und schreibt die echten Ergebnisse gegen die freigegebene Planrevision fest. Welche Befehle das sind, hängt vom Projekt ab: PHPStan, PHPUnit, Coding Standards, bei uns zusätzlich Cypress für End to End Tests aus dem Cypress Workshop.

Eine grüne Testsuite beweist außerdem nicht, dass der Agent im Scope geblieben ist. Tests laufen nach einem unnötigen Umbau genauso grün durch wie nach einem gezielten Bugfix. Code Validierung und Workflow Verifikation sind deshalb zwei verschiedene Dinge.

Der Workflow prüft zusätzlich: Wurde der aktuelle Plan freigegeben? Blieb die Umsetzung im Scope? Gehört die Evidenz zur aktuellen Revision? Wurden geforderte Reviewschritte erledigt? Ist offenes Risiko dokumentiert? Eine polierte Zusammenfassung ersetzt das nicht. Im Formulieren guter Zusammenfassungen sind Coding Agenten längst hervorragend.

Code: 
          
Freigegebener Scope:
Order State Validierung und zugehörige Tests

Beobachtete Änderungen:
src/Order/OrderService.php
tests/Order/OrderServiceTest.php

Validierung:
composer phpstan -> bestanden
composer test -> bestanden

Unerwartete Pfade:
keine

Selection ist nicht Usage: Der blinde Fleck bei Kontext Metriken

Ein Recall System wählt für eine Aufgabe passende Regeln aus. Die Auswahl allein beweist gar nichts. Die Regel kann hilfreich gewesen sein, irrelevant, sogar schädlich, oder sie wurde schlicht nie gelesen.

Genau dieser letzte Fall ist der wichtige. Eine Regel wird für eine Recherche eingeblendet, aber während der Umsetzung nie konsultiert. Wer diesen Unterschied nicht festhält, verwandelt Auswahlstatistiken still in Nutzungsstatistiken. Die Kennzahlen beschreiben dann einen Ablauf, den es nie gab.

Die Trennung ist simpel: Selection heißt, das System hat etwas geliefert. Usage heißt, der Agent hat es benutzt. Outcome heißt, es hat geholfen oder eben nicht. Erst diese drei Werte zusammen ergeben eine Grundlage, um den Kontextabruf zu verbessern. Sonst zählt man nur, wie oft eine Datei irgendwohin kopiert wurde.

Lernen bleibt Chefsache

Nach der Aufgabe darf der Agent Funde festhalten. Ein Fund ist Evidenz. Er ist nicht automatisch eine neue Regel. Der Agent darf Belege sammeln, wiederkehrende Muster erkennen, Widersprüche in bestehenden Regeln melden und einen Vorschlag vorbereiten. Er darf seinen eigenen Vorschlag nicht still zur Projektregel befördern.

Die möglichen Ausgänge sind überschaubar: hinzufügen, ersetzen, löschen, ablehnen, oder gar kein dauerhaftes Lernen. Der letzte Fall ist der häufigste und wird am meisten unterschätzt. Ein behobener Bug offenbart nicht zwangsläufig eine wiederverwendbare Projektregel. Manchmal ist die richtige Schlussfolgerung einfach, dass der Bug behoben wurde.

Das klingt nach übertriebener Genauigkeit für einen Statusnamen. Ist es nicht. Wenn Lebenszyklus Zustände die falschen Verben benutzen, hören Audit Trails langsam auf zu beschreiben, was tatsächlich passiert ist. Wer rules.md und AGENTS.md pflegt, kennt das Problem: Die Regeldatei wächst, aber niemand weiß mehr, warum eine Zeile drinsteht.

agent-loop: Die PHP Umsetzung von Lars Moelleken

Der Begriff Governed Agent Loop bekommt durch das Open Source Projekt agent-loop von Lars Moelleken eine konkrete Form. Moelleken ist ein bekannter Name in der deutschen PHP Community, Maintainer von Paketen wie portable-utf8 und Stringy, und arbeitet in Voerde am Niederrhein, also direkt vor unserer Haustür in Duisburg.

agent-loop ist eine PHP 8.3 CLI unter MIT Lizenz, die mehrere fokussierte Pakete bündelt: agent-kanban für Aufgabenzustände, agent-session als flüchtiges Arbeitsgedächtnis, agent-recall-compiler für die gezielte Auswahl von Projektregeln, agent-map für kompakte Codeinformation und agent-learning für das kontrollierte Lernen. Statisch geprüft wird das Ganze mit PHPStan auf Level 8.

Der interessanteste Teil ist die Bedienung. Die CLI ist ausdrücklich nicht die Benutzeroberfläche. Der Entwickler tippt keine Freigabebefehle, er sagt einfach: Passt so, freigegeben. Der Coding Agent erkennt die Freigabe und schreibt sie über den Workflow fest. Dafür liefert das Projekt Skills, die der Agent je nach Phase lädt, statt ein riesiges Workflow Dokument in jeden Task zu ziehen. Wie so etwas aufgebaut ist, zeigt unsere Seite zum SKILL.md Format.

Code: 
          
composer require --dev voku/agent-loop

vendor/bin/agent-loop init scaffold --dry-run
vendor/bin/agent-loop init scaffold

vendor/bin/agent-loop init sync-skills --agent=codex

Für wen sich ein Governed Agent Loop lohnt

Nicht jedes Team braucht sofort ein eigenes Workflow Paket. Wer allein an einem kleinen Projekt arbeitet, kommt mit klaren Prompts und einem sauberen Review weit. Der Aufwand rechnet sich, sobald mehrere Menschen und mehrere Agenten auf dieselbe Codebasis zugreifen und niemand mehr rekonstruieren kann, warum eine Änderung so aussieht.

Besonders geeignet ist der Ansatz für regulierte Umgebungen und für Enterprise Teams, die Nachvollziehbarkeit brauchen. Wer belegen muss, wer welchen Scope freigegeben hat und welche Prüfung dazu gelaufen ist, bekommt hier eine Struktur statt einer Sammlung von Chatverläufen. Das passt zu dem, was wir unter Vise Coding mit Guardrails beschreiben.

agent-loop selbst setzen wir bei Never Code Alone nicht in Production ein. Wir ordnen das Projekt ein und halten die Prinzipien dahinter für richtig: freigegebener Scope, deklarierte Validierung, getrennte Wissensebenen, menschlich geprüftes Lernen. Diese Prinzipien funktionieren unabhängig von der Sprache und lassen sich auch in Python, TypeScript oder direkt in bestehenden CI CD Pipelines abbilden.

At some point, memory becomes landfill.

Lars Moelleken, PHP Open Source Maintainer, Autor von voku/agent-loop – Distill Coding Agent Learnings auf dev.to

Governed Agent Loops in NCA Projekten

Wir arbeiten täglich in Agent Loops. Claude Code und OpenCode schreiben Code, lassen Tests laufen, lesen Fehler und korrigieren. Was wir dabei immer wieder sehen: Der Loop selbst ist selten das Problem. Das Problem entsteht dort, wo niemand vorher gesagt hat, wie weit der Agent gehen darf, und wo hinterher niemand belegen kann, was tatsächlich geprüft wurde.

In der Beratung bauen wir deshalb erst die Tore, dann die Geschwindigkeit. Scope vor Implementierung, feste Prüfbefehle in der Pipeline, klare Trennung zwischen Notiz und Regel. Wie das im Alltag aussieht, zeigen unsere Seiten zu Agentic Coding, zu Code Qualität mit KI Agenten und zu den Kontrollstrategien für den KI Einsatz.

Für Teams, die gerade erst einsteigen, ist der schnellste Weg das Vibe Coding Onboarding. Wer bereits ein Projekt hat, das aus dem Ruder gelaufen ist, findet Hilfe unter Vibe Coding Projekt retten. Wir lernen uns kennen, schätzen den Aufwand und rechnen minutengenau ab.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zum Governed Agent Loop

Die wichtigsten Fragen aus Beratungsgesprächen rund um Scope, Evidenz und Freigabe bei KI Coding Agenten.

Was ist ein Governed Agent Loop 2026?

Ein Governed Agent Loop ist ein KI Coding Workflow mit festen Toren. Der Agent legt zuerst ein Work Brief mit Ziel, Scope und geforderter Validierung vor. Ein Mensch gibt frei. Danach setzt der Agent um, führt genau die deklarierten Prüfbefehle aus und hält die Ergebnisse als Evidenz fest. Am Ende entscheidet wieder ein Mensch, ob etwas dauerhaftes Projektwissen wird.

Warum reicht eine MEMORY.md Datei 2026 nicht mehr aus?

Weil eine einzige Datei die Herkunft der Information zerstört. Darin landen Transkripte, Workarounds, verworfene Ideen und echte Regeln nebeneinander. Der Agent bekommt dadurch mehr Kontext, aber nicht besseren. Sobald ein Team mehrere Agenten und mehrere Menschen auf derselben Codebasis hat, braucht es getrennte Ebenen für Session, Finding, Vorschlag und freigegebene Guidance.

Wie unterscheidet sich das 2026 von normalem Agent Looping?

Agent Looping beschreibt die technische Schleife: Modell aufrufen, Aktion wählen, Werkzeug ausführen, Ergebnis beobachten, weitermachen. Governance beschreibt, wer diese Schleife startet, wer sie stoppt und was aus ihr dauerhaft im Projekt bleibt. Der Loop bleibt derselbe, er bekommt nur Tore. Beides gehört zusammen, ist aber nicht dasselbe.

Muss ich 2026 CLI Befehle für Freigaben tippen?

Nein. Das ist der zentrale Punkt hinter dem Ansatz. Du sagst dem Agenten in normaler Sprache, dass der Plan passt oder dass die Repository Schicht unangetastet bleibt. Der Agent übersetzt das in Workflow Zustände. Die CLI liefert im Hintergrund deterministische Übergänge und prüfbare Artefakte, ist aber nicht die Bedienoberfläche.

Welche Rolle spielt Validierung 2026 im Loop?

Die geforderten Prüfbefehle stehen vor der Implementierung fest. Der Agent führt sie aus und schreibt die echten Ergebnisse gegen die freigegebene Planrevision. Wichtig: Grüne Tests beweisen nur, dass der Code funktioniert. Sie beweisen nicht, dass der Agent im vereinbarten Scope geblieben ist. Beides muss getrennt geprüft werden.

Was ist der Unterschied zwischen Selection, Usage und Outcome?

Selection heißt, das System hat eine Regel für die Aufgabe ausgewählt. Usage heißt, der Agent hat sie tatsächlich konsultiert. Outcome heißt, sie war hilfreich, irrelevant oder sogar schädlich. Wer diese drei Werte vermischt, misst am Ende nur, wie oft eine Datei irgendwohin kopiert wurde, und optimiert an der Realität vorbei.

Darf ein Agent eigene Lernvorschläge selbst freigeben?

Nein. Der Agent darf Belege sammeln, Muster erkennen, Widersprüche melden und einen Vorschlag mit Empfehlung vorbereiten. Die Entscheidung, ob daraus eine dauerhafte Projektregel wird, bleibt beim Menschen. Sonst wächst die Regelbasis unkontrolliert und niemand kann später sagen, wer welche Regel warum eingeführt hat.

Was ist voku agent-loop?

agent-loop ist ein Open Source PHP 8.3 Projekt von Lars Moelleken unter MIT Lizenz. Es bündelt mehrere Pakete für Aufgabenzustände, flüchtiges Arbeitsgedächtnis, gezielten Regelabruf, kompakte Codeinformation und kontrolliertes Lernen hinter einer einzigen CLI. Dazu kommen Skills, die ein Coding Agent je nach Phase lädt, statt ein großes Workflow Dokument in jeden Task zu ziehen.

Setzt Never Code Alone agent-loop in Production ein?

Nein. Wir ordnen das Projekt editorial ein und halten die Prinzipien dahinter für richtig. In unserem eigenen Stack arbeiten wir mit Claude Code und OpenCode, mit PHPStan, PHPUnit und Cypress in der Pipeline. Die Governance Ideen setzen wir dort direkt um, ohne an ein bestimmtes Paket gebunden zu sein.

Funktioniert das auch ohne PHP?

Ja. Die Prinzipien sind sprachunabhängig: freigegebener Scope, deklarierte Validierung, getrennte Wissensebenen, menschlich geprüftes Lernen. In Python lässt sich das mit Ruff, mypy und pytest genauso abbilden wie in JavaScript Projekten. Entscheidend ist nicht das Werkzeug, sondern dass die Tore existieren und dass Belege zur freigegebenen Planrevision gehören.

Ab welcher Teamgröße lohnt sich der Aufwand?

Wer allein an einem kleinen Projekt arbeitet, kommt mit klaren Prompts und sauberem Review weit. Interessant wird es, sobald mehrere Menschen und mehrere Agenten auf dieselbe Codebasis zugreifen. Spätestens wenn niemand mehr rekonstruieren kann, warum eine Änderung so aussieht, ist die fehlende Governance teurer als ihr Aufbau.

Wie fange ich in einem bestehenden Projekt an?

Fang mit einem Schritt an: Lass den Agenten vor jeder Aufgabe ein Work Brief mit Scope und Non Goals vorlegen und gib es bewusst frei. Danach kommt die deklarierte Validierung in der Pipeline. Erst zum Schluss die Trennung von Notiz, Fund und Regel. Alles auf einmal umzustellen scheitert meistens am Alltag.