Wenn sich der Marketplace für Agenten öffnet: Amazons KI-Plugin für Seller Central und die Operations-Schicht auf der Verkäuferseite

Die wichtigsten Erkenntnisse

• Amazon hat am 23. September 2026 die Sell-Side-API-Oberfläche von Seller Central für externe KI-Agenten geöffnet — ein US-Beta-Selling-Partner-Plugin für Amazon Quick und Anthropics Claude, das Bestände, Preise, Listings und Verkaufsanalysen abdeckt.
• 90 % der Amazon-Verkaufspartner nutzen bereits KI-Tools von Drittanbietern, und Verkäufer übernehmen die Empfehlungen von Seller Assistant in mehr als 90 % der Fälle — Amazon folgt seinen Verkäufern in einen agentenvermittelten Workflow, der längst existiert.
• Amazon hat sich für den Plugin-Weg und nicht für ein offenes Protokoll entschieden — UCP, ACP, AP2 und x402 bleiben Buy-Side-Standards, Amazon entscheidet, welche Assistenten sich verbinden, und es blockierte Metas Muse-Shopping-Agent wenige Tage vor der Ankündigung aus seinem Store.
• Das Berechtigungsmodell ist die Bewertungsfläche: eingeschränkte Datentypen, menschliche Freigabe pro Aktion und vollständige Audit-Trails — Verkäufer legen fest, auf welche Daten das Plugin zugreift, und geben jede Aktion frei, bevor sie ausgeführt wird.
• Das Plugin verbindet Amazons Daten mit dem Assistenten — nicht den eigenen Stack des Händlers — ein B2B-Händler, der NetSuite, BigCommerce oder ShipStation einsetzt, braucht weiterhin eine eigene Agenten-Modulebene für Staffelpreise, kanalübergreifende Bestände und die Bestell-Rückschreibung.

Jeder Agentic-Commerce-Standard, den wir dieses Jahr verfolgt haben — UCP, ACP, AP2, x402, Checkout MCP —, beschreibt die Buy-Side: wie ein Agent ein Produkt findet, einen Preis verhandelt, den Checkout abschließt und bezahlt. (Diesen Stack haben wir in Commerce Protocols for AI Agents abgebildet.) Am 23. September 2026 hat Amazon auf seiner Verkäuferkonferenz Accelerate die andere Seite der Transaktion geöffnet. Ein neues Selling-Partner-Plugin stellt die Sell-Side-Operations des größten Marketplace — Bestände, Preise, Listings und Verkaufsanalysen — innerhalb von Amazon Quick und Anthropics Claude bereit, in einer US-Beta. Die Sogwirkung ist messbar: 90 % der Amazon-Verkaufspartner nutzen bereits KI-Tools von Drittanbietern, um Teile ihres Geschäfts zu betreiben, und die Gebühren, die diese Verkäufer an Amazon zahlten, brachten im zweiten Quartal 2026 46,8 Milliarden US-Dollar ein — mehr als der AWS-Umsatz, wie GeekWire in seiner Berichterstattung anmerkt.

Dieser Artikel zeigt, was das Plugin tatsächlich öffnet, warum Amazon den Agenten-Plugin-Weg statt eines offenen Protokolls gewählt hat, was das Berechtigungsmodell einschränkt und was es nicht löst — denn die Operation eines B2B-Händlers endet nicht an der Marketplace-Grenze. Der Preis, den ein Agent auf Amazon anpasst, muss mit den Staffelpreisen in NetSuite abgestimmt werden. Der Bestand, den er gerade geändert hat, muss zu BigCommerce und zum Lager passen. Die Bestellungen, die der Marketplace erzeugt, müssen weiterhin in ein ERP gelangen. Das Plugin ist die Antwort des Marketplace auf Agenten-Operationen. Die Verkäuferseite dieser Integration bleibt zu bauen.

Was Amazon tatsächlich ausgeliefert hat

Am 23. September sind drei Dinge gestartet, und es lohnt sich, sie zu trennen, weil sie unterschiedliche Bewertungsprofile haben.

Seller Assistant, weiterentwickelt. Der KI-Begleiter in Seller Central verfügt jetzt über ein dauerhaftes Gedächtnis für die Preismuster, Bestandszyklen und Wachstumsziele jedes einzelnen Verkäufers und läuft auf Amazon Bedrock mit Claude-Modellen. Amazon berichtet, dass Seller Assistant bei über 90 % der Verkaufspartner ausgerollt ist, mit Hunderttausenden aktiven Nutzern, und dass Verkäufer seine Empfehlungen in mehr als 90 % der Fälle übernehmen. Diese letzte Zahl wiegt schwerer als das Gedächtnis-Feature: Eine Empfehlungs-Engine mit mehrheitlicher Annahme in Seller Central ist die Verhaltensbasis, die das Plugin erweitert.

Seller-Assistant-Workflows. Dauerhaft laufende Automatisierungen, die Bedingungen überwachen und mit Berechtigung handeln — „Benachrichtige mich, wenn eines meiner Top-10-Produkte unter 4 Sterne fällt, und entwirf einen Reaktionsplan“ oder „Überwache meine stärkste Kategorie auf wettbewerbsbedingte Lücken; wenn du eine siehst, passe meine Preise an und aktualisiere die Listings.“ Verkäufer setzen Leitplanken in einfacher Sprache und entscheiden, ob der Workflow nur Empfehlungen aufzeigt oder Aktionen ausführt. Jede Aktion wird mit einem vollständigen Audit-Trail protokolliert.

Das Selling-Partner-Plugin. Die neue Oberfläche. Das Plugin verbindet die Listing-Beiträge eines Verkäufers, Echtzeit-Performance-Kennzahlen, Bestände und Verkaufsanalysen mit einem externen Agenten — zum Start Amazon Quick, in der Beta Claude — und der externe Agent kann auf das Konto einwirken, wie es Seller Assistant innerhalb von Seller Central tut. Amazon sagt, die Verbindung von Claude dauere rund 60 Sekunden ganz ohne Programmierung — neben den bestehenden Finanz- und Lieferanten-Datenverbindungen eines Verkäufers.

Die Einordnung von Amazons eigener Vizepräsidentin ist die strategische Schlagzeile: „Unsere Vision war, dass sie sich nie wieder bei Seller Central anmelden müssten“, sagte Mary Beth Westmoreland, Vice President of Worldwide Selling Partner Experience, im Interview mit GeekWire. „Wir bringen es ihnen einfach dorthin, wo sie arbeiten.“

Warum der Plugin-Weg und nicht der Protokoll-Weg

Die Buy-Side-Protokolle sind von der Konstruktion her offen: UCP hat eine öffentliche Spezifikation und Co-Entwickler, ACP liegt auf GitHub, jeder Händler kann einen Endpunkt bereitstellen. Die Öffnung auf der Verkäuferseite ist das genaue Gegenteil. Amazon veröffentlicht ein Plugin für Assistenten, die es selbst auswählt — zuerst das eigene Quick, dann Anthropics Claude, ein Unternehmen, in das Amazon Milliarden investiert hat und dessen Modelle Seller Assistant bereits antreiben — und kündigt weitere Integrationen an, gebaut in einer Weise, die „modular genug ist, damit wir weiterhin Plugins veröffentlichen können“. Nichts in der Ankündigung beschreibt eine Spezifikation, die andere Plattformen implementieren könnten.

Der Kontext schärft den Kontrast. Tage vor Accelerate blockierte Amazon Metas Muse, einen Consumer-Shopping-Agenten, aus seinem Store — mit der ausdrücklichen Position, dass externe Agenten sich zu erkennen geben und die Regeln der Seiten befolgen müssen, die sie nutzen (GeekWire). Auf der Verkäuferseite ist Amazon gleichzeitig Gastgeber, Regelgeber und Plugin-Herausgeber. Die Agenten-Oberfläche auf der Verkäuferseite existiert genau dort, wo Amazon sagt, dass sie existiert.

Für Verkäufer ist das kein Grund, fernzubleiben. Es ist ein Grund, die Konditionen mit derselben Strenge zu prüfen wie die Fähigkeiten — denn die Oberfläche kann von der Gegenpartei, die den Marketplace besitzt, erweitert, neu bepreist oder verengt werden. Verkäufergebühren sind bereits Gegenstand des Kartellrechtsverfahrens der FTC gegen Amazon, dessen Verhandlung für März 2027 angesetzt ist (GeekWire); die Ökonomie der Verkäufer-Tools ist keine neutrale Kulisse.

Die folgende Abbildung stellt das Plugin dem Buy-Side-Protokollstack und den Berechtigungs-Gates gegenüber, die es anwendet.

Was das Berechtigungsmodell einschränkt

Amazons eigene Sicherheitsbeschreibung ist präzise genug, um sie zu bewerten: Plugin-Interaktionen sind geschützt durch „klare Grenzen beim Zugriff, menschliche Freigabe der Aktionen und vollständige Audit-Trails“. In der Praxis sind das vier Gates.

Datenbereich. Verkäufer wählen, welche Datentypen das Plugin erreichen kann — Listings, Bestände, Verkaufsanalysen, Performance-Kennzahlen. Der Geltungsbereich gilt pro Datentyp und wird vom Verkäufer festgelegt.

Sichtbarkeit der Absicht. In Quick zeigen Agenten, die um das Plugin herum gebaut sind — ein Preis-Agent, ein Listing-Agent, ein Nachschub-Agent — an, was sie zu tun beabsichtigen, bevor sie es tun.

Menschliche Freigabe. Aktionen erfordern die Freigabe des Verkäufers, bevor sie ausgeführt werden — dasselbe Muster, das Seller-Assistant-Workflows bereits verwenden: nur Empfehlung oder Handeln mit Freigabe.

Audit-Trail. Jede Aktion wird protokolliert. Amazon erklärt außerdem, es sehe nicht die übrigen Geschäftsdaten im Assistenten eines Verkäufers — die Finanz- und Lieferanten-Verbindungen, die ein Verkäufer in Claude pflegt. Das ist Amazons Aussage über seine eigene Durchsetzung, keine unabhängig überprüfbare Eigenschaft; behandeln Sie sie entsprechend.

Dies ist dasselbe Kontrollmuster, das ein individuelles MCP-Modul durchsetzt: eingeschränkte Tools, typisierte Parameter, menschliche Gates bei Schreibvorgängen, Protokolle, die eine Prüfung überstehen. Der Unterschied geht zulasten der Sichtbarkeit des Verkäufers. Mit Ihrem eigenen Modul sind die Geltungsbereiche Code, den Ihr Team lesen kann. Bei einem First-Party-Plugin definiert der Marketplace die Geltungsbereiche, und der Verkäufer vertraut auf die Durchsetzung durch den Anbieter. Beides ist nicht falsch — aber es sind unterschiedliche Vertrauensentscheidungen, und die zweite verdient dieselbe Prüfung, die ein Sicherheitsteam jeder Integration eines Drittanbieters zuteilen würde.

Die Lücke: Das Plugin verbindet Amazons Daten, nicht den Stack des Händlers

Die 60-Sekunden-Verbindung bindet Amazon an den Assistenten. Für die Systeme, in denen die tatsächliche Operation eines B2B-Händlers läuft, bewirkt sie nichts.

Preisgestaltung. Das Plugin kann Amazon-Preise innerhalb der Leitplanken des Verkäufers anpassen. Es kann die kundenspezifische Staffelpreisliste in NetSuite, die Vertragskonditionen in einem CPQ oder die Margenuntergrenze nicht prüfen, bevor es das tut. Für einen Verkäufer, dessen Amazon-Kanal mit der direkten B2B-Preisgestaltung abgestimmt sein muss, liegt die Preislogik, die die Änderung steuert, außerhalb der Reichweite des Plugins.

Bestände. Es sieht die Amazon-Bestände. Kanalübergreifender Bestand — dieselbe SKU in BigCommerce, in einem Brightpearl-Lager, zugewiesen an eine ShipStation-Sendung — ist ein separates Synchronisierungsproblem, das das Plugin nicht berührt.

Bestellungen und Rückschreibung. Marketplace-Bestellungen brauchen weiterhin Validierung, Steuer- und Versandlogik sowie die Erfassung im ERP. Das ist die Auftragsverwaltungsebene — die Ebene, auf der ein Distributor mit 380 Mitarbeitern, der 1.800 Bestellungen pro Woche verarbeitet, seine Erfassungsfehlerrate mit typisierter Schema-Validierung über NetSuite, BigCommerce und ShipStation von 12 % auf unter 2 % gesenkt hat.

Das Muster des Assistenten der Wahl wirkt in beide Richtungen. Amazons Argument ist, dass Verkäufer Claude bereits „neben ihren bestehenden Finanz- und Lieferanten-Datenverbindungen“ einsetzen. Sobald Amazons Daten im selben Assistenten landen, wird der Verkäufer ihn bitten, Amazon-Preise mit ERP-Kosten und Marketplace-Bestände mit Lagerbestand abzugleichen. Genau dieses systemübergreifende Schlussfolgern ist die Integration, die das Plugin nicht bereitstellt — und die eigene Agentenschicht des Verkäufers ist es, die sie sicher macht: kontrollierte Module für jedes System, explizite Handles dafür, was der Agent lesen und schreiben darf, und ein Audit-Trail, der in den Systemen landet, die das Unternehmen ohnehin auditieren.

Was vor der Aktivierung der Beta zu prüfen ist

Vier Fragen, der Reihe nach:

1. Was darf das Plugin schreiben, nicht nur lesen? Preisänderungen, Listing-Bearbeitungen und Bestandsanpassungen sind unterschiedliche Risikoklassen. Amazons Workflows unterscheiden „nur Empfehlung“ von „Handeln mit Freigabe“ — ordnen Sie jeden Workflow der passenden Klasse zu, bevor Sie ihn einschalten.
2. Wo sitzt die Freigabe? Pro Aktion, pro Workflow oder pro Sitzung. Eine Freigabe pro Aktion bei einem Preis-Agenten ist ein anderes Betriebsmodell als eine sitzungsweite Ermächtigung.
3. Was erfasst der Audit-Trail, und wohin kann er gelangen? Wenn Ihr Auditor NetSuite oder ein Compliance-Data-Warehouse liest, muss der Trail das System erreichen, das Ihr Auditor ohnehin liest.
4. Was braucht die Verkäuferseite? Welche Ihrer Systeme müssen sehen, was der Agent getan hat — das ERP, der Storefront, das Lager — und wie bewegen sich diese Daten? Das ist die Integration, die Ihnen gehört.

Die Operations-Schicht auf der Verkäuferseite ist jetzt eine Agenten-Oberfläche. Amazon hat seinen Zug mit einem Plugin und einem Berechtigungsmodell gemacht; der Teil, den ein B2B-Händler im Mittelstand tatsächlich besitzt, ist alles, was das Plugin nicht verbindet.

Weiterführende Lektüre

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — der Buy-Side-Protokollstack, den dieses Plugin ergänzt: Discovery, Checkout, Zahlungsmandate und die Lücke auf der B2B-Semantikebene
• More RFQs, Fewer Real Opportunities: A Sell-Side Qualification Layer for Agent-Generated Demand — das Gegenstück auf der Nachfrageseite: wenn Agenten die eingehenden Anfragen erzeugen, wie das Angebots-Team eines Lieferanten sie qualifiziert
• Order Management: How an Agent Validates 1,800 B2B Orders a Week and Cuts the Error Rate from 12% to Under 2% — wie die Integrationsschicht auf der Verkäuferseite jenseits des Marketplace aussieht: Validierung, Versandrouting und ERP-Rückschreibung

Eine beispielhafte Umsetzung

Ein B2B-Händler im Mittelstand betreibt Amazon neben seinem eigenen BigCommerce-Storefront und NetSuite, und sein Operations-Team kann nicht abgleichen, was der Agent des einen Kanals getan hat, mit dem, was die anderen Systeme annehmen. Der Aufbau beginnt mit einer Systeminventur (welche Oberflächen das Selling-Partner-Plugin abdeckt, was NetSuite und BigCommerce nach außen bereitstellen), einer Workflow-Karte (Preisanpassungen, Bestandssynchronisierung, Bestelleingang) und einem fest definierten Geltungsbereich: das First-Party-Plugin, wo es passt, individuelle MCP-Module für NetSuite und BigCommerce sowie eine Orchestrierungsrichtlinie, die Schreibvorgänge eingrenzt, eine Freigabe pro Aktion für Preisänderungen oberhalb eines Schwellenwerts verlangt und jede Agenten-Aktion in einem Audit-Protokoll festhält, das sowohl das ERP als auch der Compliance-Workflow lesen können. Der erste integrierte Ablauf — eine Preisänderung auf Amazon, die die NetSuite-Staffelliste prüft und die Entscheidungshistorie zurückschreibt — geht in 5–8 Wochen live.

Fordern Sie einen Umsetzungsauftrag mit klarem Geltungsbereich an. Einwöchige Discovery-Phase. Sie erhalten eine Systeminventur, eine Workflow-Karte und einen festen Geltungsbereich — ganz gleich, ob Sie mit uns bauen oder nicht.