Von der API zur Agententopologie: MCP und A2A

Es gibt einen Moment in fast jeder KI-Demonstration, an dem die Zukunft kurz sehr einfach aussieht. Ein Mensch formuliert ein Ziel, die Maschine versteht, ein Agent plant, prüft, bucht, verschickt, aktualisiert. Was eben noch nach Verwaltungsarbeit klang, erscheint plötzlich als Dialog mit einem System, das die Dinge einfach erledigt.

Genau darin liegt die Täuschung.

Nicht weil diese Demonstrationen falsch wären. Sprachmodelle können Absichten interpretieren, Zwischenschritte planen, Werkzeuge auswählen. Das ist nicht trivial — aber es ist auch nicht der Punkt, an dem Organisationen heute scheitern. Die aktuelle Debatte dreht sich noch immer um Modelle: welches halluziniert weniger, welches verarbeitet längere Kontexte, welches schreibt eleganteren Code. Diese Fragen sind nicht unwichtig, aber sie verdecken, dass sich der eigentliche Engpass längst verschoben hat. Das Modell ist nicht mehr das Zentrum des Problems. Das Zentrum des Problems ist die Welt, in der es handeln soll.

Nehmen wir einen einfachen Vorgang: Eine Ärztin hat an einer zertifizierten Fortbildungsveranstaltung teilgenommen und möchte ihre Bescheinigung erhalten. Für einen Menschen in einer Geschäftsstelle klingt das überschaubar. Es gibt eine Veranstaltung, eine Teilnehmerin, eine Anwesenheit, CME-Punkte, eine Bescheinigung, eine E-Mail.

Für ein agentisches System ist derselbe Vorgang eine organisatorische Prüfung mit vielen offenen Variablen. War die Person korrekt angemeldet? Gilt die Teilnahme als vollständig und nach welchem Kriterium? Ist die Veranstaltung formal zertifiziert? Gelten unterschiedliche Regeln für Mitglieder und Nichtmitglieder? Darf die Bescheinigung automatisch erstellt werden oder braucht es eine Freigabe? Gibt es offene Rechnungen? Wurde der Name korrekt aus dem Mitgliederprofil übernommen, und welche Version des Veranstaltungstitels ist maßgeblich, die interne, die veröffentlichte oder die zertifizierte?

Schon dieser kleine Vorgang zeigt, warum KI-Agenten im Organisationskontext keine besseren Chatbots sind. Sie betreten ein Geflecht aus Daten, Rechten, Zuständigkeiten, Ausnahmen und stillschweigenden Regeln. Für Menschen ist vieles davon so vertraut, dass es unsichtbar geworden ist. Man weiß, wen man fragt. Man kennt den Sonderfall. Man erkennt im System sofort, dass ein Datensatz merkwürdig aussieht, und schickt lieber noch eine kurze Rückfrage an die Kollegin, bevor etwas herausgeht.

Ein Agent weiß nichts davon. Er weiß nur, was ihm zugänglich gemacht wurde, und er darf nur tun, was ihm explizit erlaubt wurde. Die zentrale Frage agentischer Systeme lautet deshalb nicht: Was kann das Modell? Sondern: Was darf es, woher weiß es das und wer trägt die Verantwortung, wenn es falsch liegt?

Und damit stellt sich eine Frage, die oft erst spät gestellt wird: Was für ein System liegt eigentlich hinter dem Bescheinigungsprozess? Die meisten Plattformen haben irgendeine Form von API. Die entscheidende Frage ist, ob das System Zusammenhänge kennt. Ob Veranstaltungen, Personen, Mitgliedschaften, Freigabestatus und Kommunikationswege als modellierte Struktur existieren oder nur als lose Inhalte nebeneinanderliegen. Der Unterschied zwischen einem Redaktionssystem und einer agentisch benutzbaren Plattform hängt genau daran.

Die erste technische Antwort auf das Infrastrukturproblem lautet meist: Dafür haben wir doch APIs. Das stimmt, ohne Schnittstellen kann ein Agent wenig mehr tun als lesen, schreiben und raten, aber eine offene Tür ist noch keine Orientierung.

Eine klassische API setzt voraus, dass das aufrufende System bereits weiß, was es tun will. Die verfügbaren Endpunkte, ihre Parameter, ihre Rückgabewerte sind zur Entwicklungszeit festgelegt und im Code hinterlegt. Der Entwickler hat GET /api/events/{id} geschrieben, weil er wusste, dass dieser Endpunkt existiert. Ein Agent, der zur Laufzeit mit einem unbekannten System interagieren soll, hat dieses Vorwissen nicht. Er müsste für jede neue Umgebung neu programmiert werden. APIs wurden für Software gebaut, die weiß, was sie tut; nicht für autonome Systeme, die eine Umgebung erst erkunden müssen.

Genau hier liegt der konzeptuelle Fortschritt von Tool Calling und, einen Schritt weiter, des Model Context Protocol (MCP). Tool Calling erlaubt es einem Sprachmodell, statt eines Textes eine strukturierte Funktion aufzurufen — eine Suche zu starten, einen Datensatz abzufragen, eine Aktion auszulösen. MCP geht weiter: Ein MCP-Server beschreibt sich selbst mit einem maschinenlesbaren Schema. Er teilt dem Agenten zur Laufzeit mit, welche Werkzeuge er anbietet, was sie leisten, welche Parameter sie erwarten und was sie zurückgeben. Und das in einer Form, die das Sprachmodell direkt interpretieren kann. Statt GET /api/events/{id} sieht der Agent eine Werkzeugbeschreibung wie: „get_event_details: Gibt Teilnahmeregeln, Zertifizierungsstatus und offene Rechnungen für eine Veranstaltung zurück. Benötigt: event_id."

Das verschiebt Integration von starrer API-Anbindung zu maschinenlesbarer Werkzeugbeschreibung: Ein Agent kann prinzipiell dynamischer mit Werkzeugen arbeiten, weil deren Fähigkeiten nicht vollständig zur Entwicklungszeit hartcodiert sein müssen. Das ersetzt keine Rechteprüfung, keine Datenmodellierung und keine fachliche Governance — aber es ist der eigentliche Fortschritt, nicht die Intelligenz des Modells, sondern die Selbstbeschreibung der Umgebung.

Der eigentliche konzeptuelle Sprung liegt dort, wo Agenten nicht mehr nur mit Systemen sprechen, sondern miteinander. Das Agent-to-Agent-Protokoll (A2A), verschiebt die Architektur grundlegend: Statt eines zentralen Agenten, der Werkzeuge bedient, entsteht ein Geflecht spezialisierter Instanzen, die einander Aufgaben übergeben, Fähigkeiten anbieten, Ergebnisse zurückmelden und Zustände weiterreichen.

Zurück zur Ärztin. Ihr Fortbildungs-Agent nimmt die Anfrage entgegen und beauftragt spezialisierte Agenten: Der Veranstaltungs-Agent bestätigt, ob die Veranstaltung stattgefunden hat und welche Zertifizierungsregeln gelten. Der Mitglieder-Agent prüft Status und Stammdaten. Der Teilnahme-Agent vergleicht Anmeldung, Check-in und Anwesenheitsdauer. Der Abrechnungs-Agent meldet, ob offene Vorgänge existieren. Der Dokumenten-Agent bereitet die Bescheinigung vor. Auf dem Papier wirkt das elegant. In der Praxis entsteht sofort eine heikle Frage: Was passiert, wenn diese Agenten nicht dasselbe Bild der Realität liefern? Der Teilnahme-Agent sagt anwesend. Der Zertifizierungs-Agent meldet, dass die Freigabe noch aussteht. Der Abrechnungs-Agent findet eine offene Rechnung aus dem Vorjahr. Der Kommunikations-Agent könnte währenddessen längst eine freundliche E-Mail formulieren.

Wer entscheidet?

Die naheliegende Antwort wäre ein weiterer Agent: ein Orchestrator, der die Rückmeldungen der anderen Agenten sammelt, Konflikte erkennt, Prioritäten setzt und entscheidet, wann ein Mensch eingeschaltet werden muss (Human in the Loop). Doch damit verschwindet das Problem nicht. Es wandert nur eine Ebene höher. Denn auch dieser Orchestrator braucht Regeln: Welche Quelle ist im Zweifel führend? Welche Entscheidung darf automatisch fallen? Welche Abweichung ist harmlos, welche eskalationspflichtig? Und wer prüft den Agenten, der die anderen Agenten prüft? Aus einem einfachen Vorgang wird so kein linearer Prozess, sondern eine Agententopologie — und je mehr Systeme beteiligt sind, desto wichtiger wird nicht nur die Fähigkeit zur Kommunikation, sondern die Architektur der Kontrolle.

Das ist der Moment, in dem A2A nicht mehr nach Zukunftsmusik klingt, sondern nach Verwaltung.

Und dort entsteht ein Authentifizierungsproblem, das klassische Sicherheitsarchitektur nicht vorgesehen hat. In normalen Systemen authentifiziert sich ein Mensch, er erhält ein Token, das bestimmte Berechtigungen trägt, und das System handelt in seinem Auftrag. In einer Agentenkette delegiert Agent A an Agent B, der an Agent C weitergibt. Jede Stufe handelt im Namen der ursprünglichen Anfrage. Aber welches Vertrauen überträgt sich dabei? Hat die Ärztin, als sie die Bescheinigung angefordert hat, implizit autorisiert, dass ein Abrechnungs-Agent drei Delegationsstufen später auf ihre Rechnungshistorie zugreift?

Dieses Problem hat einen Namen in der Sicherheitsforschung: den Confused Deputy, eine Instanz, die im Auftrag einer anderen handelt und dabei versehentlich Rechte ausübt, die ihr ursprünglich nicht übertragen wurden. OAuth-Scopes haben sich für klar umrissene Zugriffsszenarien etabliert: Eine Anwendung erhält begrenzten Zugriff auf bestimmte Ressourcen eines Nutzers. Agentenketten verschieben dieses Modell, weil Berechtigungen nicht nur erteilt, sondern über mehrere Zwischenschritte weitergegeben, eingeschränkt und begründet werden müssen. Für solche mehrstufigen Delegationsketten gibt es heute noch kein allgemein etabliertes Standardmodell, das technische Autorisierung, Zweckbindung, Delegationstiefe und organisatorische Verantwortung gleichermaßen sauber abbildet.

A2A adressiert das teilweise über Agent Cards, also maschinenlesbare Fähigkeits- und Identitätsbeschreibungen, die angeben, was ein Agent anbietet, wie er erreichbar ist und welche Sicherheitsmechanismen vorgesehen sind. Signaturen können helfen, Authentizität und Integrität solcher Agent Cards zu prüfen. Aber die Governance-Frage (wie tief Delegationsketten gehen dürfen und welche Berechtigungen sich dabei übertragen) hat das Protokoll allein nicht beantwortet. Sie muss in der Organisation beantwortet werden.

Sobald mehrere Agenten zusammenarbeiten, entsteht ein Problem, das Organisationen gut kennen: Zuständigkeit. Wer darf prüfen? Wer darf entscheiden? Wer darf vorbereiten? Wer darf im Namen der Organisation kommunizieren? Menschen bewegen sich ständig durch informelle Strukturen. Sie wissen, welche Kollegin man kurz fragt, welche Ausnahme üblich ist, welcher Vorgang politisch sensibel ist. Organisationen funktionieren oft gerade deshalb, weil Menschen mehr wissen, als in Systemen steht.

Für Agenten ist das ein strukturelles Problem. Authentifizierung beantwortet, wer oder was zugreift. Autorisierung beantwortet, was diese Instanz tun darf. Governance beantwortet die schwierigere Frage: Unter welchen Bedingungen ist eine Handlung in dieser Organisation verantwortbar? Ein Agent darf vielleicht eine Bescheinigung erzeugen, aber darf er sie auch versenden, wenn eine Rechnung offen ist? Darf er einen Sonderfall erkennen und selbst entscheiden, oder muss er in solchen Situationen einen Menschen einschalten? Solche Fragen gehören nicht allein in die IT. Sie gehören in die Struktur der Organisation, und sie müssen beantwortet sein, bevor ein Agent produktiv eingesetzt werden kann.

Das gilt erst recht für Fehlerzustände. Die meisten digitalen Prozesse werden vom Idealfall her gedacht. Agentische Systeme müssen anders entworfen werden: vom Scheitern her. Was passiert, wenn zwei Systeme widersprüchliche Werte liefern? Wenn eine Berechtigung in der Delegationskette fehlt? Wenn ein Agent die Aufgabe nicht sicher einordnen kann? Ein gutes System darf solche Situationen nicht elegant überspielen, es muss sie sichtbar machen. Manchmal ist ein Agent am nützlichsten, wenn er klar benennt, wo ein Mensch entscheiden muss: „Ich kann die Bescheinigung erstellen, aber nicht versenden, weil die Zertifizierungsfreigabe fehlt.„ Oder: „Ich finde widersprüchliche Anwesenheitsdaten und empfehle eine manuelle Prüfung.“

Und damit stellt sich eine Anforderung, die in der KI-Debatte fast nicht vorkommt: Nachvollziehbarkeit auf einer Ebene, die aktuelle Log-Systeme strukturell nicht liefern.

In klassischen Anwendungen protokollieren Logs Aktionen: Nutzer A hat Datensatz B um 14:32 Uhr geändert. Das reicht für menschliche Akteure, weil ein Mensch im Zweifel befragt werden kann. Bei Agenten fehlt diese Rückfalloption. Was ein agentisches System protokollieren muss, ist kein bloßes Aktions-Log, sondern ein Entscheidungs- und Herkunftsprotokoll: Welche Aufgabe wurde von welchem Agenten übergeben? Welche Datenquellen wurden zum Entscheidungszeitpunkt konsultiert, und was haben sie zurückgegeben? Hat der Agent Unsicherheit erkannt und wie hat er sie behandelt? Welche Regel oder welcher Guardrail hat die Aktion ausgelöst oder verhindert? Was war der Zustand des gesamten Vorgangs, bevor die Handlung stattfand?

Das ist fundamental anders als ein klassisches Audit-Log. Es geht nicht darum festzuhalten, was passiert ist, sondern warum ein automatisiertes System entschieden hat, dass es passieren soll. In regulierten Bereichen, etwa bei medizinischen Fachgesellschaften oder Zertifizierungsprozessen, kann genau diese Nachvollziehbarkeit entscheidend werden — fachlich, organisatorisch und im Zweifel auch rechtlich. Der Agent darf nicht zur Blackbox werden, die nachträglich höflich erklärt, warum sie vermutlich richtig lag.

Wer diese Nachvollziehbarkeit ernst nimmt, landet schnell bei einem zweiten Problem: Die Protokolle selbst werden zur Infrastruktur. Jeder Agentenkontakt erzeugt Metadaten. Jede Übergabe braucht Kontext. Jede Entscheidung benötigt Herkunft, Zeitpunkt, Beteiligte, Quellenstand, Berechtigungslage und Ergebnisstatus. In komplexen Prozessen entsteht dadurch nicht ein Logfile, sondern ein maschinenlesbares Vorgangsgedächtnis. Dieses Gedächtnis muss wiederum gestaltet werden, es darf nicht alles speichern, nur weil es technisch möglich ist. Es muss unterscheiden zwischen entscheidungsrelevanten Spuren und Rauschen, zwischen Auditierbarkeit und Datenmüll, zwischen notwendiger Transparenz und neuer Unübersichtlichkeit. Auch Nachvollziehbarkeit braucht Design.

Wer bestimmt, was in diesem Protokoll festgehalten wird? Wer hat Zugriff, wer prüft, und wie lange muss es nach welchen Anforderungen aufbewahrt werden? Das sind keine IT-Entscheidungen. Das sind Führungsentscheidungen. Niemand diskutiert derzeit, welche Log-Architektur ein Unternehmen benötigt — alle diskutieren, welches Modell es nutzt. Das wird sich umkehren.

Und damit schließt sich der Kreis zurück zur Plattform. Für einen Agenten, der im Bescheinigungsprozess verantwortungsvoll handeln soll, ist entscheidend, ob das System Beziehungen explizit abbildet. Ob Veranstaltungen, Personen, Mitgliedschaften, Rollen, Freigaben und Kommunikationswege als modellierte Struktur existieren oder nur als lose Inhalte nebeneinanderliegen. Erst dann wird eine Plattform Teil des organisatorischen Gedächtnisses, auf das ein Agent sich stützen kann, ohne es bei jedem Vorgang neu rekonstruieren zu müssen.

Es ist verführerisch, die Zukunft der KI an den spektakulären Dingen festzumachen: größere Kontextfenster, multimodale Modelle, neue Interfaces. Aber im Alltag von Organisationen werden wahrscheinlich andere Dinge entscheidend: Rechte, Rollen, Status, Freigaben, Schnittstellen, Fehlerzustände, Protokolle, Auditierbarkeit. Begriffe, die nicht nach Zukunft klingen. Eher nach ERP, nach Fachverfahren, nach langen Workshops mit Prozessdiagrammen. Aber genau dort entscheidet sich, ob Agenten mehr werden als beeindruckende Demos.

Agentenfähigkeit ist keine Eigenschaft eines Modells. Sie ist keine Funktion, die man einkauft oder freischaltet. Sie entsteht dort, wo Prozesse explizit genug sind, um delegiert zu werden, Rollen klar genug, um begrenzt zu werden, und Fehler sichtbar genug, um bearbeitbar zu bleiben.

Agentenfähigkeit ist eine Eigenschaft von Organisationen.

Wer seine eigenen Prozesse nicht beschreiben kann, wird sie keinem Agenten übergeben können. Und wer es trotzdem tut, delegiert nicht Arbeit, sondern Verantwortung. Genau darin liegt die unbequeme Pointe der nächsten KI-Phase: Nicht Maschinen müssen zuerst lernen, Organisationen zu verstehen. Organisationen müssen lernen, sich selbst so zu strukturieren, dass Maschinen in ihnen handeln können, ohne Verantwortung zu verschleiern.

Das ist keine Frage, die ein besseres KI-Modell beantwortet.