Wie MCP und A2A das Design von KI-Automatisierung verändern

Kurzantwort

MCP und A2A machen KI-Automatisierung weniger zu einer Prompt-Frage und stärker zu Verbindungsdesign. MCP betrifft den Zugriff auf Tools und Daten. A2A betrifft Übergaben zwischen Agenten. In der Praxis bleiben Rechte, Logs, Freigaben, Ausnahmen und Verantwortung die entscheidenden Punkte.

Wichtigste Punkte

MCP passt vor allem zur Verbindung von Agenten mit Tools und Daten.
A2A passt vor allem zu Übergaben zwischen spezialisierten Agenten.
Mehr Interoperabilität ersetzt keine klare Verantwortung im Betrieb.
Beginnen Sie mit Lesen und Entwürfen, bevor Agenten Aktionen ausführen.
Abbruchkriterien entstehen bei unklarer Zuständigkeit, fehlenden Logs und nicht rückholbaren Aktionen.

Geeignet für: Serviceplanung, Betrieb, Produktteams und Sicherheitsprüfung, die KI-Automatisierung in echte Abläufe bringen.
Thema: Automatisierung
Zuletzt geprüft: 15. Juni 2026

Behandelte Tools

Model Context Protocol
Agent2Agent Protocol
Google ADK
OpenAI Agents SDK
Responses API

Workflow-Snapshot

Eine kompakte Karte, um diesen Guide in einen Automationsablauf zu übersetzen.

01 Input
Kläre zuerst die wiederkehrende Aufgabe, benötigte Daten, Verantwortliche und Erfolgskriterien.
02 KI-Schritt
Setze KI dort ein, wo Entwurf, Sortierung, Zusammenfassung, Routing oder Tool-Aufrufe klar begrenzt sind.
03 Menschliche Prüfung
Genehmigungen, Ausnahmen, Kostenlimits und sensible Entscheidungen bleiben in menschlicher Prüfung.
04 Ergebnis
Überführe das Ergebnis in eine Checkliste, gespeicherte Prompts, eine SOP oder einen überwachten Automationslauf.

Tools im Ablauf

Model Context Protocol
Agent2Agent Protocol
Google ADK
OpenAI Agents SDK
Responses API

Fokuspunkte

MCP
A2A
KI-Automatisierung
KI-Agenten
Workflow-Automatisierung

Routingdiagramm für KI-Automatisierung mit Geschäftssystemen, Tool-Anschlüssen, Agentenübergaben, Freigaben, Logs und Ausnahmen — MCP und A2A einzubauen heißt nicht nur, mehr Systeme zu verbinden. Die Gestaltung muss zeigen, welche Anfrage wohin geht, welcher Agent übergibt und wo Fehler landen.

Operative Notiz

Erst prüfen, ob das Tool zum Arbeitsablauf passt.

Wenn Input, Freigabepunkt und Fehlerprotokoll unklar sind, beschleunigt Automatisierung nur die Verwirrung.

Entscheidungspunkt

Welche Betriebsregel bleibt gültig, wenn Toolnamen wechseln?

Hilft Verantwortlichen zu entscheiden, wo MCP und A2A in den Ablauf gehören und wo Freigaben, Logs und Ausnahmen sichtbar bleiben müssen.

Unterlagen prüfen

8 Geprüfte öffentliche Quellen

Prüfen Sie veränderliche Funktionen und Preise über die verlinkten Quellen und offiziellen Seiten.

Erster Schritt

Vergleiche

Starten Sie mit einem kleinen Pilotlauf und erweitern Sie erst, wenn der Prüfpunkt klar ist.

Was vor dem Rollout klar sein muss

MCP passt vor allem zur Verbindung von Agenten mit Tools und Daten.
A2A passt vor allem zu Übergaben zwischen spezialisierten Agenten.
Mehr Interoperabilität ersetzt keine klare Verantwortung im Betrieb.
Beginnen Sie mit Lesen und Entwürfen, bevor Agenten Aktionen ausführen.

Workflow-Pfad

Wo dieser Guide einzuordnen ist

Dieser Abschnitt verbindet den aktuellen Guide mit dem größeren Workflow, den er unterstützt.

Tool-Stack-Entscheidungen Den Stack wählen, der zur operativen Reife des Teams passt.

Ein Pfad zum Vergleich von Automationsplattformen, App-Buildern, Agent-Buildern, Buchhaltungstools und KI-Assistenten.

Workflow-Pfad öffnen

Passt gut für: Teams zwischen einfachem Toolkauf, internem Workflow-Aufbau und breiter Plattformentscheidung
Weniger passend, wenn: Du brauchst konkrete Setup-Schritte stärker als einen Entscheidungsrahmen.

Nach einigen KI-Automatisierungsprojekten merkt man: Der Prompt ist selten das Ende der Arbeit. Ein gutes Modell fasst eine Mail zusammen, entwirft eine Antwort, klassifiziert ein Ticket oder zieht Fakten aus einem Dokument. Das ist nützlich. Die eigentliche Betriebsfrage kommt danach. Welche Systeme darf der Agent lesen? Was darf er schreiben? Wann übergibt er an einen anderen Agenten? Was kann ein Mensch später nachvollziehen?

Darum sind MCP und A2A interessant. MCP betrifft vor allem den Zugriff auf Tools und Daten. A2A betrifft die Übergabe von Arbeit zwischen Agenten. Auf dem Papier klingt das wie Protokolltechnik. Im Betrieb wird daraus eine sehr konkrete Frage: Bleibt die Verantwortung lesbar, wenn Agenten mehr Systeme erreichen und miteinander sprechen?

MCP und A2A lösen verschiedene Probleme

MCP ist die Seite für Tool- und Datenzugriff. Ein Agent muss Vertragsdokumente, Kundendaten, Ticketverläufe, Produktnotizen oder interne Richtlinien lesen. Statt jede Verbindung einzeln zu bauen, soll der Zugriff konsistenter werden.

A2A ist die Übergabeseite. Ein Support-Agent erkennt ein Abrechnungsproblem und übergibt an einen Billing-Agenten. Ein Analyse-Agent sammelt Hinweise, ein Reporting-Agent baut den Entwurf, ein Prüf-Agent sucht Lücken. Diese Arbeitsteilung ist wertvoll, aber sie schafft auch neue Bruchstellen.

Bereich	Erste Frage	Risiko im Betrieb
MCP	Welche Tools und Daten darf der Agent erreichen?	Rechte werden schnell breiter als nötig
A2A	Welcher Agent übernimmt den nächsten Teil?	Zuständigkeit verschwindet zwischen Übergaben
Klassische API-Automation	Welche Regel löst welche Aktion aus?	Regeln werden spröde, sobald Ausnahmen wachsen
Menschliche Freigabe	Wo stoppt der Ablauf?	Ohne Kriterien wird Freigabe zu Nacharbeit

Ich würde MCP und A2A deshalb nicht als reine Produktivitätsfunktion behandeln. Sie verändern die Architektur des Ablaufs.

Aus einer Toolliste wird eine Routingkarte

Viele Automatisierungspläne beginnen mit einer Toolliste: E-Mail, CRM, Ticketsystem, Datenbank, Workflow-Builder, Chat-Kanal. Diese Liste bleibt nötig. Sie reicht aber nicht mehr, wenn Agenten Kontext holen und Arbeit weiterreichen können.

Eine Routingkarte ist wichtiger. Sie sagt, welcher Eingang den Ablauf startet, welcher Agent zuerst liest, welche Systeme er mit welchem Recht nutzt, wann er übergibt, wo ein Mensch freigibt, wo Logs stehen und wo Ausnahmen landen.

Ein Beispiel: Eine Kundin schreibt, sie habe letzten Monat gekündigt und sei trotzdem wieder belastet worden. Ein Support-Agent liest die Nachricht, öffnet ein Ticket und ruft über MCP CRM-Status und Abrechnungshistorie ab. Bis hierhin ist es Lesen. Sobald Erstattung, Vertragsänderung oder Kundenversprechen im Raum stehen, ist es Ausführung. Dann sollte ein Billing-Agent übernehmen, die geprüften Daten sehen und bei bestimmten Beträgen oder Sonderverträgen einen Menschen einbinden.

Der Wert liegt nicht darin, dass die Antwort schön klingt. Der Wert liegt darin, dass der Fall mit Begründung, Quellen und offenem Risiko weiterläuft.

Praxisurteil aus dem Betrieb: erst Grenzen, dann Verbindung

Ich prüfe vor der Einführung drei Zonen.

Die erste Zone ist Lesen. Wissenssuche, Kundenstatus, Ticketverlauf, aktuelle Richtlinie, Logzusammenfassung. Hier kann MCP viel Arbeit sparen, weil der Agent Material zusammenträgt, das Menschen sonst manuell öffnen.

Die zweite Zone sind Entwürfe. Antwortvorschläge, interne Notizen, Freigabememos, Aufgaben, Berichtszusammenfassungen. Hier entsteht oft echter Nutzen. Aber ein Entwurf braucht Belege. Wenn der Agent eine Erstattung empfiehlt, muss er zeigen, welche Datensätze und welche Regel er genutzt hat.

Die dritte Zone ist Ausführung: Erstattung, Kundenmail, Rechteänderung, Deployment, Datenlöschung, Statusänderung. Hier wäre ich zurückhaltend. A2A macht Koordination einfacher, aber Koordination ist keine Freigabe. Ausführung braucht Schwellenwerte, Logs, Rollback, Benachrichtigung und einen benannten Verantwortlichen.

Nicht wählen würde ich breite Agentenübergaben, wenn die Regel noch in den Köpfen einzelner Mitarbeiter steckt. Auch nicht, wenn falsche Aktionen schwer rückgängig zu machen sind. Das Protokoll löst diese Lücke nicht; es kann sie schneller verteilen.

Beispiele zeigen die Bruchstellen

Bei Sales-Leads kann ein Agent Firmendaten suchen, CRM-Historie prüfen, den Lead anreichern und eine Priorität vorschlagen. MCP macht den Rechercheteil sauberer. A2A kann Informationen von einem Research-Agenten an einen Sales-Agenten übergeben, der einen E-Mail-Entwurf erstellt.

Das Problem ist nicht der Text der Mail. Das Problem ist die Bewertung des Leads. Branche, Budget, Rolle, frühere Kontakte, Kampagnenfokus und Vertriebskapazität spielen zusammen. Wenn das Team den Score nicht versteht, prüft es alles neu. Deshalb müssen Score, Gründe, Ausschlusskriterien und nächster Schritt sichtbar bleiben.

Im Monatsabschluss kann ein Agent Rechnungen sammeln, Transaktionen zuordnen und Buchungsvorschläge machen. Die endgültige Klassifikation und Ausnahmen brauchen aber Freigabe. Für Audit und Steuern reicht “der Agent hat es so entschieden” nicht. Quelle, Regel und Freigabe müssen im Datensatz stehen.

Bei Sicherheitsprüfungen ist die Grenze noch enger. Ein Agent kann Logs lesen und verdächtige Muster markieren. Rechte oder Firewall-Regeln automatisch zu ändern ist eine andere Kategorie. Je mehr Tools ein Agent nutzen kann, desto wichtiger werden minimale Rechte und nachvollziehbare Toolnutzung.

Abbruchkriterien kommen aus blockierter Arbeit

Ein vernetzter Agentenablauf kann im ersten Durchlauf gut aussehen und trotzdem scheitern. Ich würde auf diese Signale achten.

Fehlsignal	Sofortmaßnahme
Agenten reichen denselben Fall weiter	Routing reduzieren und einen Endverantwortlichen benennen
Prüfer verstehen die Begründung nicht	Toolaufrufe, Quellen und Übergabegrund mitspeichern
Prüfzeit sinkt nicht	Umfang zurück auf Lesen und Entwürfe setzen
Rechteanforderungen wachsen	Mindestberechtigungen je Agentenrolle neu schreiben
Ausnahmen kommen zu spät hoch	Ausnahmewarteschlange und Alerts früher setzen
Kein Rollback ist möglich	Schreibaktionen stoppen, bis Wiederherstellung steht

Gute Automatisierung muss gerade im Fehlerfall lesbar sein. Wer hat die Arbeit angestoßen, welches Tool wurde genutzt, warum wurde übergeben, wer hat freigegeben, wo liegt das Ergebnis? Wenn diese Fragen nicht schnell beantwortet werden, ist der Ablauf noch nicht reif.

Die erste Seite vor dem Bau

Vor der Umsetzung würde ich eine Seite schreiben.

Feld	Inhalt
Eingang	Mail, Formular, Ticket, Dokument, Log oder Ereignis
Erster Agent	Wer liest, klassifiziert und routet zuerst
MCP-Tools	Systeme mit getrenntem Lese- und Schreibumfang
A2A-Übergabe	Bedingungen für die Übergabe an einen anderen Agenten
Menschliche Freigabe	Beträge, Risiken, Kundenarten oder Aktionen, die stoppen müssen
Logs	Toolaufrufe, Quellen, Übergabegrund, Freigeber, Ergebnis
Ausnahmeweg	Queue oder Owner für unklare und fehlgeschlagene Fälle
Metrik	Zeitersparnis, Nacharbeitsquote, Fehlerquote, Eingriffe

Wenn diese Seite leer bleibt, ist der Ablauf nicht bereit. Ein anderes Modell löst das nicht. Ein weiterer Agent löst es auch nicht.

MCP und A2A sind sinnvoll, weil sie KI-Automatisierung aus der Prompt-Ecke in die Ablaufarchitektur bringen. Genau deshalb braucht der Betrieb mehr Disziplin. Erst lesen, dann belegte Entwürfe, dann Übergaben, danach freigegebene Ausführung. Diese Reihenfolge ist unspektakulär, aber sie verhindert die meisten teuren Fehler.

Ein realistischer Startplan

Ich würde nicht in der ersten Woche alle Systeme verbinden. Zuerst wähle ich einen Ablauf, der nur liest: Supporthistorie zusammenfassen, Lead-Recherche vorbereiten, Daten für einen Betriebsbericht prüfen. Gemessen wird nicht, ob die Antwort elegant klingt. Gemessen wird, ob die Prüfzeit der verantwortlichen Person sinkt.

Danach kommen Entwürfe mit Belegen. Der Agent schreibt nicht nur eine Antwort, sondern zeigt Quellen, Ausschlussgründe und offene Punkte. Wenn die Nacharbeit in dieser Phase nicht sinkt, ist eine breite A2A-Kette zu früh.

Erst danach würde ich freigegebene Aktionen testen. Auch dann nicht als Standard. Beträge, Kundenwirkung, Sicherheit, Löschung und externe Kommunikation bleiben Stopppunkte. Im Betrieb ist es besser, zuerst die Stopplogik zu bauen und dann die Ausführung zu erweitern.

Häufige Fragen

Sollte man zuerst MCP oder A2A betrachten?

Wenn Tool- und Datenzugriff das Problem ist, zuerst MCP. Wenn Rollen zwischen Agenten aufgeteilt werden sollen, A2A. In beiden Fällen würde ich mit Lesen und Entwürfen beginnen.

Was ist anders als bei normaler API-Automation?

Normale API-Automation folgt festen Regeln. MCP und A2A geben Agenten mehr Kontext und Übergabemöglichkeiten. Das macht den Ablauf flexibler, aber auch schwerer zu prüfen, wenn Logs und Rechte fehlen.

Können Agenten endgültige Aktionen ausführen?

Ja, aber nur bei klar begrenzten und rückholbaren Aktionen. Erstattungen, Rechteänderungen, Kundenzusagen, Löschungen und Deployments brauchen vorher Freigabe, Logs und Wiederherstellung.