Wie eine Agent Runtime gebaut ist, die man betreiben kann
Technischer Deep Dive für Platform- und Infrastruktur-Engineers. Control Plane, Execution-Modell, Kontextverwaltung und die Grenzen — ohne Marketingschicht darüber.
- Control Plane und Data Plane sind getrennt: Die Control Plane hält Entscheidungen, Identitäten und Zustand; ein Worker der Data Plane kann jederzeit verschwinden, ohne dass ein Lauf verloren geht.
- Jeder Lauf ist ein Event Log mit Snapshots: Ein Snapshot wird nach 50 Ereignissen, nach 60 Sekunden Laufzeit oder beim Wechsel des Sub-Agenten geschrieben, die Wiederaufnahme spielt nur den Rest ein.
- Agenten sind eigene Principals: Zugangsdaten gelten standardmäßig zehn Minuten, werden je Lauf ausgestellt und sind nach RFC 8707 an genau ein Zielsystem gebunden.
- Fremde MCP-Server laufen isoliert: Eigener Container, kein Host-Dateisystem, keine Persistenz zwischen Aufrufen, ausgehende Verbindungen nur zu namentlich gelisteten Zielen.
- Die Architektur hat Grenzen: Abschnitt 11 nennt die Anforderungen, für die sie die falsche Wahl ist.
/01Systemarchitektur
Die Control Plane ist klein, gesichert und hochverfügbar: Entscheidungen, Identitäten, Zustand. Die Data Plane ist groß, austauschbar und volatil: Rechenlast. Ein Worker kann jederzeit verschwinden, ohne dass ein Lauf verloren geht.
Möglich macht das der Scheduler. Er hält keine Ergebnisse, sondern Leases: Ein Worker bekommt einen Lauf befristet und muss verlängern. Läuft das Lease ab, übernimmt der nächste. Die Registry liefert zur Laufzeit, welche Werkzeuge und Agent Cards eine Identität nutzen darf — versioniert und signaturgeprüft.
Komponente anklicken — oder einen Lauf durchspielen.
/02Execution-Modell
Ein Lauf ist eine Zustandsmaschine mit persistiertem Verlauf: Jeder Schritt schreibt ein Ereignis, bevor er wirkt. Der Zustand ist die Faltung dieser Ereignisse — keine Variable, die verloren gehen kann.
Event-Sourcing und Snapshotting
Das Event Log ist die Wahrheit, Snapshots beschleunigen die Wiederaufnahme: nach 50 Ereignissen, 60 Sekunden oder beim Wechsel des Sub-Agenten. Große Tool-Rückgaben liegen im Objektspeicher; das Ereignis trägt nur Hash, Größe und Schema.
Idempotenz und Exactly-once
Jeder Schritt mit Seiteneffekt bekommt einen deterministischen Schlüssel aus Lauf-ID, Schrittname und Versuchszähler. Ein idempotenzfähiges Ziel liefert beim zweiten Aufruf dasselbe Ergebnis statt einer zweiten Buchung. Ist das Ziel nicht idempotenzfähig, schreibt die Runtime vorher tool.attempted — und wiederholt nach einem Absturz nicht blind, sondern fragt nach, prüft oder eskaliert.
Ausfall mitten im Tool-Call
Der Worker verschwindet, während ein schreibender Aufruf unterwegs ist:
- Lease läuft ab, der Scheduler gibt den Lauf frei.
- Neuer Worker lädt Snapshot und Restlog.
- Er findet
tool.attemptedohnetool.okodertool.failed. - Idempotenzfähig: erneuter Aufruf mit demselben Schlüssel. Sonst Statusabfrage — oder Eskalation an einen Menschen.
Deshalb bestehen wir bei jedem Konnektor auf Idempotenz oder Statusabfrage.
/03Context und Memory-Layer
Kontext ist die teuerste und flüchtigste Ressource im System. Drei Regeln halten ihn klein und bezahlbar.
Kompaktierung bei langen Läufen
Drei Stufen, jede durch einen Schwellwert ausgelöst: Tool-Rückgaben durch Zusammenfassung plus Referenz ersetzen; abgeschlossene Teilaufgaben zu einem Absatz verdichten; erst zuletzt modellgestützt zusammenfassen. Die ersten beiden Stufen sind deterministisch, die dritte kostet Tokens und Genauigkeit.
Vektorsuche oder strukturierter Abruf
Vieles, was als RAG gebaut wird, ist eine Datenbankabfrage: „Alle offenen Rechnungen dieses Kunden“ ist ein SELECT, keine Ähnlichkeitssuche. Vektorsuche nur für Freitext — mit Metadatenfilter und Quellenangabe im Ergebnis.
Cache-Ökonomie
Prompt-Caching wirkt nur, wenn der stabile Teil vorn steht: Systeminstruktion, Werkzeugbeschreibungen, Organisationswissen, laufbezogene Fakten, zuletzt der Verlauf. Ein Zeitstempel an der falschen Stelle zerstört den Cache für den ganzen Lauf.
/04Tool-Layer und MCP
MCP ist der vertikale Bus: ein Agent, viele Werkzeuge. Transport ist Streamable HTTP — Fortschrittsmeldungen bei langsamen Werkzeugen, funktioniert mit vorhandenen Proxys.
Schema-Validierung in beide Richtungen. Rückgaben fließen direkt in den Modellkontext; wir prüfen sie gegen das Schema, begrenzen die Größe und markieren sie als Daten, nicht als Instruktion.
Discovery läuft zur Laufzeit über die Registry, gefiltert nach Scopes, Vertrauensstufe und Version. Neue Werkzeuge brauchen kein Deployment, zurückgezogene hinterlassen keine toten Verweise — deshalb läuft die Eval-Suite auch gegen die Registry.
/05Agent-zu-Agent
A2A ist der horizontale Bus: Agent zu Agent, über Organisationsgrenzen hinweg. Seit das Protokoll bei der Linux Foundation liegt und ACP darin aufgegangen ist, ist das Risiko eines toten Formats gering.
Jeder Agent veröffentlicht eine signierte Agent Card unter /.well-known/agent-card.json; ohne Signaturprüfung lenkt ein gefälschter Eintrag Aufgaben samt Kontext an fremde Endpunkte. Delegation überträgt befristete Rechte, nie eine Vollmacht: Der Partner liefert einen Vorschlag, der ausführende Schritt bleibt bei uns.
/06Identität und Autorisierung
Der Agent ist ein eigener Principal: eigene Kennung, eigene Scopes, eigene Spur im Audit-Log. Technisch OAuth 2.1 mit Resource Indicators nach RFC 8707 — ein Token gilt für genau ein Zielsystem.
Credentials gelten zehn Minuten und werden je Lauf ausgestellt. Sub-Agenten erhalten nur eine Teilmenge der Scopes des Eltern-Laufs; die Policy Engine lehnt alles andere ab, egal was im Prompt steht.
Ein kompromittierter Retrieval-Agent kann lesen, was er lesen durfte — und keine Gutschrift auslösen, weil er den Scope nie hatte. Mehr dazu: Agent Identity und Least Privilege.
/07Sandboxing und Containment
Fremde MCP-Server laufen isoliert: eigener Container, kein Host-Dateisystem, keine fremden Zugangsdaten, begrenzte Laufzeit, keine Persistenz, ausgehende Verbindungen nur zu gelisteten Zielen.
Ein MCP-Server oder Prompt-Template kann sich zur Laufzeit anders verhalten als deklariert; schon die Tool-Beschreibung ist ein Einflusskanal, weil sie im Modellkontext landet. Dagegen: gepinnte Versionen, Signaturprüfung, Größenbegrenzung der Rückgaben, Trennung von Daten und Instruktion.
Das begrenzt den Schaden, verhindert aber nicht jede Beeinflussung — siehe Abschnitt 11.
/08Observability
Jeder Tool-Call, jeder Modellaufruf und jede Freigabe erzeugt einen OpenTelemetry-Span: Identität, Lauf-ID, Schritt, Werkzeug, sanitisierte Parameter, Policy-Entscheidung, Latenz, Tokens, Modell, Cache-Treffer, Fehlerklasse. Sanitisiert wird im Collector, nicht in der Anwendung.
Deterministisches Replay spielt einen Lauf gegen die aufgezeichneten Antworten neu ab: Fehlentscheidung reproduzieren, Prompt-Änderung an einem realen Fall prüfen, Policy gegen die Vergangenheit testen. Jeder produktive Fehlschlag wird Testfall in der CI.
/09Kostenmodell
Gesteuert wird nicht der Token, sondern der erfolgreich abgeschlossene Task — inklusive Fehlversuchen und Eskalationen. Nur diese Zahl lässt sich mit dem bisherigen manuellen Prozess vergleichen.
Ein Budget-Cap je Lauf beendet stille Schleifen mit budget_exceeded; der Zustand bleibt einsehbar. Darunter wirken zwei Hebel:
- Model-Routing. Routine mit dem kleinen Modell, Eskalation zum großen per expliziter Regel — nicht durch das Modell selbst, sonst eskaliert es immer.
- Cache-Quote und Kompaktierung. Kontext nach Volatilität sortieren, verlustarme Stufen zuerst — siehe Abschnitt 3.
/10Benchmark
Interner Testaufbau, keine Zusicherung. Wer die Zahlen für eine Entscheidung braucht, misst in der Sandbox mit eigenen Werkzeugen nach.
- Aufbau: drei Worker-Nodes, synchron replizierter Zustandsspeicher, Werkzeuge und Modelle im selben Rechenzentrum.
- Last: 1.000 Läufe je Szenario, 20 gleichzeitig, aufgezeichnete reale Eingaben.
- Recovery: harter Abbruch eines Workers zu zufälligem Zeitpunkt; gemessen bis zum ersten Ereignis nach der Wiederaufnahme.
- Kosten: Modell plus Plattformanteil, Fehlversuche eingerechnet, ohne Einrichtung.
- Nicht gemessen: menschliche Freigaben, externe Werkzeuge, Kaltstart.
| Szenario | p50 | p95 | Recovery nach Node-Verlust | Kosten je 1.000 Läufe |
|---|---|---|---|---|
| 3 Tool-Calls, kleines Modell | 1,9 s | 4,2 s | 3,1 s | 27 € |
| 7 Tool-Calls, Routing klein → groß | 4,4 s | 9,8 s | 3,4 s | 71 € |
| 12 Tool-Calls, 1 Freigabe | 6,8 s | 14,1 s | 3,6 s | 118 € |
| Gateway-Overhead je Aufruf | 4 ms | 8 ms | – | – |
/11Wofür das nicht gebaut ist
Für diese Anforderungen ist die Architektur die falsche Wahl:
- Echtzeit unter 50 Millisekunden. Persistenz, Policy und Trace kosten Zeit; dafür braucht es den direkten Modellaufruf.
- Training und Feintuning. Die Plattform betreibt Inferenz. Training gehört auf dedizierte GPU-Infrastruktur — KI on-premise.
- Agenten in fremden Web-Oberflächen. Schlecht verifizierbar, brechen bei jeder Layoutänderung, kaum autorisierbar. Wo eine API existiert, nutzen wir die API.
- Prozesse ohne Erfolgskriterium. Ohne Erfolgsdefinition gibt es weder Eval-Suite noch Nutzenbeleg. Das sagen wir vor dem Projekt.
- Vollständiger Schutz vor Prompt Injection. Gibt es nicht. Wir begrenzen Rechte, deckeln Beträge und binden irreversible Schritte an Menschen.
Wie es weitergeht
Der nächste Schritt ist kein Gespräch, sondern ein Lauf — oder der Blick auf die Argumente gegen uns.
- QuickstartVom leeren Verzeichnis zum ersten Lauf in fünf Minuten
- PreiseBetriebspauschale und Nutzungssätze für Ihr Volumen
- Vergleich EigenbauWann ein selbst gebauter Agent-Stack die bessere Wahl ist
- Vergleich HyperscalerBedrock, Vertex und Foundry gegen eine Runtime in Deutschland
- Vergleich Agent-SaaSFertige Agentenplattformen gegen betreibbare Infrastruktur
- RuntimeDie Plattformschicht hinter diesem Deep Dive im Überblick
Selbst nachmessen.
Wir stellen eine Sandbox mit Ihren Werkzeugen bereit, ziehen während eines Laufs einen Node ab und zeigen Ihnen Recovery-Zeit, Span-Baum und Kosten je Lauf — an Ihren Daten, nicht an unseren.
30 Minuten, unverbindlich und direkt mit einem technischen Ansprechpartner.