Wir haben bereits an verschiedenen Stellen darüber geschrieben, dass neben der menschlichen Nutzung digitaler Angebote ein zweiter Nutzungskontext entsteht: Software-Agenten greifen im Auftrag von Menschen auf Inhalte, Produkte und Funktionen zu. Dabei geht es nicht nur um klassische Crawler. Agenten können eine Website über einen Browser bedienen, Informationen gezielt abrufen oder über strukturierte Schnittstellen direkt mit Unternehmenssystemen kommunizieren. Cloudflare unterscheidet inzwischen ausdrücklich zwischen Search-, Agent- und Training-Traffic. Damit bekommt eine Entwicklung technische Konturen, die wir bereits 2025 unter der Frage „Das Ende der Website oder eine neue Ära der Experience-Gestaltung?“ aus der UX- und CX-Perspektive diskutiert haben. (Quelle: Cloudflare 2026)

Neu ist 2026 vor allem, dass sich die Infrastruktur für diesen Zugriff konkretisiert. Die Website verschwindet deshalb nicht. Aber sie ist nicht länger zwangsläufig der einzige Zugang zu den Leistungen eines Unternehmens. Für Menschen bleiben Navigation, Suche, Produktseiten und Checkout wichtige Interfaces. Agenten können dagegen zusätzlich auf Produktfeeds, APIs, Content-Systeme oder spezialisierte Agentenschnittstellen zugreifen. Die zentrale Frage verschiebt sich damit: Unternehmen müssen nicht einfach ihre Website „für KI optimieren“. Sie müssen entscheiden, über welche Wege Maschinen ihre Inhalte und Leistungen finden, verstehen und nutzen können – und was sie dort tun dürfen.

Von MCP bis UCP: Es entsteht ein neuer Zugriffs-Stack

Auf den ersten Blick wirkt die Entwicklung unübersichtlich. MCP, ACP, UCP, AP2 und x402 werden häufig gemeinsam unter Begriffen wie Agentic Commerce oder Agentic Web diskutiert. Technisch liegen sie jedoch nicht auf derselben Ebene. Manche Protokolle regeln den Zugriff auf Systeme und Funktionen, andere beschreiben Commerce-Abläufe oder Zahlungsprozesse. Für Content-, Commerce- und CX-Verantwortliche ist diese Differenzierung wichtiger als die Frage, welcher einzelne Standard sich am Ende durchsetzen wird.

1. MCP verbindet Agenten mit Daten, Tools und Anwendungen. Das ursprünglich von Anthropic entwickelte Model Context Protocol schafft eine standardisierte Möglichkeit, externe Systeme und ihre Funktionen für KI-Anwendungen adressierbar zu machen. Im Dezember 2025 wurde MCP als eines der Gründungsprojekte in die neu geschaffene Agentic AI Foundation unter dem Dach der Linux Foundation eingebracht. Neben MCP gehören Blocks goose und OpenAIs AGENTS.md zu den initialen Projektbeiträgen. AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft und OpenAI gehören zu den Platinum-Mitgliedern der Foundation. (Quelle: Linux Foundation 2025)
   
   Für uns ist MCP deshalb vor allem ein System- und Tool-Layer. Ein Agent kann darüber erfahren, welche Funktionen ein angeschlossenes System anbietet und diese strukturiert aufrufen. Mit der Funktionsweise und den Grenzen dieses Ansatzes haben wir uns bereits ausführlicher im Beitrag „Model Context Protocol (MCP): Neuer Standard für Agentic Automation oder nur ein Repackaging bewährter Konzepte?“ beschäftigt. Für die aktuelle Diskussion ist vor allem interessant, was passiert, wenn solche Schnittstellen nicht nur interne Enterprise-Anwendungen verbinden, sondern Content-, Service- und Commerce-Funktionen für Agenten zugänglich machen.
2. ACP und UCP setzen stärker bei Commerce-Prozessen an. Stripe und OpenAI stellten das Agentic Commerce Protocol am 29. September 2025 als offenen Standard für programmatische Commerce-Flows zwischen Käufer, Agenten und Unternehmen vor. Die erste sichtbare Anwendung war Instant Checkout in ChatGPT. OpenAI hat diese Strategie inzwischen weiterentwickelt: Im März 2026 verlagerte das Unternehmen den Schwerpunkt von einem eigenständigen Instant-Checkout-Erlebnis auf Product Discovery und Händler-eigene Checkout-Prozesse. ACP bleibt dabei Teil der Infrastruktur für strukturierte Produktinformationen und Commerce-Funktionen. (Quelle: Stripe 2025) (Quelle: OpenAI 2026)
   
   Google hat diese Ebene im Januar 2026 mit dem Universal Commerce Protocol (UCP) erweitert. UCP soll eine gemeinsame Sprache zwischen Consumer-Interfaces und Commerce-Systemen schaffen und Prozesse von Product Discovery über Kauf bis zu nachgelagerten Order-Funktionen abbilden. Google hat den Standard gemeinsam mit Unternehmen wie Shopify, Etsy, Wayfair, Target und Walmart entwickelt. Entscheidend für die Einordnung: UCP soll bestehende Infrastrukturen nicht ersetzen, sondern unter anderem mit MCP, A2A und Googles AP2 zusammenspielen. Damit wird sichtbar, dass sich eher ein modularer Protokoll-Stack als ein einzelner Universalstandard herausbildet. (Quelle: Google 2026)
3. AP2 und x402 adressieren schließlich Zahlungs- und Autorisierungsfragen. Google stellte das Agent Payments Protocol im September 2025 als offenen Rahmen für agentisch initiierte Zahlungen vor. AP2 ergänzt unter anderem A2A und MCP und soll nachvollziehbar machen, welche Transaktion ein Mensch einem Agenten tatsächlich erlaubt hat. Damit adressiert das Protokoll ein grundsätzliches Problem des Agentic Commerce: Zwischen der allgemeinen Beauftragung eines Agenten und einer konkreten Zahlung braucht es überprüfbare Autorisierung. (Quelle: Google 2025)
   
   x402 setzt an einer anderen Stelle an. Das offene Protokoll greift den HTTP-Statuscode 402 „Payment Required“ auf und verbindet den Zugriff auf eine digitale Ressource unmittelbar mit einer Zahlungsanforderung. Cloudflare nutzt diese Logik inzwischen für seinen Monetization Gateway. Damit können perspektivisch nicht nur Webseiten, sondern auch Datensätze, APIs oder einzelne MCP-Tool-Calls bepreist werden. Ein MCP-Endpunkt kann also eine Fähigkeit adressierbar machen, während eine zusätzliche Governance- und Payment-Schicht festlegt, wer diese Fähigkeit unter welchen Bedingungen nutzen darf. (Quelle: Cloudflare 2026)

Wer entscheidet, welcher Agent überhaupt reinkommt?

Mit der technischen Erreichbarkeit entsteht unmittelbar eine Governance-Frage. Unternehmen wollen nicht zwangsläufig jedem automatisierten System denselben Zugriff geben. Ein Search-Crawler, der Inhalte indexiert und möglicherweise später Nutzer auf eine Website zurückführt, erfüllt eine andere Funktion als ein Training-Crawler. Ein Agent, der gerade im Auftrag einer konkreten Person Informationen sammelt oder eine Aktion ausführt, bringt wiederum einen anderen Nutzungskontext mit. Genau diese Differenzierung hat Cloudflare im Juli 2026 in seine Steuerung des AI-Traffics übernommen. (Quelle: Cloudflare 2026)

Die Entwicklung begann bereits ein Jahr zuvor. Am 1. Juli 2025 führte Cloudflare Pay Per Crawl als Private Beta ein. Website-Betreiber können KI-Crawler erlauben, blockieren oder für den Zugriff bezahlen lassen. Technisch nutzt Cloudflare dafür unter anderem HTTP 402 „Payment Required“. Die Logik geht damit über die bisher übliche robots.txt-Entscheidung zwischen Zulassen und Blockieren hinaus: Content-Zugriff kann selbst zu einer wirtschaftlich steuerbaren Ressource werden. (Quelle: Cloudflare 2025)

Im Juli 2026 hat Cloudflare diese Steuerung weiter ausdifferenziert. Search-, Agent- und Training-Traffic lassen sich getrennt behandeln. Für neu auf Cloudflare aufgeschaltete Domains sollen ab dem 15. September 2026 Training- und Agent-Zugriffe auf werbefinanzierten Seiten standardmäßig blockiert werden, während Search weiter erlaubt bleibt. Mehrzweck-Crawler werden entsprechend der ihnen zugeordneten Verhaltensweisen behandelt. Dahinter steht ein wichtiger Perspektivwechsel: Nicht mehr nur die technische Identität eines Bots ist relevant, sondern zunehmend der Zweck seines Zugriffs. (Quelle: Cloudflare 2026)

Mit dem ebenfalls im Juli 2026 angekündigten Monetization Gateway erweitert Cloudflare diese Logik vom Content-Zugriff auf beliebige digitale Ressourcen. Unternehmen sollen APIs, Daten und explizit auch MCP-Tool-Calls nutzungsabhängig bepreisen können. Damit zeichnet sich eine zusätzliche Steuerungsebene für das Agentic Web ab: Agenten-Zugriff wird zu einer Kombination aus Auffindbarkeit, Identität, Berechtigung und gegebenenfalls Bezahlung. Welche Modelle sich wirtschaftlich durchsetzen, ist offen. Die technische Trennung dieser Fragen ist dagegen bereits sichtbar. (Quelle: Cloudflare 2026)

Content-Systeme werden für Agenten direkt adressierbar

Die dritte Entwicklung betrifft den Content selbst. Strukturierte Inhalte waren schon für Headless- und Composable-Architekturen wichtig. Agenten geben dieser Entwicklung eine zusätzliche Bedeutung. Inhalte müssen nicht ausschließlich als HTML-Seite für einen Browser bereitstehen. Sie können über APIs, Feeds oder Agentenschnittstellen direkt aus Content-Systemen abgefragt und in anderen Nutzungskontexten verarbeitet werden. Damit konkretisiert sich eine Entwicklung, die wir im Beitrag zu den neuen Interaktionsmustern in der Digital Experience bereits aus Content- und Experience-Sicht diskutiert haben: Auffindbarkeit allein reicht nicht. Inhalte müssen so strukturiert und kontextualisiert sein, dass unterschiedliche Systeme sie korrekt interpretieren und weiterverwenden können.

Storyblok zeigt, wie sich diese Logik konkret in einem Headless CMS niederschlagen kann. Der Storyblok MCP Server gibt kompatiblen Agenten strukturierten Zugriff auf den Content Workspace. Sie können Inhalte suchen und lesen, abhängig von ihren Rechten aber auch Einträge erstellen, verändern, publizieren oder Assets verwalten. Read-only-, verändernde und destruktive Operationen sind in unterschiedliche Ausführungsmodi getrennt. Damit wird MCP hier nicht nur zur Leseschnittstelle, sondern potenziell auch zur Operations-Schicht für Content-Prozesse. (Quelle: Storyblok 2026)

Das bedeutet allerdings nicht automatisch, dass eine öffentliche Storyblok-Website dadurch besser in ChatGPT, Gemini oder anderen Consumer-Agenten gefunden wird. Ein MCP Server schafft zunächst einen kontrollierten und strukturierten Zugang zu einem Content-System. Genau diese Trennung ist wichtig: Discovery, Interpretation und direkter Systemzugriff sind unterschiedliche Aufgaben. Für Unternehmen folgt daraus, dass Agent Readiness nicht mit einem einzelnen technischen Feature erledigt ist. Sie betrifft die gesamte Delivery-Architektur von Content und digitalen Services.

Vom Human Interface zur zweiten Delivery-Logik

Aus CX-Sicht wird die Entwicklung besonders relevant, weil Agenten zunehmend zwischen Unternehmen und Kund treten können. Unter dem Begriff „Agents of Customer“ haben wir zuletzt diskutiert, was passiert, wenn nicht mehr ausschließlich Menschen selbst suchen, vergleichen und auswählen. Agentensysteme können diese Aufgaben vorbereiten oder teilweise übernehmen. Damit verändert sich nicht nur die technische Anfrage an eine Website, sondern potenziell auch der Kontext, in dem Marken, Angebote und Services bewertet werden.

Für Content- und CX-Verantwortliche entsteht daraus kein weiteres isoliertes Technologieprojekt. Die Entwicklung setzt vielmehr unsere bisherige Diskussion über Composable DXP und KI-fähige Experience-Architekturen fort. Modulare und API-orientierte Architekturen organisieren Content, Daten und Funktionen bereits stärker unabhängig vom jeweiligen Frontend. Das macht einen Stack noch nicht automatisch agent-ready. Es schafft aber bessere Voraussetzungen dafür, dieselben Ressourcen später auch für neue Interfaces und maschinelle Nutzungskontexte bereitzustellen.

Genau hier liegt aus unserer Sicht die eigentliche Veränderung. Für Menschen orchestrieren Unternehmen Experience bislang vor allem über Websites, Apps, Messaging-Interfaces und andere sichtbare Touchpoints. Agenten erzeugen eine zusätzliche Delivery-Logik. Sie benötigen strukturierte Produktinformationen, eindeutig beschriebene Inhalte und adressierbare Business-Funktionen. Gleichzeitig müssen Identität, Berechtigungen, Preise und Transaktionsregeln maschinell überprüfbar sein. Das Human Interface bleibt bestehen – aber es bekommt eine parallele Maschinenzugriffsschicht.

Damit wird auch unsere frühere Frage nach dem möglichen „Ende der Website“ konkreter. Nicht die Website als solche steht zur Disposition. Zur Diskussion steht ihre bisherige Rolle als zentrale Vermittlungsschicht zwischen Unternehmen und digital handelnden Kund. Wenn Agenten Informationen, Funktionen und Commerce-Prozesse direkt ansprechen können, verliert das sichtbare Interface einen Teil seiner technischen Exklusivität. Für Experience-Verantwortliche erweitert sich die Gestaltungsaufgabe deshalb vom Interface Design zur Architektur der gesamten Experience Delivery.

Ob daraus dauerhaft ein eigenständiger „zweiter Traffic-Typ“ entsteht und welche der derzeit diskutierten Protokolle sich durchsetzen, ist noch offen. Dieses Jahr lässt sich aber deutlich erkennen, dass sich die technischen Voraussetzungen dafür konkretisieren. MCP, UCP, ACP, AP2 und x402 adressieren unterschiedliche Teile dieser Infrastruktur. Cloudflare entwickelt neue Governance-Mechanismen für maschinellen Traffic, während Content- und Commerce-Plattformen beginnen, ihre Systeme direkt für Agenten zugänglich zu machen.

Für uns ist das deshalb weniger eine neue Spezialdisziplin als die nächste Stufe der Experience-Orchestration-Diskussion: Wie organisieren wir Content, Daten, Funktionen und Governance so, dass Unternehmen ihre Experience nicht nur über menschliche Interfaces, sondern auch gegenüber handelnden Agenten kontrolliert ausspielen können? Wie Unternehmen ihre Content-, Commerce- und Experience-Architektur auf diese Entwicklung vorbereiten, ist eines der Themen auf der Shift/CX Experience Orchestration Konferenz am 22. Oktober 2026.