Yesterday I wrote about Anthropic’s blueprint for commerce agents. Now there’s a companion guide that explains why the reference implementation is built the way it is. Ali Shazal and Matthew Koen wrote it, and if you spend the 25 minutes of reading time, you’ll learn things that reach well beyond online shops.
The first decision is architectural. It’s tempting to build one subagent per domain: one for search, one for returns, one for the cart. Anthropic advises against it. A shopping conversation is one tightly coupled session across many intents, and every handoff to a subagent loses state, costs several times the tokens and adds seconds of latency. Across several enterprise deployments, a single agent with skills beat both the one-prompt-for-everything design and the subagent design on quality, often at lower cost. Subagents earn their place only for self-contained tasks that benefit from their own context window, like deep research, or as a real hand-off to an agent with its own compliance surface, say in a pharmacy.
What goes in the system prompt, what goes in a skill? The rule of thumb: anything relevant to a third or more of your traffic goes in the prompt, the rest goes in skills. Safety rules, legal constraints, brand rules and critical user facts like allergies always live in the prompt. That’s why product search sits in the shopping agent’s prompt, while skills such as “purchase-research” or “customer-care” cover the long tail.
Two points about tools struck me as especially practical. First: tools call the systems a retailer already runs, search, ranking, cart, promotions. Search results arrive already ranked; the model only decides which ones serve the user. Second: tool results are context. Return only the fields the model reasons with. Image URLs on every search row are, according to Anthropic, the usual offender. And instead of a bare 403, hand the model an instruction like “Include a product ID when querying availability.”
The part I found most interesting as a product person: UI components are tools. Most responses from a commerce agent aren’t prose but a product carousel, an itinerary, a seat map. Teams that have the model emit custom tags and parse them client-side hit a wall as the surface grows. Instead, the model calls present_products or present_itinerary with typed arguments. That comes with a nice side effect: when the customer says “the first hotel,” the on-screen layout is right there in the arguments of the last tool call. The model knows what’s currently visible.
On latency, Anthropic lists three levers: fewer turns, faster tools, faster tokens. One tip runs against intuition: if a task takes more than about five turns in production, the faster model is frequently the smarter one, because it plans better and needs fewer rounds.
For memory, the guide recommends a separate extractor that asynchronously writes facts to your own database after each turn, rather than giving the agent a “remember this” tool. It adds no latency and delivered 13 percent higher fact recall on Anthropic’s internal eval. And on safety: the model proposes, a person or a policy applies. The backend interface behind the checkout tool simply has no charge method. On the merchant side, every write tool only produces a staged change with a server-generated ID that gets applied after approval.
The guide’s closing line sums it up: most of this has nothing to do with the model. Tools, skills, evals and harness stay in place when the next model ships. That’s the real message, and it applies to any agent you’re building right now.
Sources: Anthropic: A guide to the anatomy of effective commerce agents, GitHub: anthropics/commerce-agents