Die Agent-Checkout-Protokolle konvergieren (ACP, AP2, Instant Checkout). Die Experience-Schicht bleibt die offene Frage.

Innerhalb weniger Monate haben zwei große Plattform-Lager offengelegt, wie ein Kauf durch einen KI-Agenten technisch ablaufen soll. OpenAI und Stripe haben das Agentic Commerce Protocol (ACP) vorgestellt, den Standard hinter „Buy it in ChatGPT" und Instant Checkout. Google hat parallel das Agent Payments Protocol (AP2) veröffentlicht, seit dem 28.04.2026 als Version 0.2 unter der Governance der FIDO Alliance. Beide adressieren dasselbe Problem: Wie autorisiert, bezahlt und bestätigt ein Agent einen Kauf, ohne dass ein Mensch das Formular ausfüllt?

Das ist ein echter Fortschritt, und für viele Händler wirkt es wie die eine große Frage, die das Agentic-Commerce-Zeitalter offen hatte. Ist sie aber nicht. Die Protokolle konvergieren auf den Teil, der sich standardisieren lässt: die Transaktion. Der Teil, der sich nicht standardisieren lässt, bleibt dabei unangetastet, und genau der entscheidet über Marke, Marge und Conversion. Was der Agent dem Shopper *zeigt und sagt*, gehört weiterhin dem Händler.

Was ACP, AP2 und Instant Checkout tatsächlich standardisieren

Es lohnt sich, präzise zu sein, was hier passiert. Die Protokolle regeln die Mechanik einer agentischen Kauftransaktion, nicht das Kauferlebnis.

• ACP (OpenAI + Stripe) definiert, wie ein Agent eine Bestellung anlegt, Zahlungsdaten übergibt und eine Bestätigung erhält. „Buy it in ChatGPT" ist die erste sichtbare Anwendung. Etsy ist live, und rund eine Million Shopify-Händler wurden als nächste Welle angekündigt. Die Spezifikation ist Open Source und befindet sich in der Beta-Phase.
• AP2 (Google, FIDO Alliance) definiert die Zahlungs- und Autorisierungsschicht für Agenten herstellerübergreifend. Der Fokus liegt auf verifizierbarer Absicht, Mandaten und der Frage, wer für einen Agenten-Kauf haftet.

Wichtig ist, was in dieser Aufzählung nicht vorkommt. Kein Protokoll standardisiert, welche drei Produkte der Agent aus eurem Sortiment vorschlägt. Keines legt fest, wie eine Größentabelle, ein Nachhaltigkeits-Hinweis oder eine Bundle-Empfehlung dargestellt wird. Keines entscheidet, ob der Agent bei einem ausverkauften Artikel eine Alternative anbietet oder abbricht. Und keines besitzt eure Produktdaten, eure Content-Struktur oder eure Marken-Tonalität.

ACP und AP2 sind Payment- und Fulfilment-Rails. Sie sind für den Händler das, was eine Zahlungsschnittstelle immer war: notwendige Infrastruktur, die den Kauf abschließt, aber nicht das ist, weshalb jemand bei euch und nicht beim Wettbewerb kauft.

Die Schicht, die niemand standardisiert

Zwischen der Anfrage eines Shoppers und der Transaktion liegt eine Schicht, die sich der Standardisierung entzieht, weil sie pro Händler unterschiedlich ist. Wir nennen sie die Experience-Schicht: alles, was der Agent im Namen eures Shops zeigt, formuliert, empfiehlt und begründet.

Diese Schicht beantwortet Fragen, die kein Protokoll beantworten kann:

• Auswahl. Welche Produkte holt der Agent aus einem Katalog mit 50.000 Artikeln, wenn jemand nach „leichter Laufjacke für Regen" fragt?
• Darstellung. Wie werden Preis, Verfügbarkeit, Varianten und Rückgabebedingungen strukturiert, damit ein Agent sie korrekt liest und korrekt wiedergibt?
• Begründung. Was sagt der Agent über euer Produkt? Zitiert er eure Formulierung, oder erfindet er eine eigene, die eurer Marke widerspricht?
• Abbruch-Logik. Was passiert bei ausverkauft, bei Cross-Border-Restriktionen, bei altersgeprüften Produkten?

Das sind keine Payment-Fragen. Das sind Frontend- und Content-Fragen. Und sie werden nicht kleiner, wenn der Checkout standardisiert ist. Sie werden größer, weil der Agent nun ein zusätzlicher Kanal ist, in dem eure Marke ohne eure direkte Kontrolle auftritt, sofern ihr diese Schicht nicht aktiv gestaltet.

Warum die Experience-Schicht beim Händler bleibt

Es gibt einen strukturellen Grund, warum das so bleibt. Ein Protokoll ist per Definition ein kleinster gemeinsamer Nenner. Es funktioniert nur, wenn alle Beteiligten dieselbe Mechanik teilen. Genau deshalb kann ein Protokoll die Transaktion regeln, aber niemals die Differenzierung, denn Differenzierung ist das Gegenteil eines gemeinsamen Nenners.

Für den Händler heißt das: Payment und Fulfilment könnt ihr an ACP oder AP2 delegieren. Die Antwort auf „warum dieses Produkt, warum bei uns, in welcher Formulierung" könnt ihr nicht delegieren, ohne die Kontrolle über eure Marke im agentischen Kanal aufzugeben. Diese Schicht ist kein Rendering-Detail. Sie ist der Teil des Storefronts, der eure Auswahl-Logik, eure Content-Regeln und eure Guardrails trägt.

Das deckt sich mit einem Muster, das wir schon bei früheren Plattform-Verschiebungen gesehen haben. Als Payment-Provider den Bezahlvorgang vereinheitlichten, verschwand der Unterschied zwischen Händlern nicht. Er wanderte nach vorn, in Sortiment, Präsentation und Content. Bei agentischen Käufen passiert dasselbe. Die Experience-Schicht verschwindet nicht. Sie verschiebt sich, von der Seite, die ein Mensch anschaut, zu der Struktur, die ein Agent liest.

Was das für die Storefront-Architektur heißt

Wenn der Agent zum Käufer wird, muss der Storefront Agent-ready sein. Das ist keine Marketing-Formel, sondern eine konkrete Anforderung an die Architektur:

1. Strukturierte Daten als Pflicht, nicht als SEO-Zusatz. Ein Agent liest Schema.org, nicht euer CSS. Produkt-, Preis-, Verfügbarkeits- und Varianten-Daten müssen maschinenlesbar und eindeutig sein, sonst rät der Agent, und Raten kostet euch Marge und Reputation. Wie ihr Content zitierfähig für Agenten strukturiert, haben wir in Content-Citation-Readiness beschrieben.
2. Ein Datenmodell über allen Backends. Wenn eure Produktdaten in Shopify, eure Preise in einem ERP und eure Verfügbarkeit in einem separaten System liegen, muss der Agent trotzdem eine einzige, konsistente Wahrheit sehen. Ein normalisierter Frontend-Datenlayer über den Backends löst genau das.
3. Guardrails auf Component-Ebene. Ein Agent, der eigenständig auswählt und formuliert, braucht Grenzen: welche Produkte er vorschlagen darf, welche Aussagen er treffen darf, wann er abbrechen muss. Diese Regeln gehören in den Frontend-Layer, nicht in einen Prompt. Den schema-getriebenen Ansatz dazu haben wir in Agentic Frontend Guardrails ausgeführt.
4. Dieselbe Component-Library für Mensch und Agent. Die Auswahl- und Darstellungs-Logik, die euren menschlichen Shopper bedient, ist dieselbe, die den Agenten füttert. Zwei getrennte Systeme zu pflegen, eines für die Website und eines für den Agenten, ist teuer und driftet auseinander.

Genau hier setzt eine Agentic Frontend Management Platform an. Sie trennt die Payment-Rails, die ihr an ACP oder AP2 anbindet, sauber von der Experience-Schicht, die ihr behaltet. Der Composable-Headless-Frontend-Layer sitzt über eurem bestehenden Commerce-Stack, normalisiert die Daten aus allen Backends und stellt die strukturierten, guardrail-gesicherten Inhalte bereit, die ein Agent korrekt lesen kann, ausgelegt auf maschinenlesbare Zitierfähigkeit über SEO and GEO. Ihr wechselt die Payment-Mechanik, ohne die Kontrolle über die Darstellung zu verlieren.

Fazit

Die Konvergenz von ACP, AP2 und Instant Checkout ist eine gute Nachricht: Die Transaktions-Mechanik agentischer Käufe wird zur Commodity, und Commodities muss niemand selbst bauen. Das ist aber auch die Grenze der Standardisierung. Die Auswahl, die Darstellung und die Begründung, also alles, was eure Marke im agentischen Kanal ausmacht, wird kein Protokoll für euch übernehmen.

Die praktische Konsequenz ist unaufgeregt. Bindet die Payment-Protokolle an, sobald sie für euren Markt reif sind. Investiert parallel in die Schicht, die niemand für euch standardisiert: strukturierte Daten, ein einheitliches Frontend-Datenmodell und Guardrails, die auf Component-Ebene definieren, was der Agent zeigen darf. Die Experience-Schicht verschwindet nicht. Sie bleibt in eurer Hand, wenn ihr sie dort behaltet.