# Was ist AI Agent Orchestration? Der schwierige Teil sind gemeinsamer Zustand und Handoffs

> Canonical: https://vxi.me/de/posts/ai-agent-orchestration-after-assistants/
> Locale: de-de
> Published: 2026-03-30
> Updated: 2026-10-07
> Markdown: https://vxi.me/de/posts/ai-agent-orchestration-after-assistants.md

Wenn nur ein Agent verwendet wird, sind die meisten Koordinationsprobleme überschaubar. Task geben, Tools bereitstellen, Tests ausführen lassen, Ergebnis prüfen. Die eigentlichen Schwierigkeiten beginnen meist erst, wenn Codex, Claude Code, Cursor und einige automatisierte Worker gleichzeitig dasselbe Repository verändern.

Die ersten Fehler haben dann oft wenig damit zu tun, welches Modell intelligenter ist. Es sind ganz normale Kollaborationsfehler. Claude nimmt an, Codex habe noch nicht begonnen, und editiert dieselbe Datei. Ein geplanter Job wurde eingerichtet, also behandelt ein anderer Agent das als Beweis dafür, dass er bereits gelaufen ist. Eine Anfrage wurde im Chat gesendet, aber der Empfänger hat Ownership nie wirklich übernommen. Ein Agent arbeitet von einem alten Commit aus, während der nächste so fortfährt, als sei dieser Zustand noch aktuell.

Noch ein zusätzlicher Orchestrator löst diese Probleme nicht automatisch. Routing beantwortet nur eine Frage: Wer soll den Task als Nächstes bekommen? Zuverlässige Multi-Agent-Arbeit braucht eine zweite Ebene: **Wer besitzt die Arbeit jetzt, welcher Zustand ist kanonisch, wurde der Handoff tatsächlich akzeptiert, besitzt die zugewiesene Umgebung die nötigen Fähigkeiten und wer hat den Abschluss verifiziert?**

Ein nützliches Beispiel ist das [central message board des microcredit-agent-testbed](https://github.com/scottonchain/microcredit-agent-testbed/issues/15). Das Projekt koordiniert Hermes, Claude Code und eine Codex/ChatGPT-Lane über ein öffentliches Issue plus ein kanonisches World Model. Die Domäne ist dabei nicht das Interessante. Interessant ist das Protokoll: Eine Anfrage ist nicht dasselbe wie akzeptierte Ownership, ein Zeitplan ist kein Beweis für Ausführung und erfolgreiche Konfiguration beweist nicht, dass ein späterer Lauf erfolgreich war.

Das hat verändert, wie ich Agent Orchestration beschreibe. Früher lag mein Fokus vor allem darauf, Arbeit auf spezialisierte Rollen aufzuteilen. Inzwischen denke ich, dass damit die Ebene fehlt, auf der Orchestration zu echter Engineering-Arbeit wird: **Routing ist nur der Einstieg; gemeinsamer Zustand und explizite Handoffs machen das System zuverlässig.**

## Orchestration beginnt mit Ownership, nicht mit mehr Agents

OpenAIs aktuelle Anleitung zu [Orchestration and handoffs](https://developers.openai.com/api/docs/guides/agents/orchestration) macht eine wichtige Unterscheidung. In einem Muster erhält ein Spezialist einen Handoff und übernimmt die Verantwortung für den nächsten Abschnitt der Interaktion. In einem anderen behält ein Manager die Verantwortung für das Endergebnis und ruft Spezialisten wie Tools auf.

Dieser Unterschied ist wichtig, weil er die Frage beantwortet, die Multi-Agent-Systeme oft offenlassen: **Wer besitzt das aktuelle Ergebnis?**

Bleibt der Manager verantwortlich, verhält sich der Spezialist eher wie eine Funktion. Er erledigt eine begrenzte Aufgabe und gibt ein Resultat zurück. Bei einem echten Handoff wechselt die Kontrolle dagegen wirklich. Viele Agent-Systeme werden unübersichtlich, weil Delegation im Code existiert, Ownership im Zustandsmodell aber implizit bleibt. Alle sehen, dass „jemand daran arbeitet“, aber niemand kann zuverlässig sagen, wer genau gerade verantwortlich ist.

Ein einfacher Coding-Workflow könnte so aussehen:

~~~text
issue
  -> triage agent
  -> implementation agent
  -> review agent
~~~

Das wirkt sauber, bis operative Fragen auftauchen. Darf der Triage-Agent denselben Scope noch verändern, nachdem der Implementation-Agent den Task angenommen hat? Ist der Review-Agent read-only oder darf er direkt patchen? Bedeutet DONE, dass der Task fertig ist, oder nur, dass der Implementation-Agent aufgehört hat? Wenn das Review fehlschlägt, geht der Zustand zurück auf WORKING oder entsteht eine neue Anfrage?

Leben diese Regeln nur in Prompts, hängt das System irgendwann davon ab, dass Agents den vorgesehenen Prozess ungefähr richtig interpretieren. Ich bevorzuge inzwischen einen sehr kleinen Koordinationsvertrag. Ein Handoff sollte mindestens explizit machen: Request ID, Sender, Receiver, Owner, Deliverable, Source Revision, Dependencies, Acceptance Test, Required Capability, Fallback und aktuellen Status.

Es geht nicht darum, Agent-Arbeit in ein weiteres Jira zu verwandeln. Es geht darum, mehrdeutige Zustände zu beseitigen, die sonst aus der Chat-Historie rekonstruiert werden müssten.

Das Zustandsmodell, das ich schließlich verwendet habe, ist absichtlich klein:

~~~text
REQUESTED
  -> ACKNOWLEDGED
  -> WORKING
  -> DONE
  -> VERIFIED
~~~

Wichtig sind nicht die fünf Labels. Wichtig ist, dass das System ihre Bedeutung nicht überspringen darf.

Eine gesendete Nachricht beweist nur REQUESTED. ACKNOWLEDGED sollte verlangen, dass der Empfänger sie tatsächlich annimmt. Ein geplanter Job beweist nicht, dass die Arbeit DONE erreicht hat. Sagt ein Agent „fertig“, kann der Task auf DONE wechseln; VERIFIED sollte aber Testausgabe, Diff, Logs oder andere konkrete Evidenz verlangen.

Das klingt konservativ, macht ein System mit mehreren aktiven Agents aber oft leichter. Ein neuer Worker muss nicht mehr eine lange Unterhaltung erneut lesen, um zu erraten, was passiert ist. Er kann den kanonischen Zustand und die jüngsten Receipts lesen.

## Ich habe die Regeln in einen kleinen Validator gegossen

Ein Protokoll ist wenig wert, wenn es nur als Prosa existiert. Deshalb habe ich in Content Lab ein First-Party-Experiment gebaut. Ich habe **keinen** Code aus dem oben verlinkten Drittanbieter-Repository ausgeführt, sondern synthetische Fixtures verwendet, um die Koordinationsregeln selbst zu testen.

Der erste Teil war ein Validator für den Koordinationsvertrag. Absichtlich erzeugt wurden typische fehlerhafte Zustände: zwei Agents beanspruchen gleichzeitig aktive Ownership desselben Scopes; ein Task steht auf DONE ohne Bestätigung des Receivers; ein Handoff bezieht sich auf eine veraltete Source Revision; ein Task benötigt Merge-Fähigkeit, wird aber einer Umgebung zugewiesen, die nur read/write kann; Abschluss ohne Verifikationsbeleg; eine doppelte externe Aktion, obwohl noch eine andere Anfrage aktiv ist; und ein ersetzter Task, der weiterhin als aktiv markiert ist.

Alle acht Fixture-Fälle verhielten sich wie erwartet.

Das beweist nicht, dass Produktionskollisionen jetzt seltener auftreten, und so würde ich es auch nicht darstellen. Es beweist etwas Bescheideneres und Nützlicheres: **Viele Fehler, die wie Intelligenzprobleme eines Agents aussehen, sind deterministische Koordinationsfehler, die außerhalb des Modells geprüft werden können.**

Capability-Mismatch ist ein gutes Beispiel. „Dieser Agent hat GitHub-Zugriff“ reicht als Aussage nicht. Lesen, editieren, pushen, mergen, deployen, Zugriff auf Secrets und ausgehende Nachrichten sind unterschiedliche Fähigkeiten. Dass eine interaktive Session pushen kann, bedeutet nicht, dass ein geplanter Worker in einer anderen Umgebung dasselbe darf.

Deshalb vermeide ich zunehmend ein vages has-access-Flag. Der Task sollte deklarieren, welche Fähigkeiten er benötigt, und die Ausführungsumgebung sollte deklarieren, welche Fähigkeiten sie tatsächlich besitzt.

Die aktuelle [Subagents-Dokumentation von Claude Code](https://code.claude.com/docs/en/sub-agents) weist in dieselbe Richtung. Subagents besitzen isolierten Kontext und können eingeschränkte Tools und Berechtigungen haben; Worktrees können Repository-Änderungen isolieren. Die Anleitung macht außerdem klar, dass Subagents besonders bei unabhängiger Exploration, Tool-Isolation oder Arbeit mit klar begrenztem Ergebnis sinnvoll sind. Wenn mehrere Phasen eng geteilten Kontext und ständigen Austausch benötigen, kann eine einzige Hauptsession besser sein. Multi-Agent ist nicht automatisch überlegen. Es ist dort besonders nützlich, wo die Grenzen ohnehin real sind.

Das zweite Experiment testete Receipt Replay.

Ich modellierte ein append-only Event-Log, das von REQUESTED bis VERIFIED läuft, und probierte anschließend ungültige Übergänge. REQUESTED -> WORKING wurde abgelehnt, weil „Anfrage gesendet“ nicht „Empfänger hat sie akzeptiert“ bedeutet. REQUESTED -> DONE wurde abgelehnt, weil Scheduling oder Triggern kein Ausführungsbeweis ist. Ein ACKNOWLEDGED von jemand anderem als dem Receiver wurde ebenso abgelehnt wie VERIFIED ohne Evidenz.

Alle sieben Replay-Checks bestanden. Noch wichtiger: Nach dem Löschen des abgeleiteten Zustands ließ sich der finale VERIFIED-Status allein aus dem Event-Log wiederherstellen.

Das ist für langlebige Agent-Workflows relevant. Existiert Zustand nur in einem Chat, können Context Compression, eine neue Session oder ein anderer Rechner den nächsten Schritt zum Ratespiel machen. Sind Request-, Acknowledgement-, Completion- und Verification-Receipts dauerhaft gespeichert, muss der nächste Agent keiner Zusammenfassung vertrauen. Er kann Fakten lesen.

## GitHub eignet sich gut als Control Plane – aber nicht als Runtime-Datenbank

Für kleine Teams und unabhängige Entwickler ist GitHub erstaunlich brauchbar für diese Koordinationsschicht.

Nicht weil GitHub eine Orchestration-Plattform wäre, sondern weil es mehrere Eigenschaften bereits mitbringt, die eine Control Plane braucht. Zustand ist versioniert. Änderungen haben Autoren und Zeitstempel. Commits liefern Revisionen. Issues und PRs können Evidenz tragen. Repository-Dateien sind für Tools wie Codex und Claude Code direkt lesbar. Am ersten Tag braucht man nicht zwingend ein eigenes Orchestration-Backend; kanonischen Zustand in einem Repository festzuhalten löst bereits eine große Klasse von Cross-Session-Problemen.

Mein eigenes Content Lab funktioniert bereits so. Aktives Topic, aktives Dossier, vorheriger Befehl, nächster Befehl und Lifecycle-State werden persistent gespeichert. Die Dossier-History wächst von DISCOVERED über SCORED und RESEARCHING bis READY_FOR_TEST, statt darauf zu vertrauen, dass ein Chatfenster weiß, wo der Workflow aufgehört hat. Dieses Experiment bestätigte außerdem, dass Active Pointer, expliziter Next Command und append-only History im selben GitHub-gestützten Workflow sauber zusammenspielen.

Trotzdem würde ich nicht jedes Runtime-Detail in Git speichern. Hochfrequente Locks, Millisekunden-Leases, Message Queues, temporäre Tokens und sensible Credentials sind keine guten Git-Daten. GitHub eignet sich besser für dauerhafte Fakten, die Sessions überleben und auditierbar bleiben müssen.

Ich denke dabei an zwei Ebenen:

~~~text
runtime state
  -> execution locks, streams, short-lived messages, transient state

canonical coordination state
  -> owner, revision, handoff, receipt, evidence, final decision
~~~

Die erste Ebene kann in Datenbank, Queue oder SDK-Session leben. Die zweite sollte auch Tage später noch verständlich sein, wenn ein anderer Agent nachvollziehen muss, was wirklich passiert ist.

OpenAIs aktuelle Dokumentation zu [Running agents](https://developers.openai.com/api/docs/guides/agents/running-agents) behandelt Zustand ähnlich als explizite Continuation-Entscheidung: History selbst verwalten, Sessions verwenden, serverseitige Continuation nutzen oder unterbrochene Runs fortsetzen. Die [Observability-Anleitung des Agents SDK](https://developers.openai.com/api/docs/guides/agents/integrations-observability) zeichnet Model Calls, Tool Calls, Handoffs und Guardrails auf. Das verstärkt denselben Punkt: **Execution State und auditierbarer State brauchen bewusstes Design; Prompts allein reichen nicht.**

## Als Erstes würde ich eine Evidence Chain hinzufügen

Einem Prinzip der älteren Version dieses Artikels stimme ich weiterhin zu: Wenn ein einzelner Agent einen Task zuverlässig erledigen kann, sollte man ihn nicht nur für eine beeindruckendere Architektur auf fünf Agents verteilen. Auch OpenAI empfiehlt, wenn möglich mit einem Agent zu beginnen und Spezialisten erst dann einzuführen, wenn Capability-Isolation, Policy-Isolation, klarere Prompts oder besser lesbare Traces das wirklich rechtfertigen.

Sobald allerdings mehrere Agents beteiligt sind, würde ich Shared State heute früher hinzufügen.

Nicht einen komplizierteren Supervisor. Nicht um ihrer selbst willen eine Planner-Reviewer-Hierarchie. Nur wenige Fakten, die nicht mehrdeutig bleiben dürfen: Wer besitzt diesen Scope gerade, hat der Receiver den Task tatsächlich bestätigt, auf welcher Revision basiert er, welche Fähigkeiten besitzt die Ausführungsumgebung, welche Evidenz stützt DONE und kann die Event-Historie die reale Reihenfolge später rekonstruieren?

Diese Ebene ist nicht spektakulär. Sie macht eine Demo nicht intelligenter. Mit der Zeit ist sie aber wichtiger als noch ein zusätzlicher Agent.

Der gefährlichste Fehler in einem Multi-Agent-System ist nicht immer eine schlechte Modellentscheidung. Es kann passieren, dass jede lokale Entscheidung einzeln vernünftig wirkt, während der globale Zustand bereits falsch ist. Ein Agent glaubt, niemand habe begonnen. Ein anderer glaubt, alles sei fertig. Eine Automation nimmt an, ein Zeitplan sei bereits gelaufen. Ein Reviewer prüft eine alte Revision. Jeder Schritt klingt plausibel und der gesamte Workflow kann trotzdem falsch sein.

Wenn mich deshalb heute jemand fragt, was Agent Orchestration wirklich bedeutet, höre ich nicht mehr bei „mehrere Agents arbeiten zusammen“ auf.

Ich würde es so beschreiben: **Tasks, Zustand, Berechtigungen und Evidenz in einen Workflow organisieren, der nicht auf Raten angewiesen ist.**

Routing entscheidet, wer den nächsten Schritt bekommt. Ownership sagt, wer gerade verantwortlich ist. Ein Handoff transportiert Kontext und Grenzen. Ein Receipt beweist, dass der Receiver wirklich akzeptiert hat. Capability-Grenzen verhindern, dass Arbeit einer Umgebung zugewiesen wird, die sie gar nicht ausführen kann. Traces und Evidenz machen den Endzustand später erklärbar.

Wenn du Coding Agents tiefer in reale Projekte integrierst, behandelt der verwandte Beitrag [Wie ich AGENTS.md, Skills und CI getrennt habe, als CLAUDE.md zu groß wurde](/de/posts/claude-md-agents-md-skills-ci/) die vorherige Ebene: wo Regeln leben sollten. Dieser Artikel ist die nächste Ebene: Wenn mehr als ein Agent arbeitet, **wie teilen sie eine einzige vertrauenswürdige Version der Realität?**