Ein Agent ist selten die richtige Antwort
Multi-Agent-Systeme durchlaufen gerade ihren Microservices-Moment: Statt eines Allzweck-Agenten mit dreißig Tools arbeiten spezialisierte Agenten an Teilaufgaben — koordiniert über einen Graphen, mit klaren Übergabepunkten und definierten Stellen für menschliche Freigabe.
Agenten-Orchestrierung verteilt eine Aufgabe auf spezialisierte Agenten und koordiniert deren Reihenfolge, Parallelität und Übergaben. Innerhalb einer Organisation geschieht das über einen Ausführungsgraphen, organisationsübergreifend über das A2A-Protokoll mit signierten Agent Cards. Jeder Sub-Agent erhält nur die Rechte seiner Teilaufgabe.
Drei Muster, die tragen
Die Wahl des Musters entscheidet mehr über Zuverlässigkeit und Kosten als die Wahl des Modells. Alle drei sind auf derselben Runtime abbildbar — sie unterscheiden sich in Kontrollfluss und Blast-Radius.
| Muster | Geeignet für | Kosten | Risiko |
|---|---|---|---|
| Ein Agent | Klar umrissene Aufgaben mit wenigen Werkzeugen und einem Erfolgskriterium. | niedrig | Wächst mit der Zahl der Tools: Auswahlfehler häufen sich. |
| Planner + Worker | Mehrstufige Prozesse mit unterschiedlichen Datenquellen und Rechten je Teilschritt. | mittel bis hoch | Planungsfehler pflanzen sich fort; Zwischenergebnisse müssen validiert werden. |
| Föderation (A2A) | Aufgaben, die eine andere Organisation besser erledigt — Dienstleister, Fachabteilung, Partner. | abhängig vom Partner | Vertrauensgrenze. Ohne signierte Agent Card ist der Gegenpart nicht verifizierbar. |
A2A: der horizontale Bus
MCP verbindet einen Agenten mit seinen Werkzeugen — vertikal, nach unten. A2A verbindet Agenten untereinander — horizontal, über Organisationsgrenzen hinweg. Seit das Protokoll unter neutraler Governance der Linux Foundation steht und ACP darin aufgegangen ist, hat sich die Fragmentierung von 2025 weitgehend erledigt.
- A2A (Agent2Agent)
- Offenes Protokoll für die Kommunikation zwischen eigenständigen Agenten über Organisationsgrenzen hinweg. Ein Agent delegiert eine Aufgabe an einen anderen, verfolgt deren Fortschritt und empfängt das Ergebnis — ohne die interne Umsetzung des Gegenübers zu kennen.
- Agent Card
- Maschinenlesbare Selbstbeschreibung eines Agenten unter
/.well-known/agent-card.json: Fähigkeiten, Endpunkte, Authentifizierungsverfahren, Betreiber. Signierte Karten sind der Baseline-Schutz gegen gefälschte Registry-Einträge. - Handoff
- Übergabe einer Teilaufgabe samt Kontext und zeitlich begrenzten Rechten an einen anderen Agenten. Entweder mit Streaming-Fortschritt oder als Fire-and-forget mit späterem Callback.
Bevor Sie A2A einsetzen, klären Sie die unangenehme Frage: Wer haftet, wenn der fremde Agent etwas auslöst? Wir modellieren Handoffs deshalb standardmäßig als Vorschlag mit Rückgabe, nicht als Vollmacht — die ausführende Aktion bleibt auf Ihrer Seite.
Den Graphen deklarieren
Der Ausführungsgraph ist Code, kein Diagramm in einer Oberfläche. Er liegt im Repository, wird versioniert und in der CI gegen die Eval-Suite geprüft.
from hostspezial.agents import Graph, Agent, human_approval, handoff
graph = Graph(name="dispute", budget_eur=0.50)
# Jeder Sub-Agent bekommt nur die Tools seiner Teilaufgabe.
# Die Scopes werden beim Start des Laufs kurzlebig ausgestellt.
retrieval = Agent("retrieval", tools=["postgres.query", "docs.search"], scopes=["read:orders"])
analysis = Agent("analysis", tools=[], model="gross") # nur Urteil, keine Aktion
action = Agent("action", tools=["stripe.refund", "crm.update"], scopes=["write:refund"])
graph.edge("start", retrieval)
graph.edge(retrieval, analysis)
# Ueber 250 EUR entscheidet ein Mensch. Der Lauf wartet als
# Zustand, nicht als offener Prozess — Wartezeit kostet nichts.
graph.edge(analysis, action, when=lambda s: s.amount <= 250)
graph.edge(analysis, human_approval(queue="finance", ttl_h=24), when=lambda s: s.amount > 250)
# Strittige Faelle gehen als Vorschlag an einen Partner-Agenten.
# verify_card=True erzwingt eine gueltige Signatur der Agent Card.
graph.edge(analysis, handoff("https://partner.example/.well-known/agent-card.json",
mode="streaming", verify_card=True, returns="proposal"),
when=lambda s: s.disputed)Human-in-the-Loop ist ein Zustand, keine Wartezeit
Der häufigste Konstruktionsfehler: Der Agent bleibt in einer Schleife stehen und pollt auf eine Freigabe. Das kostet Rechenzeit, blockiert einen Prozess und geht bei jedem Deployment verloren. In der Runtime ist die Freigabe ein Wartezustand mit Frist — der Lauf existiert weiter als Datensatz und wird durch die Freigabe reaktiviert.
Praktisch heißt das: Freigaben können Stunden oder Tage dauern, ohne dass etwas kostet. Läuft die Frist ab, greift der definierte Fallback — meist die Eskalation an eine zweite Warteschlange.
Was das nicht löst
Mehr Agenten heißt mehr Kontextgrenzen, an denen Information verloren geht. Ab etwa sieben Sub-Agenten haben wir in Projekten regelmäßig erlebt, dass Fehler nicht mehr aus einem einzelnen Schritt erklärbar sind, sondern aus der Übergabe zwischen zweien. Und A2A schafft kein Vertrauen: Eine signierte Agent Card beweist die Identität des Betreibers, nicht die Qualität seines Agenten.
Orchestrierung im Detail
Wann lohnt sich ein Multi-Agent-System gegenüber einem einzelnen Agenten?
Wenn Teilaufgaben unterschiedliche Rechte brauchen, unterschiedliche Modellgrößen rechtfertigen oder parallel laufen können. Reines „mehr Agenten wirkt mächtiger“ kostet nur Koordination. Als Faustregel: Erst aufteilen, wenn ein einzelner Agent mehr als acht Tools bekommen würde.
Was ist der Unterschied zwischen MCP und A2A?
MCP ist der vertikale Bus zwischen einem Agenten und seinen Werkzeugen. A2A ist der horizontale Bus zwischen eigenständigen Agenten. Sie konkurrieren nicht, sondern sitzen auf verschiedenen Ebenen — ein A2A-Partner nutzt intern wieder MCP. Details im Tool-Layer.
Wie werden Rechte an Sub-Agenten vererbt?
Nicht durch Vererbung, sondern durch Ausstellung: Jeder Sub-Agent erhält beim Start eigene, kurzlebige Credentials mit genau den Scopes seiner Teilaufgabe. Ein Sub-Agent kann keine Rechte weiterreichen, die er selbst nicht hat — und keine, die er nicht braucht. Mehr dazu unter Agent Identity.
Was passiert, wenn ein Partner-Agent nicht antwortet?
Der Handoff hat eine Frist. Läuft sie ab, gilt der definierte Fallback — in der Regel Bearbeitung im eigenen Haus oder Eskalation an einen Menschen. Der Lauf bleibt in der Zwischenzeit im Wartezustand und verbraucht keine Rechenzeit.
Kann ich einen Graphen ändern, während Läufe aktiv sind?
Ja. Graphen sind versioniert; laufende Läufe beenden sich in ihrer Version, neue starten in der aktuellen. Das verhindert, dass ein Deployment mitten in einem mehrstündigen Lauf die Regeln wechselt.
Wie lange darf eine menschliche Freigabe offen bleiben?
Standardmäßig 24 Stunden, konfigurierbar je Kante. Nach Ablauf greift der Fallback. Die Wartezeit kostet nichts, weil kein Prozess offen gehalten wird — siehe Durable Execution.
Weiter in der Plattform
Wir zeichnen Ihren Prozess als Graphen
Bringen Sie einen echten Ablauf mit — wir modellieren ihn in einem Workshop als Agenten-Graph, inklusive Freigabestellen und Rechten je Schritt. Ergebnis ist ein lauffähiger Entwurf, kein Foliensatz.