Von Chatbots zu AI-Agenten: MCP, A2A und Multi-Agent-Systeme

Ein Chatbot antwortet. Ein Agent handelt.

Dieser Unterschied bestimmt den Wert von KI in Unternehmen 2026. Ein Chatbot beantwortet Fragen — „Wie viele Urlaubstage habe ich noch?”. Ein Agent führt Prozesse aus. Der Unterschied ist nicht graduell, sondern grundsätzlich.

Ein konkretes Beispiel: Ein Mitarbeiter meldet sich krank. Der HR-Agent nimmt die Krankmeldung entgegen, prüft das Formular auf Vollständigkeit, gleicht den Zeitraum mit dem Dienstplan ab, informiert die Teamleitung, passt die Kapazitätsplanung an und dokumentiert den Vorgang in der Personalakte. Vier Systeme, ein Agent, null manuelle Eingaben. Jeder Schritt nachvollziehbar, jeder Schritt im Audit Trail.

Das ist kein Zukunftsszenario. Das ist der Stand der Technik 2026. Und es ist der Grund, warum die Architektur von KI-Agenten eine strategische Entscheidung ist — nicht eine Aufgabe für die IT-Abteilung allein.

Dieser Artikel beschreibt die Agent-Architektur für Enterprise-Umgebungen, erklärt die neuen Standards MCP und A2A, zeigt fünf konkrete Business Use Cases mit Einsparpotenzial und definiert die Governance-Anforderungen, ohne die kein Agent in Produktion gehen sollte.

Die Agent-Architektur: Fünf Schichten

Ein KI-Agent ist kein monolithisches System. Die Enterprise-Architektur besteht aus fünf Schichten, die jeweils eine klar definierte Aufgabe haben:

┌─────────────────────────────────────────┐
│          Benutzer-Interface              │
│    (very-ai / Teams / Custom)            │
├─────────────────────────────────────────┤
│        Orchestrierungs-Schicht           │
│   (Routing, Regelwerk, Eskalation)       │
├─────────────────────────────────────────┤
│          KI-Modell-Schicht               │
│  (Claude / GPT / Llama – je nach Task)   │
├─────────────────────────────────────────┤
│         Tool-Integration (MCP)           │
│  (ERP, CRM, DMS, E-Mail, Kalender...)    │
├─────────────────────────────────────────┤
│      Governance & Audit Layer            │
│  (Logging, Policies, Human-in-the-Loop)  │
└─────────────────────────────────────────┘

Benutzer-Interface. Die Schicht, über die Mitarbeitende mit dem Agenten interagieren. Das kann ein dediziertes AI-Portal sein (wie in Enterprise-AI-Portal: Mehr als nur ein Chat-Interface beschrieben), eine Integration in Microsoft Teams oder eine Custom-Oberfläche für spezifische Fachbereiche.

Orchestrierungs-Schicht. Hier wird entschieden, welcher Agent eine Aufgabe übernimmt, welches Modell verwendet wird und wann eskaliert wird. Die Orchestrierung kennt die Regelwerke, die Zuständigkeiten und die Eskalationspfade. Sie ist die Schaltzentrale.

KI-Modell-Schicht. Das Sprachmodell, das die eigentliche Verarbeitung leistet — Texte verstehen, Zusammenhänge erkennen, Antworten generieren. In einer modell-agnostischen Architektur ist diese Schicht austauschbar. Ein kostengünstiges Modell für Standardanfragen, ein leistungsfähigeres für komplexe Analysen. Das Routing erfolgt automatisch.

Tool-Integration (MCP). Die Verbindung zu Ihren bestehenden Systemen: ERP, CRM, Dokumentenmanagement, E-Mail, Kalender, Ticketsystem. Über das Model Context Protocol (MCP) greifen Agenten standardisiert auf diese Systeme zu.

Governance & Audit Layer. Jede Agenten-Aktion wird protokolliert. Policies definieren, was ein Agent darf und was nicht. Human-in-the-Loop wird dort erzwungen, wo es erforderlich ist. Diese Schicht ist nicht optional — sie ist die Voraussetzung für den produktiven Einsatz. Der Decision Layer bildet das architektonische Fundament dieser Governance.

MCP und A2A — die neuen Standards

Zwei Protokolle haben 2025/2026 die Art verändert, wie KI-Agenten mit der Außenwelt und miteinander kommunizieren: MCP (Model Context Protocol) und A2A (Agent-to-Agent).

MCP: Der USB-Anschluss für KI

MCP ist ein offener Standard, der KI-Modellen ermöglicht, auf externe Datenquellen und Werkzeuge zuzugreifen. Die Analogie ist treffend: So wie USB eine universelle Schnittstelle für Hardware geschaffen hat, schafft MCP eine universelle Schnittstelle für KI-Integrationen.

Vor MCP musste für jede Kombination aus KI-Modell und Zielsystem ein eigener Konnektor gebaut werden. Agent A greift auf SAP zu — ein Konnektor. Agent B greift auf das DMS zu — ein weiterer Konnektor. Agent C greift auf den Kalender zu — noch ein Konnektor. Bei zehn Systemen und drei Modellen ergeben sich dreißig individuelle Integrationen.

Mit MCP definiert jedes System einmal seine Fähigkeiten in einem standardisierten Format: Welche Daten kann es liefern? Welche Aktionen kann es ausführen? Welche Parameter sind erforderlich? Jedes MCP-kompatible Modell kann diese Fähigkeiten nutzen — ohne systemspezifischen Code.

Für Unternehmen bedeutet das: Neue Systeme können schneller angebunden werden. Modelle können ausgetauscht werden, ohne die Integrationen neu zu bauen. Die Abhängigkeit von einzelnen Modellanbietern sinkt.

A2A: Agenten sprechen miteinander

A2A (Agent-to-Agent) ist das Pendant zu MCP für die Kommunikation zwischen Agenten. Während MCP die Verbindung Agent-zu-System regelt, regelt A2A die Verbindung Agent-zu-Agent.

Warum ist das relevant? Weil komplexe Geschäftsprozesse selten von einem einzelnen Agenten abgedeckt werden. Eine Krankmeldung betrifft HR, Kapazitätsplanung, Gehaltsabrechnung und möglicherweise das Projektmanagement. Jeder Bereich hat einen spezialisierten Agenten. A2A ermöglicht diesen Agenten, Aufgaben delegieren und Ergebnisse austauschen — mit definierten Berechtigungen.

Entscheidend: A2A bedeutet nicht gemeinsamen Datenzugriff. Der HR-Agent übergibt dem Finance-Agent die Information „Mitarbeiter X ist ab Datum Y abwesend” — nicht die vollständige Personalakte. Jeder Agent sieht nur, was er für seine Aufgabe benötigt. Die Berechtigungsgrenzen bleiben gewahrt.

5 Business Use Cases mit konkretem Einsparpotenzial

Die Frage, die Entscheider stellen, ist nicht „Was kann ein Agent?” sondern „Was bringt ein Agent?”. Hier sind fünf Anwendungsfälle mit messbarem Einsparpotenzial:

Bereich	Use Case	Was der Agent tut	Einsparpotenzial
HR	Onboarding	Accounts anlegen, Schulungen zuweisen, Einführungsgespräche planen, Welcome-Mail versenden	4—6 h pro Einstellung
Finance	Rechnungsprüfung	Rechnung lesen, gegen Bestellung prüfen, Kontierung kontrollieren, Freigabe-Workflow auslösen	70—80 % weniger Bearbeitungszeit
Legal	Vertragsanalyse	Klauseln extrahieren, gegen Standardverträge vergleichen, Abweichungen markieren	Stunden statt Tage
IT	Incident-Triage	Fehlermeldung analysieren, Known-Issues abgleichen, Ticket mit Priorität erstellen	Schnellere Erstreaktion
Operations	Lieferanten-Monitoring	Liefertermine überwachen, mit Produktionsplan abgleichen, proaktive Meldung bei Verzug	Frühwarnung statt Nacharbeit

Jeder dieser Use Cases folgt demselben Muster: Der Agent übernimmt den strukturierten, regelbasierten Teil eines Prozesses. Der Mensch übernimmt die Ausnahmen, die Ermessensentscheidungen und die Freigaben. Die Zeitersparnis entsteht nicht durch den Wegfall menschlicher Arbeit, sondern durch den Wegfall manueller Routinetätigkeiten.

HR-Onboarding im Detail. Heute koordiniert ein HR-Sachbearbeiter bei jeder Neueinstellung manuell: IT-Accounts anlegen, Zugriffsrechte konfigurieren, Pflichtschulungen zuweisen, Einführungsplan erstellen, Willkommens-E-Mail formulieren, Gehaltsabrechnung einrichten. Jeder Schritt ein separates System, jeder Schritt eine manuelle Eingabe. Ein Onboarding-Agent orchestriert diese Schritte automatisiert: Er liest den Arbeitsvertrag, erkennt Position, Standort und Abteilung, und führt die Schritte in den jeweiligen Systemen aus. Der HR-Sachbearbeiter gibt den Gesamtvorgang frei — nicht jeden Einzelschritt.

Rechnungsprüfung im Detail. Eine Eingangsrechnung wird vom Document Agent gelesen. Der Agent extrahiert Rechnungssteller, Betrag, Positionen, Bestellnummer. Er prüft automatisch: Gibt es eine zugehörige Bestellung? Stimmen die Positionen und Beträge? Ist die Kontierung korrekt? Liegt der Betrag innerhalb der Freigabegrenzen? Bei positivem Ergebnis wird die Buchung vorbereitet. Bei Abweichungen wird an den zuständigen Sachbearbeiter eskaliert — mit dem konkreten Grund der Abweichung, nicht mit der generischen Meldung „Bitte prüfen”.

Governance-Anforderungen für Agenten

Ein Agent ohne Governance ist ein Risiko. Vier Anforderungen müssen vor dem produktiven Einsatz erfüllt sein:

1. Decision Layer. Jede Agenten-Entscheidung durchläuft den Decision Layer. Für jede Mikro-Entscheidung ist definiert: Darf der Agent autonom handeln, greift ein Regelwerk, oder muss ein Mensch freigeben? Diese Regeln sind versioniert, nachvollziehbar und nicht durch den Agenten selbst änderbar.

2. Human-in-the-Loop. Bei definierten Entscheidungstypen erzwingt die Architektur menschliche Prüfung. Das ist kein Feature, das aktiviert werden kann — es ist ein Architekturprinzip. Der Agent kann die Human-in-the-Loop-Anforderung nicht umgehen, weil sie technisch, nicht organisatorisch durchgesetzt wird.

3. Audit Trail. Jede Agenten-Aktion erzeugt einen unveränderlichen Protokolleintrag: Was war der Input? Welches Modell wurde verwendet? Welche Regel wurde angewandt? Was war das Ergebnis? Wann wurde die Aktion ausgeführt? Der Audit Trail ist die Grundlage für Wirtschaftsprüfung, interne Revision und Betriebsratskontrolle.

4. Rollback. Jede Agenten-Aktion muss rückgängig gemacht werden können. Wenn ein Agent eine fehlerhafte Buchung erzeugt oder eine falsche Benachrichtigung versendet, muss der Vorgang korrigiert werden können — technisch, nicht nur organisatorisch. Rollback-Fähigkeit ist eine Architekturanforderung, keine nachträgliche Ergänzung.

Diese vier Anforderungen sind nicht verhandelbar. Ohne sie wird kein Betriebsrat zustimmen, kein Wirtschaftsprüfer absegnen und kein CIO die Verantwortung übernehmen. Mehr zur Governance-Architektur im nächsten Artikel: Decision Layer & Shadow AI.

Multi-Agent-Systeme: Spezialisierung statt Universalagent

Die nächste Stufe nach dem einzelnen Agenten: mehrere spezialisierte Agenten, die zusammenarbeiten. Nicht ein universeller Agent, der alles kann, sondern Spezialisten, die jeweils eine Domäne beherrschen.

Das Krankmeldungs-Beispiel als Multi-Agent-System:

Krankmeldung eingehend
         │
    Document Agent  →  Liest und klassifiziert die Krankmeldung
         │
      HR Agent      →  Prüft Regeln: Lohnfortzahlung, BEM, Fristen
         │
    Workflow Agent  →  Informiert Teamleitung, passt Dienstplan an
         │
    Finance Agent   →  Aktualisiert Gehaltsabrechnung

Jeder Agent hat eigene Berechtigungen. Der Document Agent kann Dokumente lesen, aber keine Buchungen erzeugen. Der Finance Agent kann die Gehaltsabrechnung anpassen, aber keine Personalakten einsehen. Die Berechtigungsgrenzen sind architektonisch erzwungen — über das A2A-Protokoll kommunizieren die Agenten nur die Informationen, die der empfangende Agent für seine Aufgabe benötigt.

Der Orchestrator-Agent koordiniert den Gesamtablauf. Er weiß, welcher Agent welchen Schritt ausführt, in welcher Reihenfolge, und was bei Fehlern passiert. Der Orchestrator hat Überblick, aber keine operativen Berechtigungen. Er delegiert, er führt nicht selbst aus.

Multi-Agent-Systeme sind leistungsfähig, aber komplex. Die Zahl der Interaktionen wächst quadratisch mit der Zahl der Agenten. Debugging wird aufwendiger. Die Governance-Anforderungen steigen.

Praxis-Empfehlung: Klein anfangen

Die Versuchung ist groß, direkt mit einem Multi-Agent-System zu starten. Die Empfehlung ist klar: Starten Sie mit einem einzelnen Agenten für einen klar definierten Prozess.

Schritt 1: Einen Prozess identifizieren, der strukturiert, regelbasiert und häufig genug ist, um den Aufwand zu rechtfertigen. Rechnungsprüfung, Onboarding, Vertragsanalyse — einer davon.

Schritt 2: Einen einzelnen KI-Agenten für diesen Prozess aufsetzen. Mit Decision Layer, mit Human-in-the-Loop, mit Audit Trail. Nicht als Prototyp, sondern als produktives System.

Schritt 3: Messen. Durchlaufzeit vorher und nachher. Fehlerquote. Kosten pro Vorgang. Zufriedenheit der Sachbearbeiter.

Schritt 4: Erst wenn der erste Agent stabil läuft, den zweiten planen. Und erst wenn mehrere Agenten stabil laufen, über Multi-Agent-Orchestrierung nachdenken.

Dieser Ansatz ist nicht konservativ. Er ist pragmatisch. Ein funktionierender Agent mit nachweisbarem Nutzen ist mehr wert als ein ambitioniertes Multi-Agent-Konzept, das in der Pilotphase steckenbleibt.

Die Infrastruktur — Modell-Hosting, Vektordatenbanken, Orchestrierungs-Engine, API-Gateway — wird beim ersten Agenten aufgebaut und steht dann für jeden weiteren zur Verfügung. Die Investition in den ersten Agenten ist gleichzeitig die Investition in die Plattform.

Wo diese Agenten konkret laufen — auf welcher Plattform — zeigt Artikel 10: Agent-Orchestrierung.

---

📘 Enterprise AI-Infrastruktur Blueprint 2026 – Artikel-Serie

← Vorheriger	Übersicht	Nächster →
RAG & Document Intelligence: Wie KI Ihre Dokumente versteht	Zur Übersicht	Decision Layer & Shadow AI: Kontrolle statt Kontrollverlust

Alle Artikel dieser Serie: Enterprise AI-Infrastruktur Blueprint 2026

---

Sie wollen den ersten KI-Agenten für einen konkreten Geschäftsprozess aufsetzen? Gosign begleitet Enterprise-Kunden von der Prozessanalyse bis zum produktiven Agenten — modell-agnostisch, mit Decision Layer und vollständigem Audit Trail.

Termin vereinbaren — 30 Minuten, in denen wir den richtigen ersten Use Case für Ihr Unternehmen identifizieren.