Vom Agenten über den Loop zum Graphen: Eine Produktionsarchitektur für agentische Systeme

Ein viel geteilter X-Beitrag vom 18. August 2026 schreibt Andrew Ng einen zweistündigen Walkthrough zu und präsentiert eine nützliche Eskalation des technischen Umfangs: ein erster funktionierender Agent bei 9:14, Loops bei 33:11, Loops, die zu Graphen werden bei 1:02:46, Agenten, die ihren eigenen Code modifizieren bei 1:30:15, und eine Orchestrierungsebene, die das System bei 1:49:05 zusammenführt. Dieser Artikel nutzt diesen zeitlich gegliederten Entwurf als Ausgangspunkt für eine Produktionsarchitektur; er hängt nicht davon ab, ob die Zuschreibung korrekt ist.

Unabhängig davon, ob diese Begriffe zum kanonischen Vokabular werden, ist die Progression nützlich, da jeder Schritt eine andere systemtechnische Frage aufwirft. Ein einzelner Agent führt Fragen zu Fähigkeiten und Werkzeugnutzung ein. Ein dauerhafter Loop fügt Aspekte wie Status, Wiederherstellung, Kontext und Genehmigung hinzu. Ein Graph ergänzt Topologie, Koordination und Delegation. Selbstmodifikation wirft Fragen zu Verifizierung, Eingrenzung und Bereitstellung auf. Orchestrierung macht das Gesamtsystem zu einem Betriebsproblem.

1. Der erste Agent ist eine Fähigkeit; der Loop macht ihn zu einem System

Der erste Meilenstein im genannten Beitrag ist am leichtesten zu erkennen: einen Agenten zum Laufen bringen. Geben Sie einem Modell ein Ziel, eine Werkzeugschnittstelle und genügend Statusinformationen, um eine Aktion auszuwählen. Das ist der Moment, in dem ein Sprachmodell aufhört, nur ein Textgenerator zu sein, und beginnt, Teil eines Systems zu werden.

Doch die operative Komplexität entsteht nicht durch die einzelne Aktion. Komplexität tritt auf, wenn der Agent weitermachen muss: das Ergebnis beobachten, entscheiden, ob die Aufgabe erledigt ist, ein weiteres Werkzeug aufrufen, einen fehlgeschlagenen Aufruf überstehen, Kontext komprimieren, um Genehmigung bitten oder am nächsten Tag fortfahren.

Deshalb hat TrueFoundrys Artikel zum Thema Loop-Engineering vom Juni die Disziplin wie folgt definiert:

Dieser Ausdruck ist wichtig, weil er die Aufmerksamkeit von einem einzelnen „heroischen“ Prompt weglenkt. Sobald der Loop unbeaufsichtigt nützliche Arbeit leistet, werden die Designfragen zu gewöhnlichen Systemfragen: Wo liegt der Status, welche Aktionen sind wiederholbar, wie oft darf ein Fehler auftreten, wann muss ein Mensch eingreifen, welcher Code darf ausgeführt werden, welche Anmeldedaten sind erreichbar und wie wird ein Durchlauf später rekonstruiert?

2. Ein Graph ersetzt nicht den Loop; er ordnet Loops und andere Knoten an

Der nächste konzeptionelle Sprung im genannten X-Beitrag – Loops werden zu Graphen – ist der Punkt, an dem Hype die nützliche Technik verschleiern kann. Ein Graph bedeutet per Definition nicht „mehr Agenten“. Ein Produktionsgraph kann Agenten, deterministische Funktionen, Router, Joins, Warteschlangen, menschliche Kontrollpunkte, Evaluatoren, Datenbank-Schreibvorgänge und gewöhnliche Dienste enthalten.

TrueFoundrys Leitfaden zum Graph-Engineering vom Juli fasste die Beziehung in sieben Worten zusammen:

Der Graph oder Orchestrator verantwortet Fragen wie: Welcher Knoten wird als Nächstes ausgeführt? Können zwei Zweige parallel ausgeführt werden? Welches Ergebnis schaltet einen Join frei? Was passiert, wenn ein Zweig fehlschlägt? Welcher Agent darf an welchen anderen Agenten delegieren? Welcher Pfad erfordert einen menschlichen Kontrollpunkt? Ein mehrstufiger Loop innerhalb eines agentischen Knotens verantwortet eine andere Reihe von Fragen: welchen Kontext der Agent sieht, welches Werkzeug er auswählt, wie er mit Beobachtungen umgeht, wann er es erneut versucht und wann seine lokale Arbeit abgeschlossen ist.

Zuerst: Unterscheidung der zwei Bedeutungen von „Graph“

In den sozialen Medien wird der Begriff „agentische Wissensgraphen“ verwendet. Diese Formulierung kann zwei unterschiedliche Architekturen vermischen. Ein Wissensgraph repräsentiert Entitäten und Beziehungen in Informationen. Ein Ausführungsgraph für Agenten repräsentiert Akteure, Rechenknoten, Übergänge, Abhängigkeiten und den Arbeitsstatus. Das eine kann das andere speisen, aber sie beantworten unterschiedliche Fragen.

Wenn ein Forschungsagent einen Wissensgraphen abfragt und dann die Validierung an einen zweiten Agenten delegiert, ist der Wissensgraph Teil dessen, was das System weiß; der Ausführungsgraph beschreibt, was das System tut.

3. An den Kanten werden viele Unternehmensrichtlinien durchsetzbar

Ein Graph-Diagramm wird operativ, sobald Knoten und Kanten mit Befugnissen ausgestattet sind. Eine Kante kann bedeuten: „Modell aufrufen“, „dieses MCP-Tool ausführen“, „diesen Kundendatensatz an einen anderen Agenten übergeben“, „diesen Patch schreiben“ oder „dieses Artefakt bereitstellen“. Sobald diese Übergänge Konsequenzen haben, werden Topologie und Governance untrennbar miteinander verbunden – auch wenn die Knotenbewertung, der Graph-Zustand und die nachgelagerte Autorisierung weiterhin ebenso wichtige Bestandteile der Kontrollstrategie bleiben.

Der aktuelle Beitrag von TrueFoundry zum Thema Graph-Engineering fasst die Unternehmenshaltung in einem weiteren kurzen Satz zusammen:

‍