Bildquelle: extern
A2A und MCP im Unternehmensbetrieb brauchen klare Betriebsregeln vor dem ersten Multi-Agent-Workflow
Der nächste Reifeschritt bei Unternehmens-KI ist nicht einfach ein besseres Modell. Er liegt in der Verkettung. Assistenten sollen nicht mehr nur Fragen beantworten, sondern interne Tools nutzen, andere Agenten ansprechen, Aufgaben weiterreichen und Ergebnisse wieder in Geschäftsprozesse zurückspielen. Genau an dieser Stelle tauchen derzeit zwei Protokollfamilien immer häufiger auf: MCP, das Model Context Protocol, für den Anschluss von Datenquellen und Werkzeugen, und A2A, das Agent2Agent Protocol, für die Zusammenarbeit mehrerer Agenten.
Die offiziellen Beschreibungen zeigen die Rollen sauber. MCP definiert einen offenen Standard, mit dem KI-Anwendungen über Host, Client und Server auf Tools, Ressourcen und Prompts zugreifen können. Die Architektur arbeitet mit JSON-RPC 2.0 und unterstützt lokale Verbindungen per STDIO ebenso wie entfernte Anbindungen über HTTP. A2A setzt an einer anderen Stelle an. Google beschreibt es ausdrücklich als offenes Protokoll für die Kommunikation zwischen Agenten, inklusive Capability Discovery über Agent Cards, Task-Lifecycle, Streaming und Unterstützung für langlaufende Aufgaben. Im A2A-Umfeld wird zudem klar gesagt, dass A2A MCP ergänzt, statt es zu ersetzen.
Für ITSM- und IT-Management-Teams ist das keine Protokoll-Feinheit, sondern eine Betriebsfrage. Denn sobald ein Assistent nicht nur ein internes Wiki liest, sondern Tickets erzeugt, Workflows anstößt und Teilaufgaben an Spezialagenten delegiert, verschieben sich Verantwortung, Nachweisführung und Störungsbild deutlich. Wer hier zu früh auf Demo-Logik setzt, bekommt später schwer erklärbare Fehlerketten. Sechs Regeln helfen, Multi-Agent-Workflows belastbar aufzubauen.
1. Tool-Anschluss und Agenten-Delegation müssen getrennt geführt werden
Der häufigste Denkfehler ist die pauschale Aussage, man habe jetzt „Agenten mit Unternehmenssystemen verbunden“. Operativ ist das zu ungenau. MCP verbindet eine KI-Anwendung mit Werkzeugen, Ressourcen und Kontext. A2A verbindet Agenten untereinander. Das klingt ähnlich, ist aber im Betrieb etwas völlig anderes.
Ein MCP-Server, der ein Ticket anlegen oder eine Wissensdatenbank durchsuchen kann, ist ein direkter Systemzugang. Ein A2A-fähiger Agent, der eine Aufgabe an einen anderen Agenten weitergibt, ist dagegen zunächst eine Delegationsbeziehung. Beides darf in Governance und Freigabe nicht im selben Topf landen. Sonst wird im Review schnell übersehen, ob ein neuer Pfad „nur“ eine Weiterleitung erzeugt oder tatsächlich schreibend in ein Drittsystem eingreift.
Praktisch bewährt sich eine einfache Trennung in zwei Inventare: erstens angebundene MCP-Server mit ihren konkreten Tools und Rechten, zweitens A2A-Beziehungen zwischen Agenten mit Zweck, Zielsystem und erlaubtem Aufgabenraum. Erst wenn beide Sichten getrennt dokumentiert sind, lässt sich sauber entscheiden, wo eine technische Verbindung endet und wo eine geschäftliche Verantwortung beginnt.
2. Agent Cards und MCP-Server gehören wie Konfigurationselemente inventarisiert
A2A setzt auf Agent Cards zur Fähigkeitsbeschreibung. MCP beschreibt Hosts, Clients und Server sowie ihre angebotenen Primitiven. Genau daraus sollten IT-Organisationen kein loses Entwicklerwissen machen, sondern eine inventarisierbare Betriebsfläche. Wer produktive Agenten einführt, braucht de facto eine kleine CMDB-Erweiterung für KI-Komponenten.
Mindestens festgehalten werden sollten: Owner, Zweck, Umgebung, erreichbare Systeme, erlaubte Aktionen, verwendete Identitäten, Version, Logging-Pfad und Fallback. Bei A2A kommt zusätzlich hinzu, welche Aufgaben ein Agent annehmen darf und welche Artefakte er zurückliefert. Bei MCP ist wichtig, ob ein Server rein lesend arbeitet oder Tickets, Dateien, Datenbankeinträge oder Automationen verändern kann.
Der Nutzen ist sehr konkret. Bei Incidents lässt sich schneller eingrenzen, welche Verbindung betroffen ist. Bei Changes kann geprüft werden, ob neue Agentenbeziehungen bestehende Freigaben verletzen. Und bei Audits entsteht überhaupt erst ein prüfbarer Überblick darüber, welche KI-Komponenten im Unternehmen miteinander sprechen.
3. Langlaufende Agenten-Aufgaben brauchen Status, Fristen und einen Service Owner
Ein starker Punkt von A2A ist die Unterstützung für langlaufende Tasks mit Status-Updates und Artefakten. Genau das ist aus ITSM-Sicht interessant, aber auch riskant. Denn langlaufend bedeutet in der Praxis: Ein Auftrag bleibt über Minuten, Stunden oder Tage in einer verteilten Verarbeitungskette hängen. Ohne klares Zustandsmodell wird daraus schnell eine Black Box.
Teams sollten deshalb jeden produktiven Multi-Agent-Use-Case mit einer kleinen Service-Logik versehen. Welche Status gibt es, zum Beispiel angenommen, in Bearbeitung, wartet auf Freigabe, blockiert, abgeschlossen oder abgebrochen? Welche maximale Laufzeit ist akzeptabel? Wer besitzt den Gesamtauftrag fachlich, wenn drei Agenten beteiligt sind? Und wann wird ein menschlicher Bearbeiter aktiv eingebunden?
Gerade Service-Organisationen kennen diese Logik bereits aus Requests, Changes und Major Incidents. Genau deshalb sollte man sie nicht neu erfinden, sondern auf Agenten-Aufgaben übertragen. Ein A2A-Task ohne Eigentümer, Frist und Eskalationsweg ist operativ kaum besser als ein unzugeordnetes Ticket.
4. Schreibende Aktionen brauchen Freigabegrenzen zwischen Lesen, Entscheiden und Ausführen
MCP macht es technisch vergleichsweise einfach, Tools anzubinden. Genau deswegen muss die Freigabelogik strenger werden. Lesender Zugriff auf Dokumentation, Monitoring oder Ticketdaten ist etwas anderes als das Anlegen eines Changes, das Zurücksetzen eines Kontos oder das Starten einer Automatisierung. Wenn dann zusätzlich ein A2A-Agent Aufgaben an andere Agenten übergibt, potenziert sich die Wirkungskette.
Für den Betrieb ist deshalb eine dreistufige Grenze sinnvoll: lesen, vorbereiten, ausführen. Lesen heißt, Daten zu holen oder Kontext aufzubereiten. Vorbereiten heißt, Vorschläge, Change-Entwürfe oder Tickettexte zu erzeugen, aber noch nichts wirksam abzuschicken. Ausführen heißt, einen schreibenden oder operativen Schritt wirklich zu starten.
Diese dritte Stufe sollte nur unter klaren Bedingungen erlaubt werden: definierter Scope, passende Identität, protokollierte Parameter und je nach Risiko eine explizite Nutzer- oder Operator-Freigabe. Das ist keine Innovationsbremse, sondern die Voraussetzung dafür, dass aus Assistenten keine unklare Nebenautomatisierung wird.
5. Ohne durchgehende Nachverfolgung wird jede Störung zum Zuordnungsspiel
Wenn ein Agent per A2A einen Spezialagenten anfragt und dieser über MCP auf mehrere Tools zugreift, entsteht schnell eine Kette aus Delegation, Retrieval, Tool-Call und Ergebnisartefakt. Technisch funktioniert das oft schon erstaunlich gut. Betriebsseitig fehlt aber häufig der rote Faden. Der Service Desk sieht nur, dass „die KI nichts geliefert hat“. Das Plattformteam sieht vielleicht einen erfolgreichen Modellaufruf. Der eigentliche Fehler liegt jedoch in einem entfernten Tool oder in einer fehlerhaften Agentenfähigkeit.
Deshalb braucht jeder produktive Workflow eine durchgehende Korrelation über die gesamte Kette. Praktisch heißt das: eindeutige Request- oder Task-ID, nachvollziehbare Übergänge zwischen Agenten, Logging der aufgerufenen MCP-Tools, klare Fehlerklassen und sichtbarer Endstatus. A2A nennt Observability ausdrücklich als Enterprise-Anforderung, und genau das sollte man ernst nehmen.
Für ITSM lohnt sich hier ein nüchterner Standard: Jeder agentische Auftrag muss so rückverfolgbar sein, dass ein Incident Manager innerhalb weniger Minuten beantworten kann, welcher Agent welchen Teil übernommen hat, welcher Tool-Aufruf fehlgeschlagen ist und welche Nutzerwirkung daraus entstand.
6. Multi-Agent-Betrieb braucht einen bewusst geplanten Human-Fallback
Viele Teams denken bei Agenten zuerst an Automatisierung, zu selten aber an kontrolliertes Scheitern. Gerade weil A2A für Zusammenarbeit und langlaufende Aufgaben gedacht ist, muss vorab klar sein, wann eine Kette an Menschen zurückfällt. Sonst bleibt ein Auftrag irgendwo zwischen zwei Agenten hängen oder produziert ein halbfertiges Ergebnis, das niemand verantwortet.
Ein guter Fallback ist nicht nur ein generischer Hinweis wie „Bitte wenden Sie sich an den Support“. Er beschreibt konkret, welche Informationen übergeben werden: ursprünglicher Auftrag, letzter bekannter Status, beteiligte Agenten, genutzte Tools, Fehlerklasse und empfohlener nächster Bearbeitungsschritt. So wird aus dem Fallback kein Reset, sondern ein geordneter Übergang.
Besonders wichtig ist das in servicekritischen Pfaden, etwa bei Zugriffsproblemen, Betriebsstörungen, Freigaben oder providerübergreifenden Workflows. Genau dort steigt der Nutzen von Agenten am stärksten, aber auch der Schaden bei unklaren Übergaben. Ein geplanter Human-Fallback ist deshalb kein Zeichen mangelnden Vertrauens, sondern Teil eines sauberen Betriebsmodells.
Was daraus 2026 praktisch folgt
- MCP sollte als Integrationsschicht für Tools und Kontext geführt werden, nicht als diffuse „KI-Verbindung“.
- A2A sollte als Delegations- und Aufgabenprotokoll mit eigenem Zustandsmodell eingeführt werden.
- Beide Ebenen brauchen Owner, Inventarisierung, Logging und klar getrennte Freigaberechte.
- Schreibende Aktionen sollten nie still in einer Agentenkette verschwinden.
- Service Desk, Plattform, Security und Fachverantwortliche brauchen eine gemeinsame Sicht auf Fehlerpfade und Übergaben.
Fazit
A2A und MCP sind mehr als neue Akronyme im KI-Markt. Zusammen bilden sie gerade die technische Grundlage dafür, dass Unternehmens-KI von einzelnen Assistenten zu verteilten Arbeitsketten wächst. Genau deshalb darf ihre Einführung nicht nur aus API-Tests und Demos bestehen. Wer Tool-Anschluss, Delegation, Zuständigkeit, Freigabe, Nachverfolgung und Human-Fallback früh sauber trennt, schafft etwas Seltenes: nicht nur beeindruckende Agenten, sondern einen steuerbaren Service. Und genau das ist am Ende die eigentliche Reifeprüfung für KI im Unternehmensbetrieb.
