Architecture

Agentic Commerce Architecture: One MCP Capability Layer, Four AI Channels

By IdeaBosqueLast updated: October 3, 2026

Key takeaways

Four AI access channels — a first-party portal, OpenAI ACP, Meta Muse, and external A2A agents — can share one MCP capability layer instead of four separate reimplementations of the same commerce logic.
The decision rule is one line: add a protocol adapter only when the external protocol differs from MCP. OpenAI's Agentic Commerce Protocol needs an ACP→MCP adapter; a connector that already speaks MCP needs none.
Magento / Adobe Commerce stays the authoritative system of record — ACP, MCP, and A2A never reproduce its pricing, inventory, tax, or order logic; they call into it.
Write tools are gated by impact at the tool boundary — reads like catalog.search_products flow freely, while sensitive writes like order.submit and payment.authorize require human approval and idempotency.

Connect your commerce catalog to ChatGPT, to Meta Muse, and to partner-company agents, and the naive design reimplements your pricing, inventory, and checkout logic four times — once per platform. Each AI surface speaks a different protocol: OpenAI brought the Agentic Commerce Protocol (ACP, co-developed with Stripe), agents talk to tools over the Model Context Protocol (MCP), and agents delegate to each other over A2A. The reflex is to build one integration stack per platform. That reflex is the expensive mistake.

This article maps a provider-neutral architecture for agentic commerce: one enterprise MCP capability layer on the southbound side, many AI access channels on the northbound side. It uses Magento / Adobe Commerce as the worked example of the commerce system of record, but the pattern applies to any ERP, OMS, or catalog. The core result is a single decision rule — add an adapter only when the external platform's protocol must be translated into MCP — that tells you exactly where integration code belongs and, more usefully, where it does not.

The trap: four platforms, four reimplementations

Every AI commerce surface wants the same underlying operations: search the catalog, check inventory, get a price, build a cart, submit an order. The naive architecture wires each surface directly into the commerce platform with its own logic:

the first-party website → custom Magento calls
OpenAI / ChatGPT → different Magento calls
Meta Muse → different Magento calls again
partner agents → yet another set

Now a pricing-rule change, a new tax jurisdiction, or an inventory-reservation fix has to be made — and tested — in four places. The business logic has been copied, and copies drift. This is the same per-connector sprawl that makes point-to-point integration expensive at any scale, applied to AI channels instead of SaaS endpoints.

The fix is to collapse the four southbound implementations into one. Every channel reaches the same enterprise capability layer, exposed through MCP, backed by canonical commerce services, and ultimately by Magento as the single source of truth for products, pricing, inventory, carts, tax, and orders. Magento keeps owning the commerce logic; the AI channels only call it.

The decision rule: adapter only on protocol mismatch

The channels differ in exactly one way that matters to the architecture: what protocol they speak. That single fact decides whether a channel needs a translation adapter or can plug straight into MCP. The three protocols are not competing — they answer different questions:

Technology	What it is	What it answers
HTTP / REST / JSON	Transport, API style, data format	How bytes move
ACP	AI commerce interoperability (OpenAI + Stripe)	How an AI commerce platform and a merchant transact
MCP	Agent/app-to-tool interoperability	What tools an agent or application can call
A2A	Agent-to-agent interoperability	How one agent delegates work to another

ACP and MCP solve different problems, so an ACP Adapter is genuinely required — it translates ACP's commerce semantics (checkout sessions, order state, feed formats) into MCP tool calls. A2A is also distinct: an external agent delegates a task over A2A, which a gateway routes into your Agent Core, which then calls MCP. But a platform whose connector model already consumes MCP needs no adapter at all — it reaches the capability layer directly.

This is the contrarian part. The instinct is "a new AI platform means a new adapter." The rule says the opposite: build an adapter only when the platform's protocol is not MCP. The four channels then resolve to four access paths, not four integrations:

First-party portal → Agent Core → MCP
OpenAI / ChatGPT → ACP → ACP Adapter → MCP
Meta Muse → Muse Connector → MCP (no adapter — the connector speaks MCP)
External agent → A2A → A2A Gateway → Agent Core → MCP

Everything converges at MCP. That convergence is the whole design:

The architecture in one view:

The MCP Commerce Server is the reusable boundary

The capability layer is an MCP server exposing a small, stable set of commerce tools — catalog.search_products, pricing.get_price, inventory.check, cart.create, cart.add_item, order.submit, order.get_status. Every channel uses the same tools. The first-party portal's Agent Core, the ACP Adapter, the Muse Connector, and external agents arriving over A2A all call catalog.search_products — they do not each implement product search.

Crucially, MCP is the capability interface, not the business data model. Behind the tools sit canonical commerce services — a protocol-independent model of Product, Variant, Price, Inventory, Cart, Order — and a Magento adapter that maps that canonical model to Adobe Commerce's APIs. When OpenAI's product-feed format or ACP's checkout schema changes, only the ACP Adapter changes. When Magento's API changes, only the Magento adapter changes. The tools in the middle stay stable. This is the same structural discipline as a governed MCP module: typed tools, a stable contract, and the vendor's quirks isolated at the edges.

Tools are classified by impact, and the classification is where governance lives. Reads (catalog.search, pricing.get, inventory.check) are low-risk and flow freely. Writes (cart.add_item) mutate state but are reversible. Sensitive writes (order.submit, payment.authorize, refund.create) move money or create obligations — they require human approval, idempotency keys to prevent duplicate orders, and audit logging, enforced at the tool boundary regardless of which channel invoked them. A connector's own governance layer (authentication, user permissions, human-approval gates) sits in front of the MCP server, not instead of it.

Why Meta Muse needs no adapter, and ACP does

The sharpest illustration of the decision rule is the contrast between the two external AI platforms. OpenAI's ACP and MCP are different protocols, so the ACP path carries an adapter that translates ACP commerce semantics into MCP tool calls. A connector model that submits its integration as an MCP endpoint, by contrast, consumes the capability layer directly — the governance boundary is the connector's review and permission model, but there is no second translation layer to build or maintain. Adding one "because Muse is a different platform" would be integration debt with no function.

The same test extends to every future AI surface. Ask one question: can this platform consume MCP directly? If yes, it plugs into the existing server and reuses every tool. If no, you add exactly one protocol adapter — and nothing else. That is how four channels (and the fifth, and the sixth) stay cheap.

Beyond commerce: the same layer becomes an enterprise agent platform

Commerce is only one MCP domain. The same Agent Core can call a Commerce MCP server, a CRM MCP server, and an ERP MCP server, composing a request like "find products compatible with this customer's prior purchases, under $500, in stock, and prepare a recommendation" across Commerce and CRM in one plan. For external delegation, A2A — which surpassed 150 organizations in its first year — lets a partner company's procurement agent delegate to your sales agent, which calls your MCP layer, without granting the partner direct access to internal systems. The commerce architecture and the broader MCP + A2A enterprise stack are the same architecture at different scopes.

A representative build

A mid-market merchant on Adobe Commerce wanted to be sellable inside ChatGPT and Meta Muse without a platform team. We built the canonical commerce services and the Magento adapter first, exposed six MCP commerce tools, and put the first-party portal's Agent Core on them. OpenAI came next: an ACP Adapter plus the product-feed transformer, reusing the exact same tools underneath. Meta Muse was the cheapest channel of all — the existing MCP Commerce Server was documented (endpoint, auth, tools, read/write classification, sensitive-write approvals) and submitted through the connector review, with no proprietary adapter written. One capability layer; each new channel was an access path, not a rebuild.