Wer heute Multi-Agent-Systeme baut, steht vor drei Problemen gleichzeitig: Wie isoliert man Agenten voneinander? Wie verhindert man, dass sie sich gegenseitig in die Quere kommen? Und wie strukturiert man den ganzen Stack, ohne fuer jede Teilaufgabe ein eigenes SaaS-Produkt einzubinden? Drei aktuelle Entwicklungen adressieren jeweils einen dieser Punkte.
Google Scion: Ein Hypervisor fuer Agenten
Google hat am 7. April 2026 Scion als Open-Source-Projekt veroeffentlicht (GitHub: GoogleCloudPlatform/scion). Das Projekt bezeichnet sich selbst als "Hypervisor fuer Agents" -- ein Orchestrierungs-Testbed, das mehrere spezialisierte Agenten als isolierte, gleichzeitig laufende Prozesse verwaltet.
Der zentrale Designentscheid: Isolation statt Constraints. Anstatt Agenten durch eingebettete Regeln einzuschraenken, laesst Scion sie frei operieren und erzwingt Grenzen auf Infrastrukturebene. Jeder Agent erhaelt eigene Container, eigene Git-Worktrees und eigene Anmeldedaten. Die Ausfuehrung ist lokal, auf Remote-VMs oder in Kubernetes-Clustern moeglich.
Konkret bietet Scion:
- Dynamische Aufgabengraphen mit paralleler Ausfuehrung, die sich zur Laufzeit weiterentwickeln
- Diverse Agent-Lebenszyklen: Langlebige Spezialisten-Agenten neben kurzlebigen, aufgabengebundenen Agenten
- Harnesses als Adapter fuer verschiedene Agent-Typen -- aktuell unterstuetzt: Claude Code, Gemini, OpenCode und Codex (teilweise)
- Container-Laufzeiten: Docker, Podman, Apple Container Runtime, Kubernetes
Google liefert ein Demo-Projekt mit ("Relics of the Athenaeum"), das zeigt, wie verschiedene Agenten kollaborativ Raetsel loesen -- inklusive dynamischem Agent-Spawning und geteilten Arbeitsbereichen.
Fuer Entwickler ist der Ansatz interessant, weil er die Sicherheitsfrage auf eine andere Ebene verlagert. Statt im Prompt zu definieren, was ein Agent nicht tun darf, begrenzt die Infrastruktur, was er tun kann. Das ist naeher an klassischer Betriebssystem-Isolation als an Prompt-Engineering.
Race Conditions: Das unterschaetzte Problem paralleler Agenten
Parallel laufende Agenten erzeugen ein Problem, das aus der klassischen Systemprogrammierung bekannt ist, aber in der AI-Welt oft ignoriert wird: Race Conditions. Wenn zwei Agenten gleichzeitig denselben Zustand lesen, modifizieren und zurueckschreiben, gewinnt der letzte Schreibvorgang -- und der andere geht verloren. Ohne Fehler, ohne Warnung.
Nahla Davies hat auf Machine Learning Mastery einen praxisnahen Leitfaden veroeffentlicht, der die gaengigen Loesungsmuster zusammenfasst:
- Locking: Optimistisches Locking (Versionstags pruefen vor dem Schreiben, bei Konflikten wiederholen) oder pessimistisches Locking (Ressource vor dem Lesen reservieren). Ersteres skaliert besser, wenn Konflikte selten sind.
- Queuing: Aufgaben in eine Queue schieben statt Agenten direkt auf gemeinsame Listen zugreifen zu lassen. Redis Streams, RabbitMQ oder Postgres Advisory Locks als Serialisierungspunkt.
- Event-Driven Architecture: Agenten reagieren auf Events statt gemeinsamen Zustand zu lesen. Agent A emittiert ein Event nach Abschluss, Agent B konsumiert es. Lose Kopplung reduziert das Zeitfenster fuer Konflikte.
- Idempotenz: Jede Operation mit einer eindeutigen ID versehen. Wiederholungen erzeugen kein abweichendes Ergebnis. Am besten von Anfang an einbauen -- nachruesten ist schmerzhaft.
Der Artikel betont einen Punkt, der fuer LLM-basierte Systeme besonders relevant ist: LLM-Agenten sind nicht-deterministisch in ihrer Laufzeit. Ein Agent antwortet in 200ms, ein anderer braucht 2 Sekunden. Orchestrierungsschichten, die das nicht beruecksichtigen, produzieren stille Datenkorruption.
Fuer die Praxis heisst das: Wer mehr als einen Agenten parallel laufen laesst, braucht mindestens Idempotenz und eine Form von Konflikterkennung. Das ist keine Ueberarchitektur, sondern die Baseline.
Output.ai: Ein Framework aus der Produktion
Output.ai verfolgt einen anderen Ansatz: Statt ein theoretisches Framework zu entwerfen, haben die Entwickler Muster aus ueber 500 produktiven AI-Agenten extrahiert und in ein Open-Source-TypeScript-Framework gegossen. Der Claim: Ein Framework statt einem Dutzend SaaS-Abonnements.
Die Kernkomponenten decken den gesamten Lebenszyklus eines AI-Agenten ab:
- Prompts: Verwaltung und Versionierung
- Evals: Evaluierung von Agent-Outputs
- Tracing: Nachvollziehbarkeit von Agent-Entscheidungen
- Cost Tracking: Kostenerfassung pro Agent und Aufruf
- Security: Sicherheitsschicht fuer Agent-Operationen
- Durable Execution: Zuverlaessige Ausfuehrung auch bei Ausfaellen
Der Ansatz ist pragmatisch: Anstatt das x-te Orchestrierungs-Framework fuer hypothetische Szenarien zu bauen, buendelt Output.ai die Infrastruktur, die Teams in der Praxis ohnehin zusammenstuecken -- Observability, Kosten, Sicherheit, Evaluierung. Das Framework laeuft auf Rails im Backend und React/TypeScript im Frontend.
Einordnung
Die drei Entwicklungen ergaenzen sich auf verschiedenen Ebenen:
| Ebene | Werkzeug | Fokus |
|---|---|---|
| Infrastruktur | Google Scion | Isolation und Scheduling von Agenten |
| Zuverlaessigkeit | Race-Condition-Patterns | Korrektheit bei paralleler Ausfuehrung |
| Betrieb | Output.ai | Observability, Kosten, Evaluierung |
Fuer Entwickler, die heute Multi-Agent-Systeme bauen, ist die Botschaft: Die Toolchain reift. Orchestrierung ist nicht mehr nur "mehrere Agenten starten und hoffen", sondern bewegt sich in Richtung ingenieurmaessiger Disziplin -- mit Isolation, Konfliktbehandlung und Produktions-Observability als den drei Saeulen.
Quellen
- Google Open-Sources Experimental Agent Orchestration Testbed Scion (InfoQ)
- GoogleCloudPlatform/scion (GitHub)
- Handling Race Conditions in Multi-Agent Orchestration (Machine Learning Mastery)
- Output.ai -- AI Development Framework