Claude Commerce Agents and Magento: What It Takes to Plug In

On September 2, 2026, Anthropic published a blueprint for building commerce agents on Claude: a shopping agent that customers talk to inside a store’s site or app, and a merchant agent the store team uses to run the back office. The code is open source, under the Apache 2.0 license, in the anthropics/commerce-agents repository. Anthropic names Shopify and Priceline among the enterprise customers already running shopping agents on Claude, and Accenture, Mastercard and Visa as partners.

The news came back to my feed this week through a post by Idan Hayon, a fraud and payments specialist. His point stayed with me. The agent can take the customer all the way to checkout, but payment still happens in the merchant’s own checkout. Once agents start paying too, someone has to answer new questions: is this a legitimate agent, did the customer authorize this purchase, and who is responsible when the agent buys the wrong thing?

I read the repository with a Magento developer’s eyes. The interesting part for us is less the AI and more the contract it expects from the store. In this post I go through what Anthropic actually released, where the agent stops, how it would plug into a Magento or Adobe Commerce store, and where Adobe stands on the same topic.

What Anthropic released

The announcement calls it “a blueprint to help build commerce agents on Claude”. It is reference code, not a hosted product. The repository README describes it as “a reference implementation; it is not maintained and does not accept contributions.”

What is inside:

• Two agents. The shopping agent searches, compares, plans, fills the cart, answers order and policy questions, and remembers what a customer tells it. The merchant agent explains performance, maintains listings, acts on inventory alerts, prices and promotes, and drafts campaigns.
• Three ways to run them. The same agent definition runs on the Messages API, on the Claude Agent SDK, and on Claude Managed Agents (beta), where it calls your MCP server.
• Skills. Five flows per agent, one SKILL.md each. On the shopping side: search and discovery, multi-item planning, purchase research, personalization, and customer care.
• Four working examples. Retail, travel, telecom and ticketing, all with fictional ACME brands, each with a storefront and a merchant portal.
• A Claude Code plugin that scaffolds an agent against your own systems.

Deployment is through the Claude API, Amazon Bedrock, Microsoft Foundry or Google Cloud Vertex AI.

Anthropic also shares a number: according to the announcement, retailers running shopping agents on Claude have seen “carts up to 35% larger and shoppers 60% more likely to complete a purchase.” That is vendor data, from retailers it doesn’t name, so I read it as a direction, not a benchmark.

The agent stops before payment

This is the part that answers the fraud question, at least for now. The README is explicit: “Nothing places an order, charges a card, or changes a live listing.” The checkout tool renders the cart for your application to complete. The announcement says the blueprint “leaves payment to you, whether that is your existing checkout or an agentic payments provider.”

On the merchant side, every write is staged. A price change, a restock or a new campaign waits until a person approves it in the host application. With the default settings, typing “yes, apply it” in the chat doesn’t count as approval.

The repository’s backend guide lists three ways to hand off checkout:

A detail I liked: the hosted checkout URL comes from your backend after the model’s call, so the URL never passes through the model.

So where do Visa and Mastercard fit? The announcement quotes both companies on trust, but doesn’t describe a specific payment product. Their own agentic products show where this is going. Mastercard announced Agent Pay in April 2025, with “Mastercard Agentic Tokens” and a rule that trusted AI agents must be “registered and verified.” Visa’s Trusted Agent Protocol is “a verifiable, cryptographic standard” that helps merchants “differentiate legitimate agents from nefarious bots or web crawlers”, using HTTP message signatures (RFC 9421).

Those are exactly the questions from the fraud side. Today, with this blueprint, the customer still pays in your checkout, so your existing fraud rules still apply. The day an agent pays on its own, verifying the agent becomes part of your checkout.

One interface between the agent and your store

Here is the part that matters most to a commerce developer. The shopping agent talks to your store through one Python interface, StorefrontBackend. You implement it over your catalog, cart, order and policy systems. The model never calls your APIs directly and never sees a token: each method runs server-side with the credential your host holds for the session.

The required methods:

And the optional ones: checkout_handoff, get_account_context and get_disclosure.

If your store has no cart on a given surface, or no order tracking, you switch that system off in the config (enable_cart, enable_orders, enable_policies, enable_fulfillment), and its tools disappear from the agent. The guide also suggests a small pilot: implement search and product details, and stub the rest.

Mapping it to Magento

This is my own mapping, from the interface above to Magento’s GraphQL API. I haven’t run it against a store, so treat it as a starting point.

The product model fits Magento well. The blueprint has three shapes: a plain product, a family with options, and a variant with its own id, price and stock. A configurable product is the family, and each simple child is a variant. Its guide even shows the case of a parent that isn’t purchasable on its own, which is how configurables work.

A first version of search_products could look like this. The query fields come from Adobe’s GraphQL reference. I checked the code against the repository’s real types with a mocked GraphQL response, not against a live store:

import httpx

from shopping_agent import Product, SearchFilters, ShoppingSessionContext, StorefrontBackend

QUERY = """
query ($q: String!, $size: Int!) {
  products(search: $q, pageSize: $size) {
    items {
      __typename
      sku
      name
      stock_status
      price_range { minimum_price { final_price { value currency } } }
      ... on ConfigurableProduct {
        configurable_options { label values { label } }
      }
    }
  }
}
"""


class MagentoStorefront(StorefrontBackend):
    def __init__(self, graphql_url: str):
        self.client = httpx.AsyncClient(base_url=graphql_url)

    async def search_products(
        self,
        session: ShoppingSessionContext,
        query: str,
        filters: SearchFilters | None = None,
        limit: int = 8,
    ) -> list[Product]:
        response = await self.client.post("", json={"query": QUERY, "variables": {"q": query, "size": limit}})
        items = response.json()["data"]["products"]["items"]
        return [
            Product(
                product_id=item["sku"],
                title=item["name"],
                price=item["price_range"]["minimum_price"]["final_price"]["value"],
                currency=item["price_range"]["minimum_price"]["final_price"]["currency"],
                in_stock=item["stock_status"] == "IN_STOCK",
                options={
                    option["label"]: [value["label"] for value in option["values"]]
                    for option in item.get("configurable_options") or []
                },
            )
            for item in items
        ]

    # get_product_details, the cart, orders, policies and fulfillment follow the same pattern.

A few things I would watch in a real project:

• Customer tokens stay on the server. The agent session must carry the customer’s identity and token on your side. No tool argument names a user.
• Business rules stay in Magento. Salable quantity, customer group prices, cart price rules and stock reservations still decide what can be added. The blueprint’s gates check only that the product came from a catalog or order tool in this session and that quantities are within limits. In the repository’s words, “the backend decides whether a write is allowed at all.”
• Out of stock is an expected answer. When a variant can’t be added, the backend raises Unavailable with the ids of the in-stock siblings, and the agent offers them.
• Large configurables need care. A family’s details are capped at 12,000 characters by default, about sixty variants. The guide suggests splitting a big matrix, for example one family per color.
• The SaaS side is different. Adobe’s GraphQL reference notes that Adobe Commerce as a Cloud Service doesn’t support this products query; there you use the Catalog Service query instead. It’s the same split I wrote about in my last post on the two Magentos.

Safety lives in the code

What I liked most in the repository is that the important rules aren’t only in the prompt. The docs/safety.md file lists what the code enforces on all three runtimes:

• Fencing. Third-party text, like product descriptions, is sanitized, size-capped and wrapped in a fence before the model reads it. The prompt then tells the model that fenced text is material to report on, not instructions.
• Cart provenance. Cart writes accept only product ids that a catalog or order tool returned in this session, or lines already in the cart. The model can’t invent a SKU and add it.
• No payment. There is no method that places an order or charges a card.
• Host approval. Merchant changes apply only when your application marks them as approved.

The same file is honest about what is left to you: authentication on every route, rate limits, fraud and eligibility rules, payment, retention of customer memory as personal data, and log hygiene. The README puts it plainly: the examples “have no authentication and the MCP servers bind to loopback.” Nothing here is production-ready without that work.

Where Adobe Commerce stands

Adobe has its own track. In February 2026 it said Adobe Commerce is “moving towards supporting UCP and ACP”, the Universal Commerce Protocol and the Agentic Commerce Protocol. At Adobe Summit in April it introduced a Commerce MCP server and a Brand Concierge for conversational shopping. Neither post says which editions get these features, and neither mentions Magento Open Source.

Anthropic’s announcement names one protocol: UCP, in Shopify’s quote about its reference storefront.

My reading, as someone who works on these stores every day: a Magento Open Source or PaaS store doesn’t need to wait for anyone to try this. The blueprint only needs a backend over APIs that Magento already has. The hard part is the same as always: customer identity, prices per customer group, stock that is really salable, and a checkout you trust.

What I would do now

• Clone the repository and run the retail example. It takes a few commands and an API key, and it shows the shopping and merchant agents side by side.
• Read docs/backends.md and docs/safety.md before writing any code. They are short and very concrete.
• Start with a read-only pilot: search_products and get_product_details over a staging store, with the cart switched off.
• Map your configurable products to families and variants, and check your largest family against the size limit.
• Keep checkout in Magento. Use checkout_handoff to send the customer to the checkout you already have.
• Talk to your payment provider about agentic tokens and agent verification before any agent pays on its own.

Agents are moving closer to the purchase. For now, the catalog, the cart and the checkout still decide what is true, and those are the parts we know how to build.

Would you put a shopping agent in front of your Magento catalog today, or would you wait for the platform to ship one?

Sources

• Building commerce agents with Claude, Anthropic, September 2, 2026
• anthropics/commerce-agents on GitHub: README, docs/backends.md, docs/safety.md, shopping-agent/core/shopping_agent/backend.py
• Mastercard unveils Agent Pay, Mastercard, April 29, 2025
• Trusted Agent Protocol overview, Visa Developer
• Adobe Commerce commits to agentic commerce standards, Adobe, February 18, 2026
• Reduce time-to-value with agentic upgrades in Adobe Commerce, Adobe, April 20, 2026
• Adobe Commerce GraphQL reference: products query, addProductsToCart, ConfigurableProduct