Technologieführer beobachten bereits ein gängiges Muster bei der Einführung von MCP: Ein Agent, der in einer lokalen Entwicklungsumgebung beeindruckend erscheint, hat Schwierigkeiten, zuverlässig zu funktionieren, sobald er in der Produktion eingesetzt wird.

B2B-Organisationen stehen vor einer spezifischen Version dieser Herausforderung. Sie verbinden KI-Agenten nicht nur mit internen Datenbanken – sie benötigen Agenten, die zuverlässig über kundenorientierte Workflows hinweg funktionieren: auf Kundenanfragen reagieren, CRM-Datensätze aktualisieren, Abrechnungssysteme auslösen und Kontodaten über Organisationsgrenzen hinweg zugänglich machen.

Ein Agent, der in einer lokalen IDE beeindruckend funktioniert, aber in der Produktion keine Verbindung zu einer Salesforce-Instanz, einer Ticketing-Plattform oder einer Partner-API herstellen kann, ist kein B2B-fähiges System. Der Aufbau einer MCP-Infrastruktur für B2B-KI-Anwendungen erfordert mehr als ein stärkeres Modell. Es erfordert eine standardisierte Konnektivitätsschicht, die sicher über die Systeme hinweg funktionieren kann, die B2B-Teams tatsächlich nutzen.

Was ist MCP in der agentischen KI?

Eingeführt von Anthropic im November 2024, das Model Context Protocol (MCP) ist ein offener Standard und ein Open-Source-Framework, das entwickelt wurde, um die Integration von KI-Systemen mit externen Tools, Systemen und Datenquellen zu standardisieren.

Für B2B-KI-Anwendungen löst MCP eines der teuersten Integrationsprobleme in Unternehmenssoftware: die Notwendigkeit, jedes Mal benutzerdefinierte Konnektoren neu zu erstellen, wenn eine Organisation ein neues Modell einführt oder ein neues Unternehmenstool hinzufügt.

Anstatt von jeder KI-Anwendung zu verlangen, maßgeschneiderte Wrapper für Ihr CRM, ERP, Ihren Support-Desk oder Ihre Abrechnungsplattform zu implementieren, definiert MCP ein gemeinsames Protokoll, das jeder konforme Agent verwenden kann, um diese Systeme zu erreichen – sobald der Server erstellt ist.

Wie MCP KI-Agenten die Interaktion mit Tools ermöglicht

MCP strukturiert die Interaktionen zwischen KI-Systemen und externen Diensten durch eine dreiteilige Architektur:

1. Hosts: LLM-Anwendungen, wie ein IDE-Assistent (Cursor) oder ein benutzerdefinierter Unternehmens-Copilot, die das Modell ausführen und das Agentenverhalten orchestrieren. 
2. Clients: Komponenten, die in die Host-Anwendung eingebettet sind und das MCP-Protokoll implementieren. Sie verwalten die Verbindungsherstellung, die Erkennung von Funktionen und die Kommunikation mit MCP-kompatiblen Diensten.
3. Server: Externe Prozesse, die die Funktionalität spezifischer Systeme über das Protokoll bereitstellen. Diese Server fungieren als Adapter für Dienste wie GitHub-Repositories, PostgreSQL-Datenbanken oder Unternehmens-CRM-Plattformen und ermöglichen Agenten die Interaktion mit ihnen über standardisierte Schnittstellen.

Innerhalb dieser Architektur standardisiert MCP Interaktionen durch drei Primitive. 

Werkzeuge stellen ausführbare Operationen dar, die ein Agent aufrufen kann, wie z. B. das Ausführen einer Datenbankabfrage oder das Erstellen einer Aufgabe in einem Projektmanagementsystem.

Ressourcen bieten strukturierte Datenzugriffspunkte, einschließlich Dateiinhalten, Dokumentationen oder Datenbankschemata, die abgerufen werden können, wenn das Modell zusätzlichen Kontext benötigt.

Prompts sind wiederverwendbare Vorlagen, die Server bereitstellen können, um die Interaktion von Modellen mit bestimmten Systemen zu steuern und so ein konsistentes Verhalten über verschiedene Host-Anwendungen hinweg zu gewährleisten.

Im Gegensatz zu traditionellen zustandslosen APIs ermöglicht MCP den bidirektionalen Kontextfluss während einer Sitzung. Dies erlaubt Agenten, kontextbezogene Entscheidungen auf Basis des Gesprächsverlaufs zu treffen.

MCP vs. traditionelle API-Integrationen für KI-Systeme

Der architektonische Übergang von traditionellen API-Integrationen zum Model Context Protocol (MCP) stellt eine grundlegende Verschiebung von statischer, fest codierter Logik zu einem dynamischen, auf Argumentation basierenden Interaktionsmodell dar. Für Unternehmen ist das Verständnis dieses Unterschieds entscheidend, um über anfällige KI-Pilotprojekte hinaus zu skalierbaren Produktionsagenten zu gelangen.

Reduzierung der Integrationskomplexität

In B2B-Umgebungen potenziert sich diese Komplexität schnell. Ein KI-Vertriebsagent muss möglicherweise aus einem CRM lesen, in ein Ticketsystem schreiben, eine Vertragsdatenbank abfragen und Updates an ein ERP senden, oft über Systeme hinweg, die verschiedenen Teams oder Anbietern gehören. Ohne ein Standardprotokoll erfordert jede neue Datenquelle eine benutzerdefinierte Integration. Mit MCP wird jedes System einmal über einen MCP-Server bereitgestellt und kann von jedem konformen Agenten oder jeder Host-Anwendung aufgerufen werden.

Für B2B-KI-Anwendungen bedeutet dies, dass die Integrationskosten für das Hinzufügen eines neuen Workflows oder die Einführung eines neuen Unternehmens-Tools erheblich sinken und Unternehmen Modelle aktualisieren oder austauschen können, ohne jede Verbindung neu aufbauen zu müssen.

Kontextmanagement in KI-Workflows

Standard-APIs folgen im Allgemeinen einem zustandslosen Anfrage-Antwort-Muster, bei dem jeder Aufruf unabhängig ist und der vollständige Kontext bei jeder Anfrage erneut übertragen werden muss. Während dies für deterministische Softwaresysteme gut funktioniert, kann es für KI-Workflows, die längere Konversationen oder mehrstufige Prozesse umfassen, token-intensiv und ineffizient werden.

MCP unterstützt den kontinuierlichen Kontextaustausch zwischen dem Agenten und den verbundenen Diensten. Dies ermöglicht es Interaktionen, auf früheren Schritten einer Sitzung aufzubauen, wodurch es für Agenten einfacher wird, längere Workflows auszuführen und gleichzeitig das Bewusstsein für frühere Aktionen und Eingaben zu bewahren.

MCP als Integrationsschicht

MCP sollte nicht als Ersatz für bestehende API-Technologien wie REST oder GraphQL angesehen werden. Stattdessen fungiert es als zusätzliche Integrationsschicht, die speziell für KI-gesteuerte Interaktionen entwickelt wurde.

In vielen Implementierungen fungieren MCP-Server als Adapter, die Agentenanfragen in bestehende API-Aufrufe übersetzen. Ein Server, der sich beispielsweise mit GitHub verbindet, kann Aktionen wie das Erstellen von Issues oder das Auflisten von Repositories bereitstellen, während er intern die Standard-APIs der Plattform verwendet. 

Speziell für B2B-Anwendungen ist diese Architektur wichtig, da sie es KI-Agenten ermöglicht, sich mit den Tools zu verbinden, die Kunden bereits nutzen – Salesforce, HubSpot, Zendesk, NetSuite – ohne diese Integrationen jedes Mal neu aufbauen zu müssen, wenn das zugrunde liegende Modell aktualisiert oder ersetzt wird.

MCP für KI-Agenten und Sicherheitsarchitektur

Wenn Sprachmodelle nicht mehr nur Text generieren, sondern Aktionen in Unternehmenssystemen ausführen, ändert sich das Sicherheitsmodell erheblich. KI-Agenten können auf Tools zugreifen, mit Datenbanken interagieren und operative Arbeitsabläufe auslösen. Infolgedessen beschränken sich Fehler nicht mehr nur auf falsche Ausgaben. Ein kompromittierter Agent kann potenziell unbeabsichtigte Aktionen in Produktionssystemen ausführen.

Sicherheitsforscher haben bereits mehrere Risiken identifiziert, die mit aufkommenden MCP-basierten Umgebungen verbunden sind.

• Tool-Poisoning: Ein bösartiger MCP-Server könnte versteckte Anweisungen oder irreführende Metadaten einbetten, die beeinflussen, wie ein Agent ein Tool verwendet, was potenziell zu unbeabsichtigtem Datenzugriff oder Offenlegung führen kann.
• Kompromittierung der Lieferkette: Öffentliche Registries können Server hosten, die bei der Installation legitim erscheinen, aber später durch Updates oder Konfigurationsänderungen schädliches Verhalten einführen.
• Schwache Verifizierung auf Host-Ebene: Viele aktuelle MCP-Hosts rufen modellvorgeschlagene Tool-Aufrufe blind auf, ohne zu überprüfen, ob die Parameter oder Tools für die spezifische Benutzersitzung autorisiert sind.
• Redirection-Hijacking: Wenn Infrastrukturkomponenten auf externe Repositories verweisen, wie z.B. auf GitHub gehostete, könnten Angreifer versuchen, die Kontrolle über aufgegebene oder umgeleitete Ressourcen zu übernehmen und diese durch bösartigen Code zu ersetzen.

Wie MCP hilft, klare Agenten-Grenzen zu definieren

Trotz dieser Risiken führt MCP strukturelle Elemente ein, die die Sicherheit im Vergleich zu Ad-hoc-Integrationsansätzen verbessern können. 

Strukturierte Tool-Schemata ermöglichen es Hosts und KI-Gateways, klare operative Grenzen zu definieren. Organisationen können genau festlegen, welche Aktionen ein Tool zulässt und welche Parameter erlaubt sind, was einen Ansatz des geringsten Privilegs für den Agentenzugriff unterstützt.

MCP-Implementierungen unterstützen auch moderne Authentifizierungsmechanismen, einschließlich OAuth-basierter Autorisierung, was dazu beitragen kann, die Anmeldeinformationsverwaltung zu zentralisieren und inkonsistente Zugriffsmuster über Dienste hinweg zu reduzieren.

Darüber hinaus erzeugen MCP-Interaktionen strukturierte Aufzeichnungen der Tool-Nutzung. Diese Protokolle erfassen, welche Tools aufgerufen wurden, welche Parameter verwendet wurden und welche Ergebnisse diese Aktionen hatten. Eine solche Transparenz unterstützt Überwachung, Audits und die Untersuchung von Vorfällen in Unternehmensumgebungen.

Governance und Richtliniendurchsetzung für KI-Agenten

Eine kritische strukturelle Einschränkung der aktuellen MCP-Spezifikation ist, dass Berechtigungen größtenteils auf Sitzungsebene liegen. Sobald ein Tool autorisiert ist, kann jede Agentenaktivität in dieser Sitzung oft darauf zugreifen. Unternehmen müssen KI-Gateways vor MCP-Servern bereitstellen, um Zugriffsentscheidungen zu zentralisieren und detaillierte Richtlinien anzuwenden.

Organisationen führen typischerweise ein KI-Gateway oder eine Kontrollschicht zwischen Agenten und MCP-Servern ein. Diese Schicht zentralisiert die Autorisierung und überwacht, wie Agenten Tools verwenden.

Sicherheitsarchitekturen integrieren Identitäts- und Zugriffsmanagement (IAM) direkt in agentenbasierte Workflows. Bei risikoreichen Vorgängen, wie Finanztransaktionen oder Änderungen am Produktionscode, können Governance-Modelle zusätzliche Genehmigungsschritte erfordern, einschließlich Genehmigungen durch Menschen (Human-in-the-Loop, HITL). Durch die Kombination von MCP mit etablierten Governance-Mechanismen können Unternehmen die operative Kontrolle behalten und gleichzeitig Agenten befähigen, nützliche Aufgaben zu erledigen.

Infrastruktur für KI-Agenten mit MCP gestalten

Sobald ein Agent auf Tools zugreifen, Betriebsdaten abrufen und Aktionen über Geschäftssysteme hinweg auslösen kann, verlagert sich das Designproblem von der Prompt-Qualität zur Infrastrukturkontrolle. 

Für Unternehmen ist es wichtig zu verstehen, wie sie den Tool-Zugriff, die Identität, den Zustand, Genehmigungsprozesse und die Prüfbarkeit in agentengesteuerten Workflows steuern werden.

MCP ist hier relevant, da es standardisiert, wie KI-Anwendungen sich mit Ressourcen und Prompts verbinden, ersetzt aber nicht die Orchestrierung, die Richtliniendurchsetzung oder die Laufzeit-Governance. 

Beginnen Sie mit dem richtigen Designprinzip

MCP sollte als Schnittstellenschicht zwischen KI-Agenten und Unternehmenssystemen behandelt werden. Es ist nicht die vollständige Agentenplattform. In der MCP-Architektur gilt: 

• Hosts führen KI-Anwendungen aus 
• Clients verwalten die Protokollkommunikation 
• Server stellen Tools, Ressourcen und Prompts bereit. 

Das macht MCP nützlich, um zu standardisieren, wie Agenten auf Aufzeichnungssysteme zugreifen, aber es entscheidet nicht, welches Modell eine Aufgabe bearbeiten soll, wie mehrstufige Workflows orchestriert werden oder welche Aktionen eine menschliche Genehmigung erfordern. Diese Entscheidungen gehören an eine andere Stelle im Stack. 

Für Teams ist diese Unterscheidung wichtig, denn wenn MCP als Komplettlösung missverstanden wird, könnten Unternehmen zu wenig in die Kontrollschichten investieren, die bestimmen, ob Agenten sicher im Produktionsbetrieb eingesetzt werden können. 

Ein praktikables Design trennt Orchestrierung, Sicherheitsrichtlinien und operative Governance von dem Protokoll, das für die Verbindung zu Tools verwendet wird. 

Die Architektur sollte auf fünf Entscheidungsebenen aufbauen

Ein praktisches Produktionsdesign für KI-Agenten benötigt in der Regel fünf Schichten.

1. Modellzugriffsschicht.

Diese Schicht bestimmt, welches Modell für welche Aufgabe verwendet wird. Der Hauptzweck dieser Schicht ist die Risikokontrolle. Verschiedene Aufgaben können unterschiedliche Kompromisse hinsichtlich Kosten, Latenz, Argumentationsqualität und Datensensibilität erfordern. Daher sollte das Routing richtliniengesteuert sein und nicht fest auf einen einzigen Modell-Anbieter programmiert werden. Diese Schicht ist von MCP getrennt. MCP standardisiert die Tool-Konnektivität, nicht die Modellauswahl. 

2. Orchestrierungsschicht.

Diese Schicht verwaltet, wie Agenten Workflows ausführen, einschließlich der Planung von Schritten, der Behandlung von Wiederholungsversuchen, der Speicherung von Informationen und der Koordination mehrstufiger Aufgaben. Frameworks wie LangGraph werden hier häufig verwendet, da sie dauerhafte Ausführung, Zustandsbeibehaltung, langlaufende Prozesse und menschliche Eingriffspunkte unterstützen. Dies sind Orchestrierungsbelange, keine Protokollbelange.

3. MCP-Schnittstellenschicht.

Hier interagieren Agenten über ein Standardprotokoll mit Unternehmenswerkzeugen. MCP-Server stellen Funktionen bereit; MCP-Clients in Host-Anwendungen entdecken und rufen diese auf. Diese Schicht ist wertvoll, da sie Geschäftsworkflows von einmaligen Integrationen entkoppelt. 

Ein System, wie eine Ticketing-Plattform oder ein interner Wissensdienst, kann einmal über einen MCP-Server bereitgestellt und dann über mehrere Hosts oder Agenten-Anwendungen hinweg wiederverwendet werden. 

4. Ausführungskontrollschicht.

Die Organisation setzt Laufzeitgrenzen durch. Sie sollte vom Modell vorgeschlagene Tool-Aufrufe validieren, Parameter einschränken, Anmeldeinformationen verwalten, Genehmigungsregeln anwenden und riskante Aktionen bei Bedarf isolieren. 

MCP unterstützt strukturierte Interaktionen und Autorisierungsmuster auf Transportebene, einschließlich OAuth 2.1 für geschützte Server, aber Unternehmen benötigen weiterhin Kontrollen auf Implementierungsebene darüber, was ein Agent in einer bestimmten Sitzung und unter welcher Identität tun darf. 

5. Audit- und Governance-Schicht.

Diese Schicht bietet Nachvollziehbarkeit über den gesamten Agenten-Lebenszyklus hinweg: 

• Welches Tool aufgerufen wurde
• Von welchem Agenten oder Benutzerkontext
• Mit welchen Parametern
• Mit welchem Ergebnis 

Sie definiert auch, welche Systeme über MCP bereitgestellt werden dürfen, welche Server zur Nutzung freigegeben sind, welche Aktionen einer menschlichen Überprüfung bedürfen und wie Vorfälle untersucht werden. Dies ist keine optionale Berichtsebene, die am Ende hinzugefügt wird. Sie ist Teil der Produktionssteuerungsebene.

Was zentralisiert werden sollte

Führungskräfte, die Agenten-Infrastrukturen entwerfen, sollten frühzeitig fünf Dinge zentralisieren.

Erstens, Server-Genehmigung und Lebenszykluskontrolle sollte zentralisiert werden. MCP-Server sollten sich nicht als unkontrollierte Adapter einzelner Teams verbreiten. Ein privates Register oder ein genehmigter interner Katalog ist ein besseres Modell für die Produktion, insbesondere für sensible Systeme. Die Sicherheitsempfehlungen von MCP selbst betonen ein sorgfältiges Autorisierungsdesign und implementierungsspezifische Kontrollen, anstatt blindes Vertrauen in verbundene Server zu setzen.

Zweitens, Identität und Autorisierung sollte zentralisiert werden. Geschützte MCP-Server können OAuth 2.1-Musterverwenden, aber das hilft nur, wenn der Zugriff an unternehmensweite Identitätsregeln gebunden und entsprechend begrenzt ist. Die Organisation sollte wissen, ob ein Agent im Namen eines Benutzers, eines Dienstkontos oder eines überwachten Workflows handelt und welche Berechtigungen in jedem Fall gelten.

Drittens, die Validierung von Tool-Aufrufen sollte zentralisiert werden. Der Host oder eine zwischengeschaltete Steuerungsebene sollte überprüfen, ob ein vorgeschlagenes Tool, ein Parametersatz und ein Ausführungskontext zulässig sind, bevor die Anfrage das Zielsystem erreicht. Dies adressiert Risiken, die bereits in den OWASP Richtlinien für LLM- und Agenten-Systeme hervorgehoben wurden, einschließlich Prompt Injection, unsicherer Ausgabebehandlung, Tool-Missbrauch und Identitätsmissbrauch.

Viertens, Protokollierung und Evaluierung sollte zentralisiert werden. Produktionsteams benötigen einen einheitlichen Audit-Trail über Modelle, Workflows, Tools und Genehmigungen hinweg. Ohne dies werden Debugging und Compliance-Überprüfungen über die Anwendungsteams hinweg fragmentiert. Das strukturierte Interaktionsmodell von MCP hilft, aber das Unternehmen muss diese Aufzeichnungen dennoch systematisch sammeln, aufbewahren und überprüfen. 

Fünftens, die Richtlinie für die menschliche Genehmigung sollte zentralisiert werden. Sensible Aktionen wie Zahlungsausführungen, Produktionsänderungen, rechtliche Mitteilungen oder Datenlöschungen sollten nicht der lokalen Anwendungslogik überlassen werden. Sie sollten durch unternehmensweite Regeln gesteuert werden, die festlegen, wann die Ausführung pausiert, wer sie genehmigt und wie diese Entscheidung protokolliert wird. Moderne Orchestrierungstools unterstützen diese Unterbrechungsmuster für die Überprüfung durch Menschen bereits. 

Was entkoppelt bleiben sollte

Mehrere Teile der Architektur sollten bewusst getrennt bleiben.

Die Modellwahl sollte von der Tool-Konnektivität entkoppelt bleiben.
Eine Organisation sollte Modelle ändern oder hinzufügen können, ohne jede Verbindung zu operativen Systemen neu aufbauen zu müssen. MCP unterstützt diese Trennung, da das Protokoll zwischen Hosts und Servern sitzt, anstatt Tools an einen einzigen Modellhersteller zu binden. 

Die Workflow-Logik sollte von systemspezifischen APIs entkoppelt bleiben.
Orchestrierungs-Frameworks sollten Planung und Zustand verwalten, während MCP-Server die zugrunde liegenden Systeme auf standardisierte Weise zugänglich machen. Diese Trennung senkt die Kosten für die Änderung der Workflow-Logik oder der zugrunde liegenden Dienstimplementierung. 

Governance sollte von den Anwendungsteams entkoppelt bleiben.
Geschäftsbereiche können den Anwendungsfall definieren, aber Genehmigungsregeln, Serverzertifizierung, Identitätskontrollen und Prüfanforderungen sollten zentral festgelegt werden. Das reduziert das Risiko fragmentierter Agenten-Bereitstellungen mit inkonsistenten Kontrollen. 

Eine praktische Rollout-Reihenfolge

Ein nützlicher Rollout-Pfad ist es, die Autonomie schrittweise einzuführen, anstatt sie auf einmal bereitzustellen.

Phase 1: Leseintensive Workflows mit vollständiger Protokollierung.

Beginnen Sie mit Workflows, bei denen der Agent Informationen abruft, den Kontext zusammenfasst oder Empfehlungen vorbereitet, aber keine schreibenden Aktionen mit hoher Auswirkung ausführt. Dies ermöglicht es den Teams, Orchestrierung, Identität und Telemetrie zu validieren, bevor das Betriebsrisiko steigt. 

Die OWASP-Richtlinien behandeln Prompt Injection und den Missbrauch von Ausgaben konsequent als frühe Kontrollprioritäten, was ein Grund dafür ist, dass „nur lesend“ nicht „risikofrei“ bedeutet. 

Phase 2: Eingeschränkte Schreibaktionen mit Genehmigungsschranken.

Sobald Protokollierung, Validierung und Genehmigungsabläufe stabil sind, kann die Organisation Agenten erlauben, begrenzte operative Aufgaben auszuführen, wie das Öffnen von Tickets, das Aktualisieren routinemäßiger Datensätze oder das Auslösen klar definierter Workflows. Diese sollten über explizite Positivlisten und menschliche Überprüfung laufen, wo der geschäftliche Nutzen dies rechtfertigt. MCP- und Orchestrierungs-Frameworks unterstützen beide strukturierte Unterbrechungs- und Autorisierungsmuster, aber das Unternehmen muss entscheiden, wo diese Kontrollen angesiedelt sind. 

Phase 3: Mehrstufige autonome Workflows.
Erst nachdem die ersten beiden Phasen stabil sind, sollten Organisationen auf länger laufende, systemübergreifende Workflows erweitern. Hier ist die Orchestrierungsreife am wichtigsten. Workflows müssen in der Lage sein, zu pausieren, nach Fehlern fortzufahren und den Zustand über Schritte hinweg zu teilen. 

Checkliste für Führungskräfte zur Gestaltung einer MCP-basierten Agenten-Infrastruktur

Bevor KI-Agenten in der Produktion skaliert werden, sollten Führungsteams sechs Fragen klar beantworten können:

1. Welche Workflows sind für die Agentenausführung genehmigt und welche bleiben nur beratend?
2. Welche Unternehmenssysteme dürfen über MCP zugänglich gemacht werden und wer zertifiziert diese Server?
3. Unter welcher Identität läuft jeder Agent und wie wird die Autorisierung festgelegt und überprüft?
4. Welche Aktionen erfordern eine menschliche Genehmigung vor der Ausführung?
5. Wo werden Tool-Aufrufe über den gesamten Stack hinweg validiert, protokolliert und überwacht?
6. Kann die Organisation Modelle, Workflows oder Systemkonnektoren unabhängig voneinander ändern, ohne die gesamte Architektur neu aufzubauen?

Wenn diese Fragen noch keine klaren Zuständigkeiten und Richtlinien haben, ist die Infrastruktur nicht bereit für eine umfassende Agentenautonomie.

Fazit

KI-Agenten markieren einen Wandel von Systemen, die Antworten generieren, hin zu Systemen, die Aktionen innerhalb der Unternehmensinfrastruktur ausführen. MCP entwickelt sich zur gemeinsamen Schnittstelle, die es Modellen ermöglicht, sich mit Tools und Diensten zu verbinden, wodurch die Integrationshürden reduziert werden, die viele KI-Initiativen verlangsamt haben.

Doch Konnektivität allein genügt nicht. MCP standardisiert, wie Agenten Systeme erreichen, nicht aber, wie diese Interaktionen geregelt werden. Autorisierung, Orchestrierung, Validierung und Audit müssen weiterhin als Teil der umfassenderen Agenten-Infrastruktur konzipiert werden.

Organisationen, die diesen Unterschied frühzeitig erkennen, werden Agenten entwickeln, die zuverlässig im Produktivbetrieb arbeiten. Diejenigen, die MCP als vollständige Plattform betrachten, werden schließlich feststellen, dass die eigentliche Herausforderung nicht darin besteht, Modelle mit Systemen zu verbinden, sondern darin, zu kontrollieren, wie sie innerhalb dieser agieren.