WEBVTT

1
00:00:01.300 --> 00:00:07.956
This is Anthropic, Read Aloud. Today: A guide to the anatomy of effective commerce agents.

2
00:00:09.256 --> 00:00:12.249
A guide to the anatomy of effective commerce agents.

3
00:00:12.699 --> 00:00:20.257
The architecture, latency and cost techniques, and eval practices for agents that make it easier to buy and sell online.

4
00:00:20.707 --> 00:00:24.611
From Claude Blog, published September 2, 2026.

5
00:00:25.611 --> 00:00:27.121
ca- shared styles v1

6
00:00:27.571 --> 00:00:38.970
Over the past year, we've worked with teams across the commerce industry, retailers, marketplaces, travel, entertainment, and telecom providers, to build commerce agents using Claude.

7
00:00:39.420 --> 00:00:55.458
These agents are in production, and enterprise customers have seen larger carts and more efficient seller operations when using them. They also share a simple architecture: Claude in an agent loop equipped with a set of skills, tools, and a strong eval suite.

8
00:00:55.908 --> 00:01:15.098
This post is for the engineers and engineering leaders building these (or other consumer facing) agents. Part 1 covers the architecture, which you decide once. Part 2 covers latency and cost. Part 3 covers production: memory, safety, evals, and scaling the work across an organization.

9
00:01:15.548 --> 00:01:38.101
Reference implementationWe've also provided a blueprint to help build commerce agents on Claude. It contains the harnesses, patterns, and guardrails an engineering team needs to get a commerce agent running in days, with reference implementations of a shopping agent and a merchant agent for retail, travel, telecom, and ticketing platforms. anthropics/commerce-agents to

10
00:01:38.551 --> 00:01:39.404
In this guide

11
00:01:39.854 --> 00:01:52.162
1. Part 1: The architectureWhat is a commerce agent?Skills, not subagentsSystem prompt or skill: decide by frequencyEngineering agent toolingThe U I components are tools.

12
00:01:52.402 --> 00:02:02.772
2. Part 2: Making it fast and affordableMinimizing task completion latencyPerceived latencyPrompt cachingChoosing the model and its configuration.

13
00:02:03.012 --> 00:02:15.950
3. Part 3: Running it in productionMemory that survives the sessionSafety: enforcement lives in the harnessEvals: shipping a non-deterministic systemShipping with a large organization.

14
00:02:16.190 --> 00:02:17.528
4. Looking ahead.

15
00:02:17.978 --> 00:02:18.831
01

16
00:02:19.631 --> 00:02:20.657
The architecture.

17
00:02:21.107 --> 00:02:29.321
One model in a standard agent loop, with skills for the long tail and tools that call the systems you already run. You decide this once.

18
00:02:30.121 --> 00:02:31.518
What is a commerce agent?

19
00:02:31.968 --> 00:02:38.385
We define a commerce agent as an agent that simplifies buying and selling across an online catalog.

20
00:02:38.835 --> 00:02:58.546
Some agents face consumers: they search, compare, substitute, and assemble the order. That could be a retail cart, a travel itinerary, a mobile plan change, or seats held for a show. Some agents face the business: they answer questions about sales, run promotions and campaigns, and manage inventory and pricing.

21
00:02:58.996 --> 00:03:14.731
The core architecture is a model in a standard agent loop: reasoning about a goal, exploring context, taking actions through tools, learning procedures through skills, asking clarifying questions, and observing the results until the goal is accomplished.

22
00:03:15.181 --> 00:03:22.349
There is no intent router in front of it that segments the conversation and no set of domain specific agents behind it.

23
00:03:23.149 --> 00:03:24.568
Engineering context.

24
00:03:25.368 --> 00:03:26.836
Skills, not subagents.

25
00:03:27.286 --> 00:03:36.921
A commerce agent has to cover a wide range of capabilities across many categories and intents, which makes it tempting to create one subagent per domain.

26
00:03:37.371 --> 00:03:48.526
In practice this proves suboptimal, because a commerce conversation is one tightly coupled session across multiple intents and turns, and requires considerable shared context.

27
00:03:48.976 --> 00:03:57.118
In a subagent architecture, the orchestrator holds the cart or staged changes, the user's preferences, and the conversation history.

28
00:03:57.568 --> 00:04:13.850
Every handoff to a subagent is a state-lossy operation, which often impacts the quality of the subagent’s response and, consequently, the overall response. On top of that, each handoff can cost several times the tokens and adds seconds of latency.

29
00:04:14.300 --> 00:04:28.849
The domains also rarely separate cleanly. A returns flow might need the order history, the current cart, and the product catalog, meaning a subagent-per-domain approach either duplicates that access everywhere or hands off mid-task.

30
00:04:29.299 --> 00:04:39.764
As models get smarter, they also handle longer context, more skills, and more tools, so the limits behind today's placement rules loosen with each model generation.

31
00:04:40.214 --> 00:04:52.982
Instead, agent skills give you similar per-domain modularity and context control without the handoff tax, because the skill instructions load into the main agent that already holds the entire history.

32
00:04:53.432 --> 00:05:08.549
In our comparisons across several enterprise deployments, a single agent with skills consistently has outperformed both the one-prompt-for-everything design and the subagent design on quality, and often at a lower cost and latency per task.

33
00:05:08.999 --> 00:05:19.613
Where subagents do earn their place is when the orchestrator can call them as a tool for a narrow or self-contained task that would benefit from its own dedicated context window.

34
00:05:20.063 --> 00:05:37.675
A common production example is a deep-research subagent, where the subagent searches and reads documents, writes and runs code, traverses data models, and hits dead ends. All the work happens inside one or more subagents, and only a compact answer comes back to the orchestrator.

35
00:05:38.125 --> 00:05:58.113
The other exception is a domain that already has its own purpose-built agent. If your pharmacy or financial-services experience runs a dedicated agent with its own compliance surface, the right move can be a hand-off, where that agent takes over the task and works with the user directly through its own loop until the task is done.

36
00:05:58.563 --> 00:06:13.464
The distinction is ownership of the conversation. A hand-off makes the domain agent the user's counterpart, while delegation keeps the orchestrator, bouncing the domain agent in and out within a single turn and degrading on every exchange.

37
00:06:14.264 --> 00:06:17.248
System prompt or skill: decide by frequency.

38
00:06:17.698 --> 00:06:33.227
The main factor when deciding whether to put a set of instructions within a system prompt or skill is how often the agent will need it. Loading a skill costs a model turn, so anything the agent needs on most turns generally goes in the system prompt.

39
00:06:33.677 --> 00:06:51.891
This does, however, depend on how your traffic is distributed, and what agent behavior your evals show. A good starting point is that anything relevant to a third or more of your traffic, whether anticipated before launch or observed in production, goes in the system prompt, and the rest goes in skills.

40
00:06:52.341 --> 00:07:04.641
If a skill is predictable from a signal you already have, such as the page the user arrived from, we recommend injecting it from the harness before the first model call and skipping the extra turn to load the skill.

41
00:07:05.091 --> 00:07:13.859
Critical instructions, such as safety and legal rules, brand constraints, and key user facts such as allergies, always go in the system prompt.

42
00:07:14.309 --> 00:07:22.906
For commerce agents, this means product search lives in the prompt, since nearly every session touches it, and skills carry the long tail of features.

43
00:07:23.356 --> 00:07:39.299
In our reference implementation, the shopping agent's prompt holds grounding, cart and checkout semantics, and presentation rules, and the following skills cover the rest: search-discovery, purchase-research, planning-goals, customer-care, and memory-personalization.

44
00:07:39.749 --> 00:07:51.933
The merchant agent splits the same way, with performance-insights, catalog-listings, inventory-operations, pricing-promotions, and marketing-campaigns as its skills, one per operational domain.

45
00:07:52.383 --> 00:07:58.696
In the prompt Shopping agent Grounding, cart and checkout semantics, presentation rules, and product search.

46
00:07:58.816 --> 00:08:15.380
Shopping skills The long tail search-discovery · purchase-research · planning-goals · customer-care · memory-personalization Merchant skills One per operational domain performance-insights · catalog-listings · inventory-operations · pricing-promotions · marketing-campaigns

47
00:08:16.180 --> 00:08:17.771
Engineering agent tooling.

48
00:08:18.221 --> 00:08:25.538
Our post on writing effective tools for agents covers tool design in general. Two points have mattered most in commerce:

49
00:08:25.988 --> 00:08:29.382
Build agent tools on top of your core systems and logic.

50
00:08:29.832 --> 00:08:45.914
A commerce company already has search and ranking, a cart, a preferences and profile store, an inventory system, promotion and campaign engines, sales analytics, and more, each encoding logic tuned over years and seeing signals the model never will.

51
00:08:46.364 --> 00:08:54.765
The agent's tools should call those systems, not reimplement them, and the tool boundary is where their logic ends and the model's judgment takes over.

52
00:08:55.215 --> 00:09:06.625
For example, when the agent calls search products, the results should arrive already ranked; its job is to decide which results serve the user's goal, how many to show, and how to present them.

53
00:09:07.075 --> 00:09:08.623
Tool results are context.

54
00:09:09.073 --> 00:09:17.145
Return the fields the model reasons with and drop the rest. Image U R Ls on every search row are the usual offender.

55
00:09:17.595 --> 00:09:24.762
As needed, reshape the raw response inside the tool, including appending a next step when it isn't obvious from the data.

56
00:09:25.212 --> 00:09:40.276
This is especially relevant for error scenarios, where the model benefits from instructions instead of error codes. For example, add an error instruction "Include a product I D when querying availability," instead of a generic 403.

57
00:09:41.076 --> 00:09:42.774
The U I components are tools.

58
00:09:43.224 --> 00:09:56.190
Most commerce agent responses are U I components rather than prose, whether a product carousel, an itinerary, a seat map, or a chart. That means the agent has to emit a schema rather than text.

59
00:09:56.640 --> 00:10:05.899
Teams sometimes start by prompting the model to emit custom tags and parsing them on the client-side. This stops working as the surface grows, because:

60
00:10:06.349 --> 00:10:18.364
The model isn’t as well trained on your markup as it is on tool calls so reliability drops as nested components get added. Well-formed data is not guaranteed just through prompting.

61
00:10:18.604 --> 00:10:27.052
The tag definitions live in the system prompt, so every new component bloats context and every edit risks regressions elsewhere in the prompt.

62
00:10:27.292 --> 00:10:40.736
Past conversations end up stored in a format only your parser can read, so loading history means either parsing raw messages on the client or keeping a second copy in a format that isn't native to the model A P I.

63
00:10:41.186 --> 00:10:56.881
The pattern that has held up is to make each U I component a tool. The model calls present products, present itinerary, or present plan comparison with typed arguments; your server validates and enriches the call and emits an event; and your client renders it.

64
00:10:57.331 --> 00:11:12.057
As the components are tool calls, they're already in the messages array in native format, so you don’t need to re-parse when you reload an old conversation. An example presentation-tool contract is illustrated below and in the reference repo.

65
00:11:12.507 --> 00:11:27.761
The tradeoff is streaming granularity. Each top-level argument of a tool call buffers on the server for validation, so the sub-components of a presentation tool arrive in steps even with streaming on. This impacts perceived latency.

66
00:11:28.211 --> 00:11:37.371
To get a token-level stream, set eager input streaming: true on the tool definition, which skips the buffering and with it the server-side schema guarantee.

67
00:11:37.821 --> 00:11:47.388
In our evals, schema violations are very rare on Claude Sonnet-class models and up, but wrap the call in a retry for the cases where one slips through.

68
00:11:47.838 --> 00:12:02.382
Presentation tools also give the agent a record of what's on screen. When a customer says "the first hotel" or "the third one down on the left," the layout is in the messages array, in the arguments of the last presentation call.

69
00:12:02.832 --> 00:12:14.742
For that to work, the arguments have to reflect the rendered layout, so structure them the way the U I is structured, as ordered rows and carousels rather than a flat list the client rearranges.

70
00:12:15.192 --> 00:12:16.069
02

71
00:12:16.869 --> 00:12:18.631
Making it fast and affordable.

72
00:12:19.081 --> 00:12:27.256
Attack latency on two fronts, end-to-end and perceived, and let caching carry the cost. None of it should spend intelligence to get there.

73
00:12:27.706 --> 00:12:42.092
Latency matters in commerce, and consumer surfaces are the least forgiving. However, on agentic surfaces, what we have consistently seen move metrics like retention, engagement, and cart size is the quality of the outcome.

74
00:12:42.542 --> 00:12:50.966
Whether the answer was relevant and the task actually completed was more critical to those metrics as compared to marginal latency gains.

75
00:12:51.416 --> 00:13:03.504
So attack latency on two fronts. Minimize end-to-end latency through good engineering, and pair that with dropping perceived latency (since time spent watching an agent work reads as progress).

76
00:13:03.954 --> 00:13:11.119
Every user has a latency budget, and the techniques below keep the agent inside it without spending intelligence to get there.

77
00:13:11.919 --> 00:13:14.120
Minimizing task completion latency.

78
00:13:14.570 --> 00:13:32.808
Task completion latency is the sum, over model turns, of time to last token plus tool processing. That gives you three levers to work towards: fewer turns, faster tools, and faster tokens. These levers sometimes compete, so the thing to minimize is the sum rather than any one of them.

79
00:13:33.258 --> 00:13:53.043
Fewer turns Load likely context up front, increase model intelligence, and have the model call independent tools in parallel. Faster tools Optimize the tool's own backend, and dispatch tools eagerly as their arguments complete. Faster tokens Choose the model and its configuration by sweeping your eval suite.

80
00:13:53.843 --> 00:13:54.738
Fewer turns.

81
00:13:55.188 --> 00:14:08.335
Query complexity adds turns, and is generally out of your control. Model intelligence and relevant context help the agent get to task completion in fewer turns. Some of our key learnings in this area include:

82
00:14:08.785 --> 00:14:25.980
Load likely context up front. If the user opened the assistant from a product page, or a merchant opened it from a campaign dashboard, put that page's data in the session context. The conversation is likely about it, and answering from context costs no extra turns.

83
00:14:26.220 --> 00:14:47.362
Increase model intelligence. Smarter models can decrease overall turns in the completion of a task as the agent can more efficiently plan and issue its tool calls. That often outweighs their slower tokens. If your queries skew complex, or production shows more than about five turns per task, the faster model is frequently the smarter one.

84
00:14:47.482 --> 00:14:53.642
Which one that is depends on your traffic, so choose by sweep, as described under "Choosing the model" below.

85
00:14:53.882 --> 00:15:14.127
Have the model call independent tools in parallel. Commerce use cases often require many operations in parallel: be it searching for multiple products, querying many policy docs, or fetching records from many sources of sales data. Parallel tool ensures multiple independent queries don’t burn additional turns.

86
00:15:14.247 --> 00:15:23.698
Prompt the model to call many tools within a turn and return the results in one user message as an array of tool results (see the parallel tool use docs ).

87
00:15:24.498 --> 00:15:25.465
Faster tools.

88
00:15:25.915 --> 00:15:39.306
Optimize the tool's own backend. Sometimes a tool genuinely fans out to a merchant agent with a "get today's snapshot" query reads sales, inventory, and campaign status in three independent calls.

89
00:15:39.426 --> 00:15:59.241
But we often see the tool boundary become the place where missing backend logic gets stitched together: an availability check that calls the catalog for the SKU, the inventory service per store, and the fulfillment service for cutoffs, then applies substitution rules and pickup eligibility in the tool's own code before answering.

90
00:15:59.361 --> 00:16:17.338
That tool is now overloaded with domain knowledge, hard to keep correct as the rules change, and is carrying logic that should sit in an upstream system. When you find yourself writing that logic in a tool, the fix is one backend endpoint that answers the question, and calling that with an agent tool.

91
00:16:17.578 --> 00:16:39.792
Dispatch tools eagerly. Tool arguments stream out of the model like any other tokens, so the harness can execute each tool’s call as its arguments complete and process it while the model is still streaming other, parallel tools or content blocks. We've seen this take multi-second gaps down to a few hundred milliseconds, and the Claude Agent S D K does it by default.

92
00:16:39.912 --> 00:16:44.776
You should prompt the model to emit its slowest call first for maximum latency gains.

93
00:16:45.576 --> 00:16:46.770
Perceived latency.

94
00:16:47.220 --> 00:17:02.521
Perceived latency is the time a user feels until the screen does something. It’s especially critical in consumer-facing use cases where any transaction friction impacts checkout rates and revenue. Two techniques shorten it without touching the model:

95
00:17:02.971 --> 00:17:20.987
Stream components as they form. A rendered commerce response is typically 500 to 700 output tokens, which without streaming is five or more seconds of a spinner. Send each parameter of a presentation tool to the client as it streams and render the page progressively.

96
00:17:21.227 --> 00:17:42.090
Show the work. While the agent is gathering context, render a short progress line for each step in plain language (for example, "finding hotels near the water"). You can build it from the tool's existing arguments (such as the query for a product search), or add an additional user facing message parameter tool that prompts the model to write the line.

97
00:17:42.540 --> 00:17:54.409
Figure 1: The two panels above run the same agent with the same tools and prompt; only the harness differs. Total time is about the same, but the time the user sees something is quite different.

98
00:17:55.209 --> 00:17:56.130
Prompt caching.

99
00:17:56.580 --> 00:18:13.924
Prompt caching is your largest cost reduction candidate and commerce traffic is well-suited for it. Cached input token reads cost a tenth of fresh ones, and while cache-writes carry a premium of roughly 1.25 x, a cached prefix pays for itself on its second use.

100
00:18:14.044 --> 00:18:24.488
In customer facing applications where volume is large, you have a unique opportunity to hit very high cache levels using the cheapest, default 5 minute cache expiration.

101
00:18:24.938 --> 00:18:45.294
The best commerce deployments we've seen run at 90 to 99 percent cache hit rates, and that is the range to design for from the start. Our experience has shown cached token reads are also around 1.5 to 2 x faster at about 100 thousand tokens, with relatively linear scaling the more tokens there are.

102
00:18:45.744 --> 00:19:01.843
Caching is prefix-based. A request reads from cache up to the first byte that differs from a previous request, so what matters is not just what is in the context but the order it is in. Think of a request as three segments, ordered by how often they change:

103
00:19:02.293 --> 00:19:17.406
Global: most of the system prompt and tool definitions, identical across every session. This is your warmest cache and, at scale, will likely not expire. Keep it byte-identical across turns and sessions and put a cache breakpoint at its end.

104
00:19:17.646 --> 00:19:26.937
Session: per-user context and conversation history, which differ across sessions but stay stable within one. This segment comes after the global one.

105
00:19:27.177 --> 00:19:46.315
Volatile: anything that changes within a session, such as the current time or the current page. Put it at the very end of the request, either as a tagged block in the newest user turn or, on models that support mid-conversation system messages, as a system-role message appended to the messages array.

106
00:19:46.435 --> 00:19:55.417
The most common mistake we see is a timestamp or the current page at the top of the system prompt, which silently breaks the cache on every request.

107
00:19:55.867 --> 00:20:09.225
There are two implementation details to remember here. First, skills should be loaded as tool results rather than appended to the system prompt. The skill body then lands in the conversation prefix and is cached along with it.

108
00:20:09.675 --> 00:20:26.144
Second, roll your breakpoints forward in each turn: a request allows a limited number of breakpoints, so move the newest one to the end of each user turn. Each round then reads the accumulated history, including long tool results such as search responses, from cache.

109
00:20:26.944 --> 00:20:29.287
Choosing the model and its configuration.

110
00:20:29.737 --> 00:20:38.057
Model size and the effort setting are the same tradeoff to intelligence against latency and cost to and you should choose both by measurement:

111
00:20:38.507 --> 00:20:53.227
1. Pick your metric and your floor. Pick the quality metrics your business runs on (task completion, answer relevance, grounded accuracy), the eval score you won't go below, and your p50 and p99 latency and cost budgets.

112
00:20:53.467 --> 00:21:14.564
2. Sweep. Run your entire eval suite across every model and effort level you'd consider. We recommend starting at Opus for merchant agents, whose tasks are analysis-heavy, and Sonnet for consumer agents, where latency weighs more. If you have production traffic, weigh the results by your real query mix. Then let the numbers decide.

113
00:21:14.684 --> 00:21:22.078
Sometimes Opus 5's lift on cart-driving tasks justifies the cost difference over Sonnet, and sometimes it doesn't..

114
00:21:22.318 --> 00:21:44.925
3. Read the results carefully. Two things regularly surprise teams. The first is that a prompt is tuned to a model, so a sweep run with one prompt may underperform other models that it wasn't written for. A smaller model usually needs instructions the current model infers on its own, and a larger one will follow instructions to the letter that the smaller one was ignoring.

115
00:21:45.045 --> 00:22:07.181
A few rounds of iteration on each candidate's failing cases is a cheap step before ruling any of them out. The second is that a more intelligent configuration sometimes wins on latency (most commonly on p90 and p99) despite slower tokens, because it plans its tool calls better and needs fewer rounds on the most complex requests.

116
00:22:07.631 --> 00:22:29.913
Measure cost per completed task rather than per model call, since a cheaper model that needs more turns, or fails more often, is not cheaper. When the result is close, and the cost fits your per-task economics and latency, choose intelligence. Quality is what drives adoption and retention, and allows for room to build for the next 6 months as models become better.

117
00:22:30.363 --> 00:22:31.229
03

118
00:22:32.029 --> 00:22:33.388
Running it in production.

119
00:22:33.838 --> 00:22:41.555
Memory, safety, evals, and scaling the work across an organization: what gets an agent through production and keeps it there.

120
00:22:42.005 --> 00:22:50.200
Lastly, we talk about what gets an agent through production: memory, safety, evals, and scaling the work across an organization.

121
00:22:51.000 --> 00:22:52.765
Memory that survives the session.

122
00:22:53.215 --> 00:23:13.959
The relationship and interactions you have with your customers matter. Memory is what lets an agent pick up where the last conversation left off instead of starting from nothing. A shopper who mentioned a nut allergy in March shouldn't have to repeat it in June, and a merchant who checks the same three campaigns every Monday shouldn't have to name them each time.

123
00:23:14.079 --> 00:23:23.999
Long-term memory, the facts that should survive across sessions, is a system you build and it has three parts: how facts are stored, how they are written, and how they are read.

124
00:23:24.799 --> 00:23:25.850
Storing memories.

125
00:23:26.300 --> 00:23:29.080
Memory belongs in your systems, not in the model.

126
00:23:29.530 --> 00:23:51.843
A flat markdown profile works when profiles are small and the agent is the only reader. Most production commerce agents outgrow it, and the practical replacement is the database you already operate. A fact is a small typed record: a key (such as shoe size, default store, preferred report cadence), a short value, a category, and the session it came from.

127
00:23:51.963 --> 00:24:07.110
Some keys you decide up front and every user gets; the rest the extractor discovers. A database stays queryable as the store grows, lets you build deterministic behavior on specific attributes, and joins to the user data you already have.

128
00:24:07.560 --> 00:24:26.030
For merchant-facing agents, key memory by person rather than by account. Merchant logins are often shared between operators, so each operator needs their own profile, and reads have to respect that operator's permissions: a store manager's agent should not recall a fact a district manager stated.

129
00:24:26.480 --> 00:24:43.995
In the commerce domain, agent memory holds personal data. The facts worth remembering are often the most regulated ones, and the rules between jurisdictions differ. Treat memory as a data-handling design problem and not just a storage one. In practice that means four things:

130
00:24:44.445 --> 00:24:53.713
Decide which types of memories you are willing to hold. Enforce that at the write path, with a validator that every save goes through, rather than in the prompt alone.

131
00:24:53.953 --> 00:25:01.517
Give users a way to see, correct, and delete what is stored. Wire deletion into your account-deletion and data-request flows.

132
00:25:01.757 --> 00:25:09.862
Set a retention period. A preference from a few years ago is likely to be outdated, so a retention period helps keep memory facts fresh.

133
00:25:10.102 --> 00:25:16.764
Memory should be a per-deployment switch. This allows regions that can't take on these obligations to run without it.

134
00:25:17.564 --> 00:25:18.531
Writing memory.

135
00:25:18.981 --> 00:25:35.469
Write memory asynchronously. At the end of each turn, or every few turns in a long session, an agent in a separate thread or process reads the conversation and creates, updates, or deletes facts in the store, keeping its own working context as the session goes on.

136
00:25:35.919 --> 00:25:44.559
It adds nothing to the conversation's latency, and achieved 13 percent higher fact recall on our internal commerce memory eval suite.

137
00:25:45.009 --> 00:26:03.999
The obvious alternative, a tool the agent calls to save a fact, is the wrong one for a latency-sensitive commerce agent. Every save is a tool call inside a user-facing turn, and unless the whole store is in context, a save needs a read first to update or dedupe, which is a round of its own.

138
00:26:04.449 --> 00:26:13.230
It also puts one more decision in front of the agent on every turn, and in our evals that competition for attention showed up as missed memories.

139
00:26:13.680 --> 00:26:26.287
Separating the extractor also lets you prompt it precisely. It reads only the user's and the assistant's text, never tool results, so a product description or a review can't become a fact about the user.

140
00:26:26.407 --> 00:26:39.676
Its prompt says what counts as a fact, a stated size, a dietary constraint, a fulfillment preference, a merchant’s usual materialized views, and what doesn't, such as anything from a listing or a one-off detail.

141
00:26:40.476 --> 00:26:41.381
Reading memory.

142
00:26:41.831 --> 00:26:43.595
Read memory in three layers.

143
00:26:44.045 --> 00:26:57.168
Always in context A small fixed set of facts goes into context on every turn: the ones nearly every request depends on, such as a shopper's default store and fulfillment preference, or an operator's store and role.

144
00:26:57.288 --> 00:27:15.113
Pre-fetched per turn Facts relevant to the current request are pre-fetched per turn from the same signals that pre-load a skill: a shoe search pulls sizes and brand preferences, a campaign question pulls the operator's usual metrics. Behind a lookup tool Everything else sits behind a lookup tool.

145
00:27:15.563 --> 00:27:21.897
Since memory is per-user context, all of it goes in the session segment, below the global cache breakpoint.

146
00:27:22.697 --> 00:27:25.150
Safety: enforcement lives in the harness.

147
00:27:25.600 --> 00:27:47.463
The prompt is where safe behavior starts, but in commerce it can't be where safety is enforced. The failures are financial and often irreversible, and a prompt rule is one injection or one bad sample away from being skipped. Every rule below is enforced in code, on both the consumer and the merchant agent, and defined once so every runtime shares it.

148
00:27:48.263 --> 00:27:51.463
The model stages; a person or a policy applies.

149
00:27:51.913 --> 00:28:04.214
No model tool call moves money or changes the business. Order placement, payments, refunds, price changes, and campaign launches all end in an action the harness controls instead of the model.

150
00:28:04.664 --> 00:28:15.162
On the consumer side this is structural: the checkout tool renders the cart with a button to place the order, and the backend interface the agent calls has no charge method at all.

151
00:28:15.612 --> 00:28:36.474
On the merchant side, every write tool produces a staged change with a server-generated I D, and apply change succeeds only for I Ds that have been approved through a real surface: a button in the operator's portal, a confirmation in the C L I, or the platform's own tool-approval prompt when the agent runs on Managed Agents.

152
00:28:36.924 --> 00:28:55.492
The guardrails are re-checked at apply time against current limits, not the limits in force when the change was staged. Whatever the surface, the shape is the same: the model's most dangerous action is to propose, and the approval routes through the maker-checker flow your business already uses for that kind of change.

153
00:28:56.292 --> 00:28:59.727
Writes and renders accept only server-issued I Ds.

154
00:29:00.177 --> 00:29:08.923
The harness keeps a per-session record of every I D the server has handed the model, and that record is the only key any write or render will accept.

155
00:29:09.373 --> 00:29:28.445
The cart accepts only product I Ds the server returned to this session, and the merchant tools accept only listing and campaign I Ds the agent has actually read. An I D that arrived any other way, hallucinated, pasted by a user, planted in a review, is refused before the backend sees it.

156
00:29:28.895 --> 00:29:41.530
The same rule covers the U I. Presentation tools take I Ds, and the server fills in the product, order, or change records itself, so a card only renders records the server itself filled in.

157
00:29:41.980 --> 00:29:50.243
It covers delegates too: the merchant analysis subagent reads data but never adds to the set of I Ds the agent may write to.

158
00:29:50.693 --> 00:30:10.752
For fees, disclosures, and other regulated content, the model chooses which product to disclose and the server supplies every word from approved copy. The same fee fields are on the merchant agent's protected list, so neither side of the counter can change or paraphrase them, and evals check the rendered strings byte for byte.

159
00:30:11.552 --> 00:30:14.685
Capped transactions must hold to repeated requests.

160
00:30:15.135 --> 00:30:29.373
Most commerce surfaces cap how many of an item one user can buy, for ticket allocations, promotional pricing, or fraud control, and an agent will retry, rephrase, and parallelize in ways a human clicking a button never did.

161
00:30:29.823 --> 00:30:44.421
The cap is therefore enforced on the line as it would be after the write, so a second "add two more" can't stack past it, and cart writes for one session are serialized so parallel tool calls in a single turn can't combine to exceed it.

162
00:30:44.871 --> 00:31:04.069
Merchant changes are checked the same way against caps on price movement, discount depth, restock size, and campaign budget, plus a list of protected fields no change may touch. The rule generalizes: enforce every limit on the resulting state rather than the request, and serialize writes per session.

163
00:31:04.869 --> 00:31:07.067
Third-party content is sanitized.

164
00:31:07.517 --> 00:31:18.747
In commerce most of the context is written by people who aren't you, sellers, reviewers, competitors, so every backend read is untrusted input and goes through one sanitizer.

165
00:31:19.197 --> 00:31:31.732
Every tool result authored by a third party, such as listings, reviews, policies, seller messages, and stored memory, is sanitized and wrapped in a fence with a fixed label before the model sees it.

166
00:31:32.182 --> 00:31:50.080
The sanitizer strips control and bidirectional characters, removes anything that imitates the fence markers, defuses text that imitates a conversation turn or a tool call, and caps the size, which is designed to stop a hostile listing from impersonating the system or filling the context.

167
00:31:50.530 --> 00:31:56.818
The prompt carries the other half of the contract: fenced text is material to report on, never to act on.

168
00:31:57.618 --> 00:32:00.274
Evals: shipping a non-deterministic system.

169
00:32:00.724 --> 00:32:21.818
Anything from a small prompt change to a new tool can change agent behavior in ways that are hard to predict, and the change you're shipping is often not the one that regresses. Evals are how you find that out before you deploy. Our earlier blog post on evals for agents covers the general practice. This section covers specifics for commerce agents.

170
00:32:22.268 --> 00:32:24.743
Evaluate snapshots, not conversations

171
00:32:25.193 --> 00:32:45.735
The model’s A P I is stateless, so what the agent outputs is a function of the system prompt, the tools, and the messages array. This means any state a commerce conversation can reach can be constructed directly. So creating an eval case means constructing the test state, appending the test user message, and letting the agent run from there.

172
00:32:46.185 --> 00:33:00.448
Then grade the outcome: the final state and the rendered response, including the arguments of the last write. In most cases, we recommend against grading the path the agent took to get there as such test cases are brittle and restricting.

173
00:33:00.898 --> 00:33:18.897
Simulated-user evals, in which a second model plays the user and a judge grades the whole conversation, are a poor tool for measurement. Two non-deterministic systems interacting need larger samples, cost more per trial, are harder to judge, and produce failures that are hard to attribute.

174
00:33:19.017 --> 00:33:28.303
They are useful for finding coverage gaps and for a general vibe check on the agent, so use them to discover cases, then write each case as a snapshot.

175
00:33:29.103 --> 00:33:31.565
Evaluate for behaviors in tough conditions.

176
00:33:32.015 --> 00:33:53.315
Most teams fail to properly test the injected state. A case should encode the preconditions of a failure, not just the task. If a behavior only emerges after a busy first turn with several tool calls, or after a contradiction earlier in the session, a case that starts from a clean state passes on every config and provides no meaningful data.

177
00:33:53.765 --> 00:34:02.716
We've observed most suites to be heavy on such clean-state cases, so make sure a share of yours starts from long, messy, or contradictory histories.

178
00:34:03.516 --> 00:34:06.182
Cover the different types of commerce agent evals.

179
00:34:06.632 --> 00:34:11.880
Effective evaluation requires testing both desired and undesired behaviors.

180
00:34:12.330 --> 00:34:24.663
For every positive case, write its negative counterpart: a "should serve" for every "should refuse," a "should just do it" for every "should ask." Missing negatives are the most common gap we find in a suite.

181
00:34:25.113 --> 00:34:26.519
Evaluate for the following:

182
00:34:26.969 --> 00:34:49.571
Core requests that make up the bulk of your traffic, since a failure here affects most sessions. These include simple lookups, multi-constraint requests, product and plan questions, and multi-intent messages. For the questions, check that every price, availability, and attribute traces back to returned data, and that the agent says when data is missing rather than inventing it.

183
00:34:49.811 --> 00:35:06.973
Context-dependent requests, such as references to what is on screen, constraints carried over from earlier turns, and writes against an existing cart. Evaluating memory falls into this bucket as well. Check that memories were extracted, retrieved, and changed the answer.

184
00:35:07.213 --> 00:35:19.394
Safety and brand cases, where a failure costs money or trust. These include attempted injection, attempts to read another user's data, and regulated language, which is checked byte for byte.

185
00:35:19.514 --> 00:35:34.169
Split injection into two cases: user-authored injection, where the directive comes from the user's own message, and data-plane injection, where it is planted in product names, reviews, or web snippets that arrive via tool results.

186
00:35:34.409 --> 00:35:47.186
Interface evaluations, to ensure the right component is rendered, item caps are respected, and there are no internal identifiers in user-facing text. Test for timeouts and empty results too.

187
00:35:47.426 --> 00:36:07.868
Requests that belong to multiple capabilities at once. An operator asks "if I mark this down 15 percent, do I have enough stock to cover the demand?" That is a pricing question and an inventory question together. The right answer stages the markdown with a stock projection attached; the wrong answers do one and skip the other.

188
00:36:07.988 --> 00:36:19.674
Evals written per capability won't catch this, because each grades only its own half. Write cases for the requests that need two neighboring capabilities together, and grade both halves of the answer.

189
00:36:20.474 --> 00:36:23.645
Write evals with SMEs and use real incidents.

190
00:36:24.095 --> 00:36:42.978
Partner with the subject-matter experts who see the failures firsthand, such as team members in Product, Legal, Merchant Ops, Customer Care, and Category Management, to design test cases. Real failures make the best evals, and 50 to 100 eval cases per user flow is a good starting point.

191
00:36:43.428 --> 00:37:05.060
Make sure to have a variety of cases, as outlined above. Production transcripts are a great stream for sourcing new cases, especially the tricky ones. Coding agents are good at generating additional cases and adversarial variants. The reference repository includes a Claude Code plugin with an eval-authoring skill built with our recommended approach.

192
00:37:05.860 --> 00:37:07.797
Shipping with a large organization.

193
00:37:08.247 --> 00:37:26.764
In a commerce enterprise the agent is built by many engineering teams. Search, checkout, pricing, marketing tech, customer care, and the catalog platform each own systems the agent depends on, each ships on its own cadence, and each will want to add or change a tool, a skill, or a prompt rule.

194
00:37:27.214 --> 00:37:36.722
Unlike a service, an agent has no strict module boundary protecting the others: a change made by the pricing team shares a context window with checkout.

195
00:37:37.172 --> 00:37:52.068
The tempting fix is to break the system into many subagents, one per business unit. As discussed in Part 1, we recommend against it for quality reasons. Instead, we outline the process for de-risking multi-team collaboration:

196
00:37:52.518 --> 00:38:12.914
Ownership follows the systems. Every skill and tool has a single owner team. For example, pricing owns the promotion tools and the pricing skill, care owns the order and returns tools and the customer-care skill. The shared prompt has a single platform-level owner for the common parts and domain owner for the domain-specific section.

197
00:38:13.154 --> 00:38:34.604
A change ships with its cases and CI runs a set chosen for it. A team contributing a skill also contributes its cases, including the negative cases and the boundary cases against neighboring skills. Running the full suite on every pull request is too slow and too expensive to survive, so build a CI set from it instead.

198
00:38:34.724 --> 00:38:56.629
That set will consist of a core set of cases with the highest-traffic requests and every safety case. On top of that, run the cases for whatever the change touched. For a skill, that means its own cases and its neighbors' boundary cases. For a tool, it is every case that calls it. For the shared prompt, it is the full eval suite since everything reads the system prompt.

199
00:38:56.749 --> 00:39:10.274
We recommend gating the pass rate over a few trials, and on cache hit rate and cost per turn. It is also a good practice to run the full suite nightly and before every release. Cross-team regressions are caught in these runs.

200
00:39:10.514 --> 00:39:29.878
The agent should also be inside the release calendar. It's one deployment unit, so a bad change reaches every user at once. Roll prompt and skill changes to a canary cohort first, keep a switch that turns off one skill without a deploy, and freeze the agent ahead of peak periods the same way you freeze other systems.

201
00:39:30.328 --> 00:39:34.825
For the human side of this arrangement, see Building effective human-agent teams.

202
00:39:35.625 --> 00:39:36.502
Looking ahead.

203
00:39:36.952 --> 00:39:53.677
Most of what this post describes is not about the model. The tools call systems you already run, the skills encode procedures you already follow, the evals are your product requirements doc written as tests, and the harness enforces policy you would enforce for any client.

204
00:39:53.797 --> 00:40:03.489
Models will keep improving, and when a better one ships, the architecture we describe adopts it as a config change with an eval sweep. Everything else keeps working.

205
00:40:03.939 --> 00:40:22.627
It is also important to think about your roadmap for product surfaces. The architecture will outlast the chat panel. The same agent can work over voice, and it can proactively act on a fare drop before the user asks. For a team that already has the evals and the tools, those are presentation-layer projects.

206
00:40:22.747 --> 00:40:37.041
Further out, some of the traffic to your storefront will come from agents that shop on behalf of users. The same provenance, staging, and approval rules that keep your own agent in bounds are what will let you open your tools to those agents safely.

207
00:40:37.491 --> 00:40:54.956
Commerce has always rewarded making the buying process as smooth as possible. Agents make that a lot easier. Check out the complete reference implementation, with both the consumer and the merchant agent and runnable examples for retail, travel, telecom, and entertainment.

208
00:40:55.756 --> 00:40:56.733
Acknowledgements.

209
00:40:57.183 --> 00:41:09.034
Written by Matthew Koen and Ali Shazal. Special thanks to Michael Segner, Rodrigo Olivares, Amandeep Khurana, Aiza Usman, John Lopus and others for their contributions.

210
00:41:10.034 --> 00:41:27.072
That was A guide to the anatomy of effective commerce agents, from Claude Blog, published September 2, 2026. Read the original at claude dot com. This unofficial audio edition was generated automatically for the podcast Anthropic, Read Aloud.