
이미지: 앤스로픽 공개 영상 갈무리
Summary
- On September 2, Anthropic released a blueprint for building shopping and merchant agents under the Apache 2.0 license.
- The repository includes four example verticals — retail, travel, telecom, and entertainment — along with a Claude Code plugin.
- The design ensures payments and price changes can't be executed by the model directly; they only queue up for human approval.
The whole blueprint, out in the open
On September 2, Anthropic open-sourced a blueprint for building commerce agents. The GitHub repository anthropics/commerce-agents contains implementation code for a customer-facing shopping agent and a merchant agent that runs a store's back end, plus four example verticals — retail, travel, telecom, and entertainment — all under the Apache 2.0 license.
Anthropic built this repository to be forked directly. It ships without connectors, leaving the backend slot open so each company can wire its own inventory and order systems in via MCP. Every store and product in the examples is fictional — no real orders or payments go through. The repository description is explicit that this is a reference implementation, and Anthropic won't be maintaining it or accepting outside contributions.

One agent for the customer, one for the store
The shopping agent handles what a customer says in natural language. It searches the catalog, compares multiple products on screen, fills a cart, and answers questions about order status or return policy. Five skills sit underneath it: search and discovery, purchase research, planning, customer support, and memory and personalization.
The merchant agent runs on the store's side of the screen. It analyzes sales, tracks inventory, suggests pricing and promotions, and drafts marketing campaigns. It also has five matching skills: performance analytics, catalog management, inventory operations, pricing and promotions, and marketing campaigns.
There's a single rule for deciding what goes into the system prompt versus what gets pushed out to a skill: whatever covers roughly a third of all conversations stays resident in the prompt, and the long tail gets handled through skills instead.
One notable structural choice is that there's no intent classifier up front. Rather than splitting a conversation and routing it to separate specialized agents, a single model runs a standard agent loop and pulls in whatever skill it needs, when it needs it. Think of a customer service counter: an intent router is like a front desk that hears your issue and sends you to "the third floor." This design is more like one staff member who stays with you the whole time and pulls out the right file whenever it's needed.
Screen rendering follows the same logic. The model doesn't write markup directly — it calls tools like present_products or present_itinerary, and the server validates the arguments and fills in the details to build the screen. Tool results get trimmed down to only the fields that are needed before being passed along; things like image URLs are stripped out entirely.
The model can't move money
The part of the code that got the most attention wasn't revenue generation — it was the brakes. Anthropic set out a core design principle: "No tool call the model makes should move money or change the business."
The safeguard has three layers. First, everything queues instead of executing. Payment flows stop at rendering the cart and a checkout button on screen, and any merchant-side price change or campaign launch sits in an approval queue. Someone has to actually click through on a portal or confirm via CLI before anything takes effect.

Second, only server-issued IDs are accepted. The server logs every ID it hands the model during a session, and filters out anything else before it reaches the backend — whether it's an ID the model made up, one a user pasted in, or one planted inside a product review.
Third, fees, disclosures, and regulatory language only ever come from pre-approved copy. The model can't generate that text on its own, and the merchant agent is also blocked from touching protected fields like pricing terms.

Rate limits are also applied differently than you might expect: they're set on outcome state rather than on individual requests, and writes within a single session are serialized in order. That's meant to close off any workaround where an agent fires off multiple parallel tool calls to get around a limit.
Memory lives in a database, not a notepad
Long-term memory isn't stored as a markdown profile — it's saved as typed records in a database. Each fact gets broken down into a key, a value, a category, and the session it came from, forming a single row.
Memory writes happen asynchronously, after a turn ends, so the user isn't left waiting on a response. The extraction step only reads the conversation text, never the tool results — a safeguard against a product description accidentally getting mistaken for a user's stated preference. Anthropic says this approach raised factual recall by 13% in internal testing.
Reading memory happens across three tiers: always-on values like a default store or shipping preference, values pre-fetched every turn for context (like a shoe size when someone's browsing footwear), and everything else, which gets pulled on demand through a lookup tool.
15 minutes, one hour
Anthropic says retailers running shopping agents on Claude have seen cart sizes grow by as much as 35%, along with a 60% increase in checkout completion rates. On adoption speed, the company quoted customers directly. Dror Zalika, who leads commerce at Wix, said their engineers "stood up a prompt-driven commerce agent in 15 minutes." Ashley Nader, a staff product manager at Fetch, said her team "got both agents from the blueprint running locally in under an hour, and real conversations worked on the first try."
The engineering documentation also includes operational figures. Cache hit rates across deployments ran 90–99%, and cached tokens cost a tenth as much as fresh reads while processing 1.5 to 2 times faster. A typical task wraps up in three to five model turns, and commerce responses tend to run 500–700 tokens in output length. Anthropic recommends starting with an evaluation set of 50–100 cases per user flow.
There are three execution paths: a reference loop built on the Messages API, the Claude Agent SDK, and a beta managed-agent option. A Claude Code plugin is also included for scaffolding. Supported deployment targets include the Claude API, Amazon Bedrock, Microsoft Foundry, and Google Cloud Vertex AI.
Editor's take
What stuck with me reading this wasn't the performance numbers — it was the directory names in the repository. docs/safety.md, gates, guardrails, an approval console. These are usually the things you bolt on last, and often skip, when you sit down to build a commerce agent. Here they're baked in as folder names from the start.
That's where the weight of this blueprint actually sits. It's not a guide for building a demo — it's a guide for turning a demo into something you can put in front of other people's money.
Anyone who's actually shipped an agent knows exactly where things break. A demo that works fine in testing almost always has its first real incident in production when the model invents a product code that doesn't exist, or touches someone else's order using an ID it picked up from somewhere it shouldn't have. One rule — only accept server-issued IDs — closes off that entire failure mode.
This maps almost exactly onto the problem Korean commerce companies are wrestling with right now. Plenty of companies have already bolted product search and support chatbots onto their storefronts, and most of them stall at the same point: the bot talks a good game, but nobody trusts it to actually handle a payment.
The answer this code offers for clearing that last hurdle isn't a smarter model — it's taking execution authority away from the model by design. The model never presses the payment button; a person does. A price change on the merchant side sits in an approval queue. Under this structure, the worst-case failure is capped at "one odd suggestion sitting in a queue somewhere."
One more detail worth flagging: the choice to store memory as database records instead of prose. A lot of agents today accumulate user memory as sentences in a markdown file, and that's a risky pattern for commerce specifically. One stray line from a product description can harden into a "preference," and every recommendation after that gets skewed. That's exactly why Anthropic built a separate extractor that never reads tool results at all — and the 13% recall improvement comes directly out of that isolation.
The timing of this release is no accident either. Anthropic opened the code right as US retail heads into peak-season prep in early September, effectively laying down a standard playbook — "build your commerce agent on our model" — ahead of competitors. Shipping it under Apache 2.0 with the connector slot left empty means it can plug into anyone's backend. And whoever plugs it in ends up running Claude underneath. The blueprint is what's open source here; what's actually for sale is the tokens that run on top of it.





Comments