For most of the past two years, the deal a foundation lab offered builders was simple: here is a raw model and an API, now go assemble everything else yourself. On September 2, 2026, Anthropic changed the shape of that deal for one vertical. It open-sourced Claude Commerce Agents, a forkable blueprint for building shopping and merchant agents on the Claude Agent SDK. You no longer start from a blank editor and a token; you start from a working reference implementation that already handles catalog search, cart assembly, customer care, and back-office analytics. This is the fork-a-vertical-agent pattern, and it is worth understanding as a trend, not just a product release.
Background
Agentic commerce has been the most-hyped and least-shipped corner of applied AI. The demos are irresistible: a shopper describes a vague intent, the agent searches a catalog, compares options, assembles a cart, and answers return questions in one conversation. The reality has been harder. Building that agent well means writing planning skills for multi-item requests, wiring tool contracts to a real storefront and checkout system, adding guardrails so the agent does not confidently promise things it cannot deliver, and building an evaluation harness to prove the agent actually helps rather than annoys. Each of those is a project on its own, and most teams underinvest in the last two because they are invisible until something breaks in production.
Anthropic's release is the first time the company has published a full, forkable agent stack for a specific domain rather than raw API documentation. The repository at github.com/anthropics/commerce-agents ships two agents. A shopping agent searches the catalog, compares products, builds carts, and handles order and return questions. A separate merchant agent tracks inventory, recommends pricing and promotions, and drafts marketing campaigns, with every proactive action gated behind human approval. Around those agents, the blueprint bundles the tedious infrastructure: skills, tool contracts, safety guardrails, evaluation harnesses, reference implementations for retail, travel, telecom, and ticketing, and a Claude Code plugin for editing the whole thing from your editor.
Deep Analysis
What is in the blueprint: skills, tool contracts, guardrails, evals
The value of the release is not the model call. Anyone with an API key can prompt Claude to talk about products. The value is the four layers that surround the model call, each of which is the part builders usually get wrong.
Skills are the reusable reasoning routines: multi-item planning, personalization, comparison logic, and the conversational patterns that turn a vague shopper intent into a concrete cart. These encode the "how a good salesperson thinks" layer that is easy to sketch and hard to make reliable. Tool contracts define the interface between the agent and your systems: the shapes of a catalog search call, an add-to-cart action, an order-status lookup, a checkout handoff. The blueprint ships sample contracts you replace with your own storefront and checkout APIs, which means the hard architectural decision of "what can the agent actually do" is already made and documented. Guardrails keep the agent inside safe behavior, and critically, the merchant agent gates every proactive action behind human approval rather than letting it autonomously change prices or push campaigns. Evaluation harnesses are the layer almost nobody builds themselves: a test rig that scores whether the agent handled a multi-item request well, so you can measure regressions before shipping instead of discovering them from angry customers.
Anthropic's companion breakdown on the anatomy of effective commerce agents sets a concrete bar for that evaluation work. It reports carts up to 35 percent larger and shoppers 60 percent more likely to complete a purchase when a Claude shopping agent is in the loop. Whether or not you hit those numbers, they give the eval harness a target: an agent that does not move cart size or conversion is not earning its place, and now you have the tooling to know that before launch.
Fork to shipped agent: the builder path
The workflow the blueprint enables is deliberately short. Here is the path from clone to a testable shopping agent:
- Fork the closest reference. Clone the repository and pick the reference implementation nearest your domain: retail, travel, telecom, or ticketing. Starting from the closest vertical means the planning skills and conversation patterns already assume the right shape of problem.
- Wire your catalog. Point the shopping agent at your real product catalog so search and comparison run against your inventory instead of the sample data.
- Swap the tool contracts. Replace the sample storefront and checkout contracts with your own APIs. This is where the agent stops being a demo and starts touching your commerce systems, and the contract shapes are already defined for you to fill in.
- Customize in Claude Code. The kit ships a Claude Code plugin so you adjust agent behavior, prompts, and skills directly from your editor. You are editing an opinionated scaffold, not rebuilding it, which keeps the changes small and reviewable.
- Run the eval harness. Step the retail (or chosen) agent through the evaluation harness against a test catalog to see how it scores multi-item requests. This is the checkpoint that tells you whether your changes helped or regressed the agent before any customer sees it.
- Choose a runtime. The agents run on the Messages API, the Claude Agent SDK, or the new Claude Managed Agents beta, so you can self-host or move to managed hosting without rewriting the agent.
The point of this sequence is that the invisible-but-critical work, the guardrails and the eval rig, comes pre-built. A team that would have spent weeks assembling scaffolding spends that time on the parts that are actually specific to their business: their catalog, their checkout, their brand voice.
Open blueprint vs raw SDK vs closed platform
The interesting question is not whether the blueprint is good in isolation but how it compares to the two alternatives builders were already choosing between: writing an agent from scratch on the raw SDK, or buying into a closed vertical-agent platform. The tradeoffs sort cleanly across four axes.
| Axis | Open blueprint (Commerce Agents) | Raw SDK from scratch | Closed vertical platform |
|---|---|---|---|
| Time to ship | Fast: fork a working reference, swap catalog and contracts, run evals | Slow: build skills, guardrails, and eval harness yourself before shipping | Fast: configure and go, but limited to what the platform exposes |
| Portability | High: runs on Messages API, Agent SDK, or Managed Agents beta; you own the code | High: you own all of it, but you also maintain all of it | Low: agent logic lives inside the vendor's runtime and data model |
| Eval tooling | Included: evaluation harnesses ship with the blueprint | None by default: you build measurement yourself or fly blind | Vendor-defined: metrics exist but you cannot inspect or extend the harness |
| Lock-in | Low: open to fork, optional managed hosting, standard SDK underneath | Lowest: no external dependency beyond the model API | High: pricing, roadmap, and data all controlled by the platform |
The blueprint occupies a deliberate middle. It buys back most of the time-to-ship advantage of a closed platform while keeping the portability and low lock-in of building on the raw SDK. The one thing raw-from-scratch still wins is absolute minimalism of dependencies, but that "win" is mostly the freedom to re-solve problems Anthropic already solved and tested. For a commerce team, the eval-tooling row is the quiet decider: shipping an agent you cannot measure is how these projects die in production, and only the blueprint hands you that instrumentation on day one.
Why labs are shipping vertical scaffolds
Step back and the release reads as a strategy shift, not a one-off. Labs are starting to ship opinionated open vertical scaffolds instead of only raw SDKs, and the logic is straightforward. A raw SDK converts a small number of sophisticated teams into production users; a forkable, tested, domain-specific blueprint converts a much larger number of teams because it removes the exact steps where they stall. The same skills-and-tools pattern powers Anthropic's broader agent stack, so the commerce release is really a proof that the stack can be packaged into a vertical and handed over intact.
There is a distribution motive too. Every forked blueprint is a team building on the Agent SDK, defaulting to the model that ships with the reference, and one sales conversation away from managed hosting when they want to stop operating it themselves. Open-sourcing the scaffold is not charity; it is a funnel where the free tier is a genuinely useful, forkable product and the upsell is operations. For builders that alignment is unusually favorable, because the free artifact is complete enough to ship without ever talking to sales.
Impact on Creators
For the creators and builders who make things on top of these tools, the practical effect is that "build a commerce agent" moves from a multi-week engineering project to a multi-day integration project. If you run a storefront, a booking service, a ticketing site, or any catalog-shaped business, the closest reference implementation is a head start you did not have last week. The tedious, high-stakes work of guardrails and evaluation is done to a standard set by the lab that built the model, which raises the floor for everyone who forks it.
It also reshapes what a small team can credibly attempt. A solo builder or a two-person shop can now stand up a shopping agent that searches a catalog, builds carts, and handles returns, then measure it against the same 35-percent-larger-cart and 60-percent-higher-conversion targets Anthropic reports, without hiring an agent-infrastructure specialist. The Claude Code plugin means the customization happens in the editor you already use, so the loop from idea to tested change stays tight. The competitive pressure cuts the other way as well: if the barrier to a competent commerce agent just dropped, having one stops being a differentiator and not having one starts being a gap.
Key Takeaways
- Anthropic open-sourced Claude Commerce Agents on September 2, 2026, a forkable blueprint for shopping and merchant agents built on the Claude Agent SDK.
- The blueprint ships the parts builders usually get wrong: skills, tool contracts, safety guardrails, evaluation harnesses, and reference implementations for retail, travel, telecom, and ticketing.
- The builder path is short: fork the closest reference, wire your catalog, swap the checkout and storefront tool contracts, customize in Claude Code, and run the eval harness before shipping.
- Versus a raw SDK build it saves the scaffolding and eval work; versus a closed platform it keeps portability and low lock-in. The included eval tooling is the quiet differentiator.
- Anthropic cites carts up to 35 percent larger and shoppers 60 percent more likely to complete a purchase with a Claude shopping agent in the loop, giving the eval harness a concrete target.
- The release signals a broader trend: labs shipping opinionated open vertical scaffolds, not just raw SDKs, as a distribution and adoption strategy.
What to Watch
The signal to track is whether other labs follow with their own forkable vertical scaffolds, and which verticals get scaffolded next. Commerce is a natural first target because the payoff is measurable in cart size and conversion, but the same pattern maps onto support, scheduling, logistics, and any domain where an agent needs skills, tool contracts, guardrails, and a way to prove it works. If the fork-a-vertical-agent pattern spreads, the competitive question for builders stops being "can you build an agent" and becomes "what did you do with the day you saved by forking one." Watch, too, how the managed-hosting upsell evolves against the open fork: the healthiest version of this trend is one where the free blueprint stays complete enough to ship on its own, and the paid tier competes on operations rather than by holding features hostage.
