Multi-Vendor-Orchestrierung: Framework-übergreifende Agenten koordinieren

Multi-Vendor Agent Orchestrierung bezeichnet die Koordination von KI-Agenten unterschiedlicher Frameworks und Anbieter über ein gemeinsames, offenes Protokoll. Via Agent-to-Agent (A2A) steuert etwa ein LangGraph-Orchestrator CrewAI- und AutoGen-Agenten, ohne deren interne Prompts, Modelle oder Speicher offenzulegen. Das Ziel ist Interoperabilität ohne Vendor-Lock-in: Agenten, die in getrennten Estates leben, arbeiten an einer gemeinsamen Aufgabe zusammen.

• Wer koordiniert wen? Ein Orchestrator-Agent ruft Peer-Agenten über A2A auf. Die interne Logik der aufgerufenen Agenten bleibt bewusst opak.
• Welches Protokoll wofür? MCP für Agent-zu-Tool, A2A für Agent-zu-Agent. Stand 2026 ist das der konvergente Industrie-Stack.
• Was bringt es? Kein Lock-in auf einen Anbieter, da Agenten über portable AgentCards austauschbar werden und kein Estate die anderen exponieren muss.

Warum Framework-übergreifend statt Monolith

In der Realität von DACH-Unternehmen liegt keine grüne Wiese vor. Der CRM-Agent lebt in Salesforce, der ERP-Agent in SAP, der Produktivitäts-Agent in Microsoft, ein Spezial-Reasoning-Schritt vielleicht direkt im Anthropic Claude Agent SDK. Niemand baut das alles in einem einzigen Framework neu. Multi-Vendor-Orchestrierung akzeptiert diese Heterogenität als Normalfall und legt eine gemeinsame Sprache darüber.

Der konzeptionelle Schlüssel von A2A: Das Protokoll definiert, wie Agenten reden, nicht wie sie denken. Ein Salesforce-Agent kann einen SAP-Agenten aufrufen, ohne dass einer der beiden seine Prompts, sein Gedächtnis oder sein Modell offenlegt. Genau diese Kapselung ist die Voraussetzung dafür, dass ein LangGraph-Orchestrator einen CrewAI-Agenten oder einen AutoGen-Agenten steuern kann, ohne deren Innenleben zu kennen.

Architektur: der konvergente Protokoll-Stack 2026

Nach zwölf Monaten öffentlicher Neuordnung ist der Stack eindeutig. Anthropic hat MCP am 9. Dezember 2025 in die Agentic AI Foundation unter der Linux Foundation eingebracht; Google hat A2A am 23. Juni 2025 an die Linux Foundation gespendet, mit AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow als Gründungsmitgliedern. IBMs ACP ist im August 2025 in A2A aufgegangen.

Die ehrliche Einordnung: MCP plus A2A ist der konvergente Stack. AGNTCY ist die rationale Ergänzung, wenn Cross-Vendor-Identität und Observability wirklich gebraucht werden. NANDA gehört auf die Watchlist, nicht auf den kritischen Pfad eines 2026er Programms.

Die technischen Kernbausteine von A2A

• Transport: JSON-RPC 2.0 über HTTPS, Streaming via Server-Sent Events, optionale Push-Notifications für lange Tasks.
• AgentCard: Ein JSON-Dokument je Agent mit Endpoint, Capabilities, unterstützten Skills, Modalitäten und Authentifizierungsschemata. Das ist der Cross-System-Vertrag schlechthin.
• Task-Lifecycle: submitted -> working -> input-required -> completed | failed | canceled. Das Resultat eines Tasks sind ein oder mehrere Artefakte.
• Drei Interaktionsmodi: synchron, asynchrones Polling, sowie Streaming/Push für lang laufende Aufgaben.

Interop-Vorteile und ihre Grenzen

Der Hauptvorteil ist kein Marketing-Versprechen, sondern strukturell: Wer Agenten über portable AgentCards anbindet, kann einen schwachen Spezialagenten gegen einen besseren austauschen, ohne den Orchestrator umzubauen. Für eine Agentur bedeutet das, einmal gebaute Agenten in beliebigen Kunden-Estates aufrufbar zu machen.

Die Grenzen sind ebenso real und gehören in jede Architekturentscheidung:

• Trust-Boundaries: Jeder A2A-Peer ist für die anderen opak. Das ist gut für Vertraulichkeit, aber schlecht für White-Box-Auditierung. Cross-Vendor-Traces sind hart.
• Prompt-Injection-Verstärkung: Jedes neue Sub-Agent-Kontextfenster ist eine neue Angriffsfläche. Die EchoLeak-Klasse (CVE-2025-32711, Aim Labs, Microsoft 365 Copilot, Juni 2025) skaliert linear mit der Zahl der Agenten, die untrusted Content aufnehmen.
• Vendor-Lock-in durch die Hintertür: Proprietäre A2A-Erweiterungen an AgentCard oder Task-Semantik untergraben genau die Portabilität, die das Protokoll begründet. Das Watchlist-Signal 2026: Bleibt die AgentCard ein portables JSON-Dokument?
• Reife: Hub-and-Spoke via A2A ist 2026 als Productisation einzuordnen, nicht als durchgereifter Standard. AGNTCY und NANDA sind noch keine Produktiv-Wetten.

Praxisszenario: LangGraph orchestriert über drei Vendor-Grenzen

Ein konkreter Cross-Functional-Flow eines Konzerns, der Sales, Service und Finance über drei Estates verbindet. Der Orchestrator ist LangGraph (v1.0, GA 22. Oktober 2025, MIT-Lizenz), die internen Spezialagenten sprechen jeweils ihr eigenes Framework und werden über A2A aufgerufen.

```text
LangGraph-Orchestrator (durable state, checkpointing)
|
|-- A2A-Task --> Agentforce-360-Agent (CRM-Daten, Atlas Reasoning, intern kein A2A)
|-- A2A-Task --> CrewAI-Enrichment-Agent (Lead-Anreicherung, eigener Prozess)
|-- A2A-Task --> AutoGen-Review-Agent (Critic-Generator, Qualitaetspruefung)
|-- A2A-Task --> SAP-Joule-Agent (Finanz-Posting, bidirektionales A2A ab Q4 2026)
|
|-- MCP --> ABAP / S4HANA / Integration Suite (Tools)

Write-Pfad: single-threaded. Nur der LangGraph-Knoten committet.
Jeder A2A-Hop traegt dieselbe Trace-ID (Audit + DSGVO).
```

Wichtig ist die Schreib-Disziplin. Cognition.ai hat im April 2026 die wirksame Form präzisiert: Mehrere Agenten steuern Intelligenz bei, aber Writes bleiben single-threaded. Lese-lastiges Fan-out (Anreicherung, Retrieval, Review) ist robust; paralleles Schreiben in geteilten Zustand ist fragil. Im Szenario sammeln und prüfen drei Agenten, aber nur der Orchestrator-Knoten schreibt. Zur Einordnung der Kosten: Anthropics Orchestrator-Worker-Muster (Claude Research, 13. Juni 2025) erreichte plus 90,2 Prozent Breite bei rund 15-fachem Token-Verbrauch. Dieser Faktor rechnet sich nur bei hochwertigen, parallelisierbaren Aufgaben, nicht pauschal.

DACH-spezifische Pflichten bei Multi-Vendor-Flows

Sobald Agenten auf verschiedenen Compute-Providern laufen, überquert der Datenfluss bei jeder Aufgabe mehrere Datenresidenz- und Auftragsverarbeiter-Grenzen.

• AVV-Kette (DSGVO Art. 28): Jeder Agent-Provider ist potenziell Auftragsverarbeiter. Multi-Agent verlängert die Kette; jeder A2A-Hop ist potenziell eine eigene AVV-Beziehung.
• Grenzüberschreitende Transfers (Art. 44-49): Bei einem US-EU-gemischten Stack führt man nicht ein Transfer Impact Assessment durch, sondern eines pro grenzüberschreitendem Agenten-Hop.
• Audit-Trail: End-to-End-Trace jedes Agent-Calls, Modellversionen pinnen, alle Sub-Agent-Prompts und genutzten AgentCards aufzeichnen, über eine einzige Trace-ID korrelieren. Das Allianz-Project-Nemo-Muster mit dediziertem Audit-Agenten ist hier die DACH-relevante Blaupause.
• Sprachliche Konsistenz: Ein Agent mit Du, der einen Agenten mit Sie aufruft, liest sich für Kunden als kaputt. Tone-of-Voice gehört auf AgentCard- und Prompt-Template-Ebene erzwungen.

Für Agenturen und B2B

Für DACH-Agenturen ist der größte Produktstrategie-Hebel 2026, für jeden productisierten Agenten eine AgentCard zu veröffentlichen. So rufen Kunden-Estates Ihre Agenten direkt aus Agentforce, Joule oder Copilot Studio auf, ohne Individualintegration. Ohne AgentCard sitzt Ihr Agent dauerhaft hinter einer Custom-Schnittstelle. Für B2B-Entscheider lautet die Procurement-Frage konkret: Garantiert der Agentforce-, Joule- oder Copilot-Studio-Vertrag A2A-Interop und MCP-Standardtreue, und was passiert beim Exit? Die rationale Mittelstands-Default-Architektur ist n8n oder LangGraph als Orchestrierung, MCP für Tools, A2A für jeden Cross-Platform-Handshake. Blck Alpaca begleitet diese Entscheidungen praxisnah: vom Pattern-Selection-Review über governte AgentCard-Strategien bis zur sovereign-tauglichen Audit-Architektur.