Eine Agent-Anfrage berührt zwölf Container. Nur einer führt ein Modell aus.

Die häufigste Reaktion auf unseren Quickstart lautet, zwölf Container seien viel für eine Demo. Der Einwand ist berechtigt, und die ehrliche Antwort besteht nicht darin, die Zahl zu verteidigen, sondern einen Agent-Lauf Dienst für Dienst durchzugehen und zu sagen, wofür jeder Container tatsächlich zuständig ist und welche Garantie beim Löschen verloren geht. Ein früherer Beitrag beantwortete, wie weit man kürzen kann. Dieser beantwortet, warum der Rest da ist.

Zuerst die Zahl korrigieren, denn es kursieren zwei verschiedene. Der Quickstart-Befehl nennt zwölf Dienste, die Compose-Datei definiert vierzehn. Tatsächlich starten dreizehn: minio-init steht nicht im Befehl, aber api hängt von dessen erfolgreichem Abschluss ab, also wird es hochgezogen, legt den Bucket an, schaltet den anonymen Zugriff ab und beendet sich. Der vierzehnte ist scheduler, von dem kein Dienst abhängt und den der Quickstart deshalb nie startet. Wie viele Dienste eine Compose-Datei definiert und wie viele tatsächlich laufen, sind zwei verschiedene Zahlen.

Drei Container sind einmalige Aufgaben, die enden, bevor die erste Anfrage eintrifft: migrate legt die Tabellen an, bootstrap den Administrator und den Tenant, minio-init den Objekt-Bucket. Sie kosten Startzeit, keinen Dauerbetrieb. Zwei weitere sind schlicht das, was demonstriert wird: api und web. Alles Übrige ist das Ausführungsjournal und die Grenzen darum herum.

Postgres ist dieses Journal. Ein Lauf wird in fünf Tabellen festgehalten, die den Lauf selbst, seine Schritte, seine Werkzeugaufrufe, seine Artefakte und seine Kosten abdecken. Das ist die physische Grundlage der beiden Zusagen, die die Plattform zu jeder Ausführung macht: Sie ist beobachtbar und sie ist wiederholbar. MinIO ist die andere Hälfte und hält die großen Objekte, während die Datenbank nur einen Storage-Key und einen SHA-256 behält. Beide sind zugleich die einzigen harten Readiness-Schranken: Fällt eine aus, meldet sich die Plattform als nicht bereit, statt Anfragen anzunehmen, die sie nicht protokollieren könnte.

Jeder verbleibende Container kauft genau eine Grenze. Vault hält Zugangsdaten in einem KV-v2-Store, damit sie weder in einem Prozess noch in einer dotenv-Datei landen. Redis cacht Berechtigungsentscheidungen mit fünf Minuten TTL, trägt den Rate-Limiter und den instanzübergreifenden Event-Bus. Milvus liefert die Vektorsuche, und etcd sei ausdrücklich genannt, weil es häufig missverstanden wird: Es ist der Metadatenspeicher von Milvus selbst, keine Abhängigkeit der Plattform. Eine weitere bewusste Asymmetrie: Ein Milvus-Ausfall lässt die Wissenssuche fehlschlagen, senkt aber die Readiness nicht.

Ein Container wird erst interessant, nachdem die Antwort bereits zurückgegeben wurde. Ereignisse aus einem Lauf werden in derselben Transaktion wie die Arbeit selbst persistiert; ausgeliefert werden sie danach vom Outbox-Dispatcher, mit Checkpoint-Idempotenz. Entfernt man ihn, wirkt während der Anfrage nichts kaputt, denn die Anfrage war bereits erfolgreich: Die Ereignisse bleiben einfach für immer pending, und nachgelagerte Konsumenten erhalten nichts. Ebenfalls wissenswert: Dieser Prozess und der Knowledge-Ingest-Worker sind derselbe Code wie api mit einem anderen Einstiegspunkt.

Gruppiert nach dem, was sie garantieren, statt nach ihrem Namen, ist der Dauerbetrieb klein: Zwei Container sind das Produkt, zwei tragen Journal und Artefakte physisch, zweieinhalb sind eine einzige Fähigkeit, nämlich Vektorsuche, einer ist Secret-Isolation, einer ist replikenübergreifende Verteilung und Cache, und zwei sind Hintergrundprozesse aus demselben Code. Genau ein Prozess der gesamten Topologie führt ein Modell aus. Das übrige Gewicht kauft eine einzige Sache: dass nach dem Lauf noch ein Nachweis existiert und dass ein Absturz auf halbem Weg keinen halben Zustand hinterlässt.

Ob sich das lohnt, hängt vom Vorhaben ab. Wer nur wissen will, ob ein Agent eine Aufgabe überhaupt zu Ende bringt, für den ist dieser Stack zu schwer; der frühere Beitrag zeigt, wie man auf vier dauerhafte Container kürzt. Geht der Agent in einen Prozess, den später jemand abstimmen muss, sind diese Container das, was man irgendwann selbst schreiben würde. Ein Vorbehalt: Dieser Rundgang ist eine statische Lektüre von Code und Compose-Datei, kein neuer Ende-zu-Ende-Lauf. Das Repository liegt auf github.com/soit-ai/soit, die vollständige Topologie in docker/docker-compose.yml.