When the Marketplace Opens to Agents: Amazon Seller Central's AI Plugin and the Sell-Side Operations Layer

Key takeaways

• Amazon opened its Seller Central sell-side API surface to outside AI agents on September 23, 2026 — a US beta Selling Partner plugin for Amazon Quick and Anthropic's Claude covering inventory, prices, listings, and sales analytics.
• 90% of Amazon selling partners already use third-party AI tools, and sellers accept Seller Assistant's recommendations more than 90% of the time — Amazon is following its sellers into an agent-mediated workflow that already exists.
• Amazon chose the plugin path, not an open protocol — UCP, ACP, AP2, and x402 remain buy-side standards, Amazon decides which assistants connect, and it blocked Meta's Muse shopping agent from its store days before the announcement.
• The permission model is the evaluation surface: scoped data types, per-action human approval, and complete audit trails — sellers choose which data the plugin reaches and approve each action before it executes.
• The plugin connects Amazon's data to the assistant — not the seller's own stack — a B2B seller running NetSuite, BigCommerce, or ShipStation still needs its own agent module layer for tier pricing, multi-channel inventory, and order write-back.

Every agentic-commerce standard tracked this year — UCP, ACP, AP2, x402, Checkout MCP — describes the buy side: how an agent discovers a product, negotiates a price, completes checkout, and pays. (We mapped that stack in Commerce Protocols for AI Agents.) On September 23, 2026, at its Accelerate seller conference, Amazon opened the other side of the transaction. A new Selling Partner plugin puts the sell-side operations of the largest marketplace — inventory, prices, listings, and sales analytics — inside Amazon Quick and Anthropic's Claude, in a US beta. The pull is measurable: 90% of Amazon selling partners already use third-party AI tools to run parts of their business, and the fees those sellers paid Amazon brought in $46.8 billion in the second quarter of 2026 — more than AWS revenue, as GeekWire notes in its coverage.

This article maps what the plugin actually opens, why Amazon chose the agent-plugin path instead of an open protocol, what the permission model gates, and what it does not solve — because a B2B seller's operation does not end at the marketplace boundary. The pricing an agent adjusts on Amazon has to reconcile with the tier prices in NetSuite. The inventory level it just changed has to agree with BigCommerce and the warehouse. The orders the marketplace produces still have to reach an ERP. The plugin is the marketplace's answer to agent operations. The seller's side of that integration remains to build.

What Amazon actually shipped

Three things launched on September 23, and it is worth separating them because they have different evaluation profiles.

Seller Assistant, upgraded. The AI companion inside Seller Central now carries persistent memory of each seller's pricing patterns, inventory cycles, and growth goals, and it runs on Amazon Bedrock with Claude models. Amazon reports it has rolled out to over 90% of selling partners with hundreds of thousands of active users, and that sellers accept its recommendations more than 90% of the time. That last number matters more than the memory feature: a majority-accepted recommendation engine inside Seller Central is the behavioral baseline the plugin extends.

Seller Assistant workflows. Always-on automations that monitor conditions and act with permission — "alert me if any of my top 10 products drop below a 4-star rating and draft a response plan," or "monitor my top category for competitive openings; if you see one, adjust my pricing and refresh the listings." Sellers set guardrails in plain language and choose whether the workflow only surfaces recommendations or takes actions. Every action is logged with a complete audit trail.

The Selling Partner plugin. The new surface. The plugin connects a seller's listing contributions, real-time performance metrics, inventory levels, and sales analytics to an outside agent — Amazon Quick at launch, Claude in beta — and the outside agent can act on the account the way Seller Assistant does inside Seller Central. Amazon says connecting Claude takes roughly 60 seconds with no coding, alongside a seller's existing accounting and supplier data connections.

The framing from Amazon's own VP is the strategic headline: "Our vision was that they would never have to log into Seller Central," said Mary Beth Westmoreland, vice president of Worldwide Selling Partner Experience, in GeekWire's interview. "We would just bring it to them where they work."

Why the plugin path, not the protocol path

The buy-side protocols are open by design: UCP has a public spec and co-developers, ACP lives on GitHub, any merchant can expose an endpoint. The sell-side opening is the opposite shape. Amazon publishes a plugin for assistants it chooses — its own Quick first, then Anthropic's Claude, a company Amazon has invested billions in and whose models already power Seller Assistant — and says more integrations will follow, built in a way that is "modular enough for us to continue to publish plugins." Nothing in the announcement describes a specification other platforms could implement.

The context sharpens the contrast. Days before Accelerate, Amazon blocked Meta's Muse, a consumer shopping agent, from its store — with Amazon's stated position that outside agents must identify themselves and follow the rules of the sites they use (GeekWire). On the sell side, Amazon is simultaneously the host, the rule-setter, and the plugin publisher. The sell-side agent surface exists where Amazon says it exists.

For sellers, that is not a reason to stay out. It is a reason to evaluate the terms with the same rigor as the capabilities — because the surface can be extended, re-priced, or narrowed by the counterparty that owns the marketplace. Seller fees are already the subject of the FTC's antitrust case against Amazon, set for trial in March 2027 (GeekWire); seller-tooling economics are not a neutral backdrop.

The diagram below places the plugin against the buy-side protocol stack and the permission gates it applies.

What the permission model gates

Amazon's own safety description is precise enough to evaluate: plugin interactions are protected by "clear boundaries on what it can access, human approval on actions, and complete audit trails." In practice that is four gates.

Data scope. Sellers choose which types of data the plugin can reach — listings, inventory, sales analytics, performance metrics. Scope is per data type, selected by the seller.

Intent visibility. In Quick, agents built around the plugin — a pricing agent, a listing agent, a restock agent — show what they intend to do before they do it.

Human approval. Actions require the seller's approval before they are carried out, matching the pattern Seller Assistant workflows already use: recommend-only, or act-with-approval.

Audit trail. Every action is logged. Amazon also states it does not see the other business data in a seller's assistant — the accounting and supplier connections a seller keeps in Claude. That is Amazon's statement about its own enforcement, not an independently verifiable property; treat it accordingly.

This is the same control pattern a custom MCP module enforces: scoped tools, typed parameters, human gates on writes, logs that survive an audit. The difference cuts against the seller's visibility. With your own module, the scopes are code your team can read. With a first-party plugin, the marketplace defines the scopes and the seller trusts the vendor's enforcement. Neither is wrong — but they are different trust decisions, and the second one deserves the same review a security team would give any third-party integration.

The gap: the plugin connects Amazon's data, not the seller's stack

The 60-second connection binds Amazon to the assistant. It does nothing for the systems where a B2B seller's actual operation runs.

Pricing. The plugin can adjust Amazon prices within seller guardrails. It cannot check the customer-tier price list in NetSuite, the contract terms in a CPQ, or the margin floor before doing it. For a seller whose Amazon channel must reconcile with direct B2B pricing, the pricing logic that governs the change lives outside the plugin's reach.

Inventory. It sees Amazon inventory levels. Multi-channel stock — the same SKU in BigCommerce, in a Brightpearl warehouse, allocated to a ShipStation shipment — is a separate synchronization problem the plugin does not touch.

Orders and write-back. Marketplace orders still need validation, tax and shipping logic, and ERP entry. That is the order-management layer — the one where a 380-employee distributor processing 1,800 orders a week cut a 12% entry error rate to under 2% with typed-schema validation across NetSuite, BigCommerce, and ShipStation.

The assistant-of-choice pattern cuts both ways. Amazon's pitch is that sellers already run Claude "alongside their existing accounting and supplier data connections." Once Amazon's data lands in the same assistant, the seller will ask it to reconcile Amazon pricing with ERP costs and marketplace inventory with warehouse stock. That cross-system reasoning is exactly the integration the plugin does not provide — and the seller's own agent layer is what makes it safe: governed modules for each system, explicit handles for what the agent may read and write, and an audit trail that lands in the systems the business already audits.

What to evaluate before enabling the beta

Four questions, in order:

1. What can the plugin write, not just read? Pricing changes, listing edits, and inventory adjustments are different risk classes. Amazon's workflows distinguish recommend-only from act-with-approval — map each workflow to the right class before switching it on.
2. Where does approval sit? Per action, per workflow, or per session. Per-action approval on a pricing agent is a different operating model than a session-wide grant.
3. What does the audit trail capture, and where can it go? If your auditor reads NetSuite or a compliance warehouse, the trail has to reach the system your auditor already reads.
4. What does the seller's side need? Which of your systems must see what the agent did — the ERP, the storefront, the warehouse — and how does that data travel? That is the integration you own.

The sell-side operations layer is now an agent surface. Amazon has made its move with a plugin and a permission model; the part a mid-market B2B seller actually owns is everything the plugin does not connect.

Related reading

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — the buy-side protocol stack this plugin complements: discovery, checkout, payment mandates, and the B2B semantic-layer gap
• More RFQs, Fewer Real Opportunities: A Sell-Side Qualification Layer for Agent-Generated Demand — the demand-side counterpart: when agents generate the inbound, how a supplier's quoting team qualifies it
• Order Management: How an Agent Validates 1,800 B2B Orders a Week and Cuts the Error Rate from 12% to Under 2% — what the seller-side integration layer looks like beyond the marketplace: validation, fulfillment routing, and ERP write-back

Representative build vignette

A mid-market B2B seller runs Amazon alongside its own BigCommerce storefront and NetSuite, and its operations team cannot reconcile what one channel's agent did with what the other systems believe. The build starts with a system inventory (which surfaces the Selling Partner plugin covers, what NetSuite and BigCommerce expose), a workflow map (pricing adjustments, inventory synchronization, order intake), and a fixed scope: the first-party plugin where it fits, custom MCP modules for NetSuite and BigCommerce, and an orchestration policy that scopes writes, requires per-action approval on price changes above a threshold, and lands every agent action in an audit log both the ERP and the compliance workflow can read. The first integrated flow — a price change on Amazon that checks the NetSuite tier list and writes the decision trail back — goes live in 5–8 weeks.

Request a scoped build. One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.