Der Engpass war nie das Modell
Fragen Sie Unternehmen, warum ihr KI-Pilotprojekt stecken geblieben ist — die Antwort betrifft selten das Modell.
Das Modell konnte gut genug schlussfolgern. Was es nicht konnte: den Vertrag im Dokumentenmanagementsystem lesen, den Lagerbestand im ERP prüfen, die Kundenhistorie im CRM nachschlagen und das Ergebnis zurückschreiben — zuverlässig, mit intakten Berechtigungen, jedes Mal.
Schlussfolgern ist weitgehend zur Standardware geworden. Der Zugang ist die Einschränkung. Und beim Zugang verwandeln sich Agentenprojekte unauffällig in Integrationsprojekte.
Das N×M-Problem
Bevor es einen Standard gab, war jede Verbindung zwischen Agent und System eine Einzelanfertigung.
Bei vier Agenten und sechs internen Systemen pflegten Sie bis zu vierundzwanzig eigene Integrationen. Jede mit eigener Authentifizierung, eigener Fehlersemantik, eigener Vorstellung davon, wie sie ihre Fähigkeiten beschreibt. Änderte sich die ERP-Schnittstelle, mussten Sie jeden Agenten anpassen, der sie berührte.
Die Branche hat dieses Problem in anderen Bereichen schon mehrfach gelöst — Gerätetreiber, Datenbankanbindung, Language Server in Code-Editoren. Die Lösung hat immer dieselbe Form: keine Punkt-zu-Punkt-Verbindungen mehr bauen, sondern sich auf ein Protokoll in der Mitte verständigen. Aus N×M Integrationen werden N+M.
Das Model Context Protocol (MCP) ist dieses Protokoll für KI-Agenten. Von Anthropic als offener Standard eingeführt und inzwischen weit darüber hinaus implementiert, definiert MCP, wie eine KI-Anwendung die Fähigkeiten externer Systeme entdeckt und aufruft.
Was MCP tatsächlich standardisiert
MCP ist ein Client-Server-Protokoll. Ihre KI-Anwendung ist der Host und enthält einen oder mehrere Clients. Jeder Client verbindet sich mit einem MCP-Server — einem schlanken Adapter, der vor einem System sitzt und maschinenlesbar beschreibt, was dieses System kann.
Der Server stellt drei Arten von Primitiven bereit:
- Tools — Aktionen, die der Agent auslösen kann: eine Rechnung erstellen, Verträge durchsuchen, den Lagerbestand prüfen. Jedes Tool bringt ein Schema seiner Parameter mit, damit der Agent weiss, wie er es korrekt aufruft, statt zu raten.
- Resources — Daten, die der Agent lesen kann. Ein Dokument, ein Datenbankeintrag, ein Verzeichnisbaum. Adressierbar und abrufbar, ohne Nebenwirkungen.
- Prompts — wiederverwendbare Anweisungsvorlagen, die der Server für typische Aufgaben gegen dieses System anbietet. So liegt das Domänenwissen beim Konnektor und wird nicht in jedem Agenten neu erfunden.
Die entscheidende Folge: Die Beschreibung der Fähigkeiten ist Aufgabe des Servers, nicht des Agenten. Ein MCP-Server für Ihr ERP wird einmal geschrieben — von jemandem, der das ERP versteht — und jeder Agent in Ihrem Unternehmen kann ihn nutzen.
Warum das die Unternehmensarchitektur verändert
Der architektonische Wandel ist schnell beschrieben und in der Praxis bedeutend: Integration wird ein wiederverwendbares Gut statt Kosten pro Projekt.
Daraus folgt einiges.
Konnektoren überleben Agenten. Agenten sind günstig neu zu schreiben und werden häufig neu geschrieben, wenn sich Modelle und Anforderungen ändern. Ein MCP-Server für Ihren Dokumentenspeicher ist stabile Infrastruktur. Die Trennung bedeutet, dass Modellwechsel Ihre Integrationsschicht nicht mehr bedrohen.
Eine Integrationsfläche zum Absichern. Statt Zugangsdaten zu prüfen, die über Agenten-Codebasen verstreut sind, haben Sie eine definierte Grenze pro System. Authentifizierung, Berechtigungsumfang, Rate Limiting und Logging leben im Server.
Ein Fähigkeitsinventar wird möglich. Wenn sich jedes System über dasselbe Protokoll zeigt, können Sie die Frage "Was können unsere Agenten eigentlich?" beantworten — und das ist lange vor einer technischen eine Governance-Frage.
Die Anbieterbindung sinkt. Ein Konnektor, der gegen ein Protokoll statt gegen ein bestimmtes Agenten-Framework geschrieben ist, übersteht den Wechsel des Frameworks oder des Modellanbieters.
Wie ein guter Server aussieht
Der typische Fehler beim ersten MCP-Server ist, die darunterliegende API eins zu eins zu spiegeln — vierzig Endpunkte als vierzig Tools bereitstellen und die Sache für erledigt erklären.
Das ergibt einen technisch korrekten Server, den Agenten schlecht nutzen. Ein besserer Server ist um Aufgaben statt um Endpunkte herum entworfen.
Zwei Entwürfe für dasselbe ERP im Vergleich:
| Endpunkt-spiegelnder Entwurf | Aufgabenorientierter Entwurf |
|---|---|
| Fünf getrennte Abfragen für Kunde, Aufträge, Auftragspositionen, Lieferungen, Rechnungen | Ein Tool: Auftragshistorie eines Kunden abrufen |
| Der Agent verkettet fünf Aufrufe und kann die Reihenfolge verfehlen | Ein Aufruf, korrekte Verknüpfungen serverseitig garantiert |
| Fehlerquellen vervielfachen sich mit jedem Aufruf | Fehlerbehandlung an einer Stelle |
Der aufgabenorientierte Server leistet intern mehr und gibt dem Agenten deutlich weniger Gelegenheit, etwas falsch zu machen. Praktische Leitlinien:
- Benennen Sie Tools nach Absicht, im Vokabular, das Ihr Unternehmen bereits verwendet.
- Schreiben Sie Beschreibungen für einen fähigen Neueinsteiger. Sie werden vom Modell gelesen und entscheiden massgeblich darüber, ob ein Tool korrekt eingesetzt wird.
- Geben Sie Fehler zurück, die einen nächsten Schritt vorschlagen, keine rohen Stacktraces. "Kunde nicht gefunden — versuchen Sie die Suche nach Name" ist handlungsfähig; ein nacktes 404 nicht.
- Halten Sie Antworten schlank. Jedes unnötige Feld verbraucht Kontext, den der Agent zum Schlussfolgern braucht.
- Trennen Sie Lesen von Schreiben. Getrennte Tools, getrennte Berechtigungen, getrennte Auditbehandlung.
Zugriffskontrolle ist der schwierige Teil
MCP standardisiert, wie Fähigkeiten beschrieben werden. Es entscheidet nicht, wer sie nutzen darf — und genau dort wird es in Unternehmen tatsächlich schwierig.
Drei Fragen sollten geklärt sein, bevor ein Server Produktivdaten berührt.
Wessen Berechtigungen gelten? Ein Agent, der im Auftrag einer bestimmten Person handelt, sollte deren Rechte erben und kein Dienstkonto besitzen, das alles sehen kann. Die Bequemlichkeit eines Dienstkontos am Anfang ist der häufigste Weg, auf dem Agentenprojekte ein Berechtigungsproblem erwerben, das sich später nicht mehr entwirren lässt.
Wie gross ist die Schadensreichweite jedes Tools? Ein Lese-Tool gegen eine Reporting-Replik und ein Schreib-Tool, das Zahlungen auslöst, gehören in unterschiedliche Risikoklassen mit unterschiedlichen Freigabeanforderungen. Beide gleich zu behandeln heisst, entweder das Harmlose zu stark einzuschränken oder das Gefährliche zu wenig.
Ist die Nachvollziehbarkeit ausreichend? Jeder Aufruf muss zuordenbar sein — welcher Agent, in wessen Auftrag, mit welchen Argumenten, mit welchem Ergebnis. In regulierten schweizerischen und europäischen Umgebungen ist das nicht optional, und nachträglich einzubauen ist es deutlich schwieriger.
Auch die Datenlokalität verschwindet nicht, weil ein Protokoll im Spiel ist. Der MCP-Server ist genau der Ort, an dem Sie durchsetzen, dass ein Dokument eine bestimmte Rechtsordnung nie verlässt — ein Kontrollpunkt, den man bewusst entwerfen sollte, statt ihn später zu entdecken.
Wo MCP endet
MCP ist ein Verbindungsprotokoll. Es ist kein Agenten-Framework, und es ist keine Orchestrierung.
Es sagt nichts darüber, wie Arbeit auf mehrere Agenten verteilt wird, wie Zustand über einen langlaufenden Prozess erhalten bleibt, wie Wiederholungen und kompensierende Aktionen behandelt werden oder wie Sie bewerten, ob ein Agent seine Aufgabe gut erledigt hat. Das bleiben Ihre Entwurfsentscheidungen — unsere KI-Orchestrierung adressiert die Schicht, die über der Verbindungsschicht liegt.
Diese Grenze klar zu benennen ist nützlich. MCP beseitigt eine Kategorie undifferenzierter Integrationsarbeit. Es beseitigt nicht die Notwendigkeit, über Prozessgestaltung nachzudenken — und ein Team, das anderes erwartet, wird von einem ansonsten solid entworfenen Protokoll enttäuscht sein.
Wie Sie anfangen
Das Scheitern sieht hier so aus: ein sechsmonatiges Plattformprogramm, das alles verbindet und nichts ausliefert. Drehen Sie es um.
- Wählen Sie einen Arbeitsablauf mit echter Reibung — etwas, wofür Menschen heute Daten zwischen zwei Systemen kopieren.
- Bauen Sie den kleinsten Server, der ihn unterstützt. Zwei oder drei aufgabenorientierte Tools, nur lesend, wenn der Ablauf es erlaubt.
- Betreiben Sie ihn im Schattenmodus. Der Agent erzeugt Ergebnisse, die ein Mensch mit dem bisherigen Prozess vergleicht, ohne dass gehandelt wird.
- Geben Sie einem Tool Schreibzugriff, sobald die Schattenergebnisse durchgehend korrekt sind — mit einer Freigabe davor.
- Erst dann verallgemeinern. Ihr zweiter Server wird besser, weil der erste Ihnen gezeigt hat, was Ihre Agenten wirklich verlangen.
Jeder Schritt liefert etwas Nutzbares, und die Reihenfolge erzeugt funktionierende Integrationen statt einer Integrationsstrategie.
Die Unternehmen, die dauerhaften Wert aus Agenten ziehen, werden nicht die mit den grössten Modellen sein. Es werden die sein, deren Systeme sauber erreichbar, korrekt abgegrenzt und vollständig auditierbar sind — denn die Modellklasse wird sich nächstes Jahr wieder ändern, die Integrationsschicht nicht.
Agenten mit Systemen zu verbinden, die nie für sie gedacht waren, ist der grösste Teil der eigentlichen Arbeit. Erkunden Sie unsere Live-Deployments im Showcase oder sprechen Sie mit unserem Team darüber, wie eine agentenzugängliche Architektur für Ihren Stack aussieht.