Unsere Agent-Schleife hat 239 Zeilen. Framework und Runtime sind nicht dieselbe Schicht.

Der Begriff Agent-Plattform hat inzwischen mindestens drei verschiedene Schichten verschluckt: die Bibliothek, mit der man einen Agenten schreibt, die Engine, die ihn ausführt, und die Ebene, die ihn regiert. Die meisten Diskussionen über Agent-Werkzeuge sind zwei Menschen, die verschiedene Fragen beantworten. Der eine sagt, er habe einen Agenten in drei Zeilen gebaut; der andere will wissen, wer den Aufruf freigegeben hat, der gestern um fünfzehn Uhr hinausging. Beide haben recht, und keiner spricht über dieselbe Schicht.

Wir werden die Interna anderer nicht bewerten, denn dafür fair zu sein hieße, ihren Code so genau zu lesen, dass man sich das Urteil verdient. Dieser Beitrag tut deshalb zwei andere Dinge: Er beschreibt, wofür die Framework-Schicht üblicherweise zuständig ist, was unstrittig ist, und er nimmt unser eigenes Repository als Probe für die Runtime-Schicht, wo jede Behauptung mit Datei und Zeilennummer kommt. Die Probe ist github.com/soit-ai/soit, Apache 2.0, beim Commit 3a57ae1.

Zählen wir zuerst die eigene Agent-Schleife. Planer, Executor und Verifizierer ergeben zusammen 239 Zeilen. Der Dienst, der diese 239 Zeilen umschließt, hat 1.617, und seine Import-Liste verrät, wofür sie draufgehen: ein Workspace-Wächter, ein Freigabe-Hauptbuch, ein Rate-Limiter, ein Werkzeugausführungsdienst mit Leases und Idempotenzschlüsseln, ein Trace-Writer, eine Freigaberegel, ein Werkzeug-Resolver. Die Schleife selbst ist ein einziges while. Eine Zeile Schleife, sechzehnhundert Zeilen drumherum, und fast keine davon handelt davon, wie der Agent denkt.

Die Grenze zwischen beiden Schichten ist kein Diagramm, sondern ein Port. Jeder Werkzeugaufruf passiert ein Policy-Gateway von 475 Zeilen, bevor er einen Adapter erreicht, und dort wohnen die unangenehmen Fragen. Nicht, ob sich die Agent-Logik schön liest, sondern ob ein Wiederholungsversuch dasselbe Ticket zweimal eröffnet, wenn das nachgelagerte System einen Idempotenzschlüssel nicht beachtet. Genau deshalb sind Aufrufe an dieser Grenze höchstens einmal.

Man könnte zu Recht einwenden, wir hätten den Governance-Code einfach hinter die eigene Schleife geschoben. Die Antwort ist das zweite Ausführungsmodell im selben Repository: eine DAG-Workflow-Engine mit 6.269 Zeilen, strukturell nichts wie eine Agent-Schleife. Sie erreicht Werkzeuge über denselben Werkzeug-Port und Modelle über denselben Modell-Port. Zwei unverwandte Ausführungsmodelle, ein Satz Garantien, das ist die operative Definition einer Schicht. Governance ist eine Eigenschaft des Ports und nicht der Schleife, und deshalb nimmt ein Austausch dessen, was darüber liegt, keine der zehn Prüfungen darunter weg.

Schichtung landet üblicherweise in der Dokumentation und verrottet im Code, also übernimmt hier ein Werkzeug die Aufsicht. Der erste Import-Vertrag im Repository verbietet dem Kernel, die API, die Module, die Adapter, die Infrastruktur oder die Verdrahtung zu importieren. Braucht der Kernel Produkt- oder Infrastrukturdaten, muss er über Provider-Schnittstellen gehen, die aus der Verdrahtungsschicht registriert werden. Das sind die laufenden Kosten einer Grenze, die am Leben bleiben soll, und sie werden von der Continuous Integration bezahlt statt von Disziplin.

Der ehrliche Teil: Jene Workflow-Engine überschneidet sich sehr wohl mit Orchestrierungs-Frameworks, und etwas anderes zu behaupten wäre albern. Sie hat einen Compiler, eine Variablenauflösung, Knoten-Executoren, einen Wiederaufnahmepfad und einen Reaper. Die genaue Aussage lautet nicht, dass wir keine Framework-Mechanik bauen, sondern dass wir nur den nötigen Teil bauen und ihn denselben Regeln unterwerfen wie jeden anderen Aufrufer.

Was heißt es also praktisch, kein konkurrierendes Framework zu sein? Werkzeuge, die für ein Framework geschrieben wurden, lassen sich über MCP registrieren, und von da an passiert jeder ihrer Aufrufe dieselben Prüfungen. Dienste lassen sich als HTTP-Plugins anhängen. Das Frontend muss nicht ausgetauscht werden, weil die Interaktion ein AG-UI-Ereignisstrom ist. Wichtiger als all das ist, was fehlt: Es gibt keinen Einstiegspunkt, der einen von jemand anderem geschriebenen Agenten komplett hostet. Ihre Schleife läuft weiterhin in Ihrem Prozess. Regiert wird die Hand, die sie ausstreckt, also der Werkzeugaufruf, der Modellaufruf und die ausgehende Anfrage, nicht die Überlegung dahinter.

Das Framework entscheidet, wie ein Agent denkt; die Runtime entscheidet, ob der Moment zählt, in dem er die Hand ausstreckt. Diese beiden Anliegen konkurrieren nicht, denn sie wirken nicht einmal auf derselben Zeitskala: das eine auf die Tage, die man mit Schreiben verbringt, das andere auf jede spätere Ausführung. Der einzige echte Wettbewerb ist der um Aufmerksamkeit, und der Wechsel vom ersten zum zweiten kommt meist zu spät, nämlich nach dem ersten Vorfall.