Build a Shopping Agent: Fork Claude Commerce 2026

The founder's guide to building an AI shopping agent product by forking Anthropic's open blueprint, and wiring in the wallet, the distribution, and the guardrails it deliberately leaves out.

On September 2, 2026, Anthropic open-sourced a working shopping agent and merchant agent under an Apache-2.0 license, and within about two weeks the repo had roughly 580 forks - GitHub. That number is the whole story in miniature. A frontier lab shipped the reasoning layer of a store as free, readable code, and hundreds of teams immediately started copying it into their own products.

But here is the catch that almost every headline buried: the blueprint has no wallet. It will search a catalog, compare products, build a cart, answer a returns question, and hand a merchant a drafted price change to approve. It will not charge a card, place an order, or manage your catalog. Anthropic built the shopping brain and skipped the transaction on purpose - PYMNTS. A blueprint is not a business. Turning that fork into a store your customers can actually buy from is where the real work, and the real opportunity, begins.

This guide is the practical, end-to-end path from git clone to a shipped shopping agent. It covers exactly what the blueprint gives you and what it withholds, the fastest way to fork and customize it, the agentic payment rails you must bolt on (ACP, AP2, Visa, Mastercard, x402), the model and cost economics that make this cheap in late 2026, how to get your agent and your products discovered inside ChatGPT, Perplexity and Google, the security gates that keep a money-touching agent from being weaponized, and an honest scoring of every competing way to build the same thing. It targets the non-technical founder who can read a command but wants the reasoning, not just the recipe.

Contents

1. What Anthropic actually shipped (and what it left out)
2. Why a fork beats a framework
3. The two agents, up close
4. Fork it in an afternoon: the build path
5. The missing wallet: bolting on agentic payments
6. The 2026 substrate that makes this cheap
7. Distribution: getting your agent (and products) found
8. The competitive map: every other way to build
9. Safety, trust, and the law
10. Market reality: adoption, conversion, and where agents fail
11. The 2027 outlook: what to build now
12. Conclusion: a decision framework

Before the detail, here is the whole decision space in one view. The table below scores the realistic ways to put an AI shopping agent in front of customers in late 2026, from forking Anthropic's blueprint to plugging into a demand surface to describing your store to an autonomous builder. Each option is scored 0 to 10 on five things a founder actually cares about, weighted by how much they matter, with the real evidence inside each cell. The score is a weighted average, and the table is sorted by it, highest first.

The five criteria, and why each is weighted as it is. Ship speed (25%) carries the most weight because time to a working, revenue-capable agent is the scarcest resource a small team has. Ownership (20%) measures how much of the code, the UX, the data, and the model choice you actually control versus rent. Payments built-in (20%) is scored high because the wallet is precisely where the effort hides: an option that solves checkout end-to-end saves weeks. Run cost (15%) captures ongoing token plus platform plus transaction fees, not the sticker price of getting started. Reach (20%) rewards built-in access to shoppers or shopping agents, the difference between a store nobody visits and one that shows up where people already buy.

Two things in that table deserve to be flagged now, because they run against the grain. First, forking Anthropic's blueprint, the subject of this guide, lands at 6.2, mid-pack. That is not a knock on the code. It is the honest math of a foundation versus a finished product: the fork wins outright on ownership and cost and loses hard on the two axes it never claimed, payments and distribution. Second, our own product, Founden, lands at 6.7, also mid-pack, scored by the same evidence as everything else. The rest of this guide explains the reasoning behind every one of those cells, and why the "low" score for the fork is exactly why the fork is interesting.

1. What Anthropic actually shipped (and what it left out)

To reason about forking Claude Commerce Agents, you first have to be precise about what the release is, because the press coverage blurred it. It is not a hosted product, not a checkout, not a marketplace, and not a protocol. It is a reference blueprint: a public GitHub repository, anthropics/commerce-agents, containing two working agents, four runnable example verticals, a shared safety harness, and a Claude Code plugin, all under an Apache-2.0 license - Anthropic. The README states the boundary in one sentence: "This is a reference implementation; it is not maintained and does not accept contributions" - GitHub. You are meant to copy it, not depend on it.

That framing matters because it changes what "using" the release means. There is no SDK to pip install and track, no versioned dependency, no Anthropic-hosted endpoint you call. The intended workflow is a fork: you clone the repo, keep the parts you want, replace the fake ACME data with your real systems, and own the result forever. Anthropic is not selling you commerce software. It is giving away the hardest-to-design part of a commerce agent (the prompt scaffolding, the tool contracts, the guardrail placement) so that building one on Claude becomes a weekend instead of a quarter. Anthropic reports that engineers using the accompanying plugin had working agents within about fifteen minutes, and that one partner, Fetch, had both agents running locally in under an hour - Anthropic.

What you get in the box is genuinely substantial. The repo ships a customer-facing shopping agent and a staff-facing merchant agent, each defined once and runnable on three different runtimes, plus four fully built example verticals so you can see the pattern applied rather than described.

• Retail (ACME): search, comparison, plans, cart, checkout handoff, and customer memory
• Travel (ACME Travel): date-bound inventory and itinerary extension
• Telecom (ACME Mobile): account context, a plan matrix, and protected regulated fees
• Entertainment (ACME Tickets): timed holds, waitlists, transfers, and all-in fee display

Those four verticals are not decoration. They are the proof that the same agent skeleton flexes across very different commerce shapes, which is exactly the question a founder in an unusual niche needs answered before committing. A ticketing store and a phone-plan store have almost nothing in common operationally, yet both are expressed as the same agent with different backend methods and skill files. Every company, product, and person in the examples is fictional, with ACME as the only "brand," so nothing in the repo leaks a real integration you would have to strip out - GitHub.

Now the part that reframes the whole exercise: what Anthropic pointedly left out. The blueprint excludes payment processing, checkout, catalog management, and advertising entirely. Nothing in the reference implementation places an order, charges a card, or changes a live listing. Checkout is a handoff: the agent renders a cart and passes a URL back to the host to complete, and that path deliberately bypasses the model - PYMNTS. This is the single most important design fact in the release, and section 5 is devoted to closing the gap. For now, understand the shape: Anthropic gave you the agent and kept the model as the toll booth, betting that if it owns the reasoning layer of commerce, it does not need to own the transaction. One analysis put the strategy bluntly: "the model becomes the toll booth, not the code" - Idukki.

The launch partner list tells you who else is placing chips on that bet. Anthropic named Shopify, Priceline, Visa, Mastercard, and Accenture among the anchor partners, with Intuit, Klaviyo, Wix, Zomato, Square, and Fetch appearing alongside - Anthropic. Priceline rebuilt its travel assistant, Penny, on Claude. The two card networks are there precisely because Anthropic skipped the wallet: Visa and Mastercard keep the payment, and the model keeps the conversation. That division of labor is the entire commercial logic of an Apache-2.0 give-away from a company that sells tokens.

2. Why a fork beats a framework

Step back from the specifics and ask the structural question, because it explains why 2026 produced a blueprint rather than a product, and why forking one is a rational default rather than a compromise. When a capability becomes cheap and well-understood, the industry stops shipping it as a locked box and starts shipping it as readable, copyable reference code. We saw this with authentication, with payments SDKs, with infrastructure-as-code. The commerce agent has now crossed that same line. The reasoning to run a store conversation is no longer a moat; it is a pattern worth publishing so that the layer underneath it (the model, in Anthropic's case) becomes the default. A fork is the natural consumption model for a pattern, the way a hosted API is the natural consumption model for a service.

The practical case for a fork over a framework or a platform comes down to three properties that matter more for a money-touching product than for almost anything else you build. Control, because you can read every line that decides whether the agent adds an item to a cart or approves a price change, and a commerce agent that you cannot fully audit is a liability the moment it touches a transaction. Portability, because the same code runs against the Claude API, Amazon Bedrock, Microsoft Foundry, or Google Vertex AI, so your infrastructure and procurement choices stay open - Anthropic. No lock-in decay, because a framework you depend on can deprecate an interface under you, whereas a fork is frozen at the commit you took and changes only when you change it. The "not maintained" label, which reads as a warning, is actually the guarantee: nothing upstream will move without your say-so.

A fork also has real costs, and pretending otherwise is how teams get burned. You inherit no security patches, no bug fixes, and no upstream improvements, so a vulnerability discovered next year is yours to find and fix. You own the integration surface completely, which is liberating until you realize how much of a production store lives in that surface. And you get none of the distribution or payments that a platform bundles in, which is exactly why the fork scored 6.2 in the table above while Shopify's bundled stack scored 7.7. The right way to read that gap is not "Shopify is better." It is "a fork trades bundled convenience for total control, and whether that trade is good depends on how much of your product is genuinely yours." For a differentiated store, a vertical with unusual rules, or a founder who intends to own the agent as a core asset, control wins. For a generic catalog that just needs to be buyable, a bundled platform wins. This is the same build-versus-buy calculus we walk through in detail for founders in building software with AI, applied to the agent layer specifically.

There is a deeper reason the fork is ascendant right now, and it is economic rather than technical. When the marginal cost of an autonomous build-and-ship cycle collapses, copying a high-quality reference and adapting it becomes cheaper than either building from scratch or configuring someone else's platform around your edge cases. The models got cheap enough, and the tooling autonomous enough, that "read this excellent example and make it yours" is now the fastest path to a defensible product. Section 6 quantifies that collapse. It is the tailwind under every fork in that 580-and-climbing count.

3. The two agents, up close

The blueprint is two agents, not one, and the distinction is the difference between the part of a store customers see and the part staff run. Understanding both is necessary even if you only intend to ship one, because they share a harness and because the merchant agent is where the genuinely novel safety design lives. Both are defined once, as a prompt plus five skill flows plus a set of tools, and both run unchanged across the three runtimes covered in section 4. Anthropic describes the architecture as deliberately flat: one agent loop, skills-first, with no intent router and no separate subagent per domain - MarkTechPost. That flatness is a feature: fewer moving parts to audit, and a single place to reason about behavior.

The shopping agent is the customer-facing one. It searches your catalog, compares options in the conversation, builds a multi-item cart, answers order-tracking and returns-policy questions, and remembers customer preferences across the session. It is the thing a shopper talks to. Crucially, it has no payment method at all: when the shopper is ready to buy, the agent renders the cart and produces a checkout handoff URL that the host completes, a path that bypasses the model entirely - GitHub. The screenshot below is the reference shopping agent running inside the fictional ACME retail storefront, doing conversational discovery and cart building.

The shopping agent's design has one lesson worth copying into any customer-facing agent you build, commerce or not. It never trusts model output to move state: cart writes are constrained to product IDs the catalog tools actually returned in the current session, and adds that name a product only by its options are held and redirected to concrete variants - GitHub. In plain terms, the agent cannot invent a product and put it in your cart. That is the same discipline we recommend for any grounded assistant in our guide to building a support agent, and the shopping agent is essentially a support agent with a cart attached and much higher stakes on getting the facts right.

The merchant agent is the staff-facing one, and it is the more interesting piece of engineering. It explains sales performance, maintains listings, flags inventory and order issues, recommends pricing and promotions, and drafts marketing campaigns. What it does not do is change anything live on its own. Every write it proposes is staged until a human approves it, and the approval is real, not theater: a preview card approves nothing, and an approval typed in chat sets nothing - GitHub. Approval has to come through an explicit route (a portal button, an SDK call, or the hosted platform's prompt), which means a compromised conversation cannot talk the agent into applying a change. The screenshot below shows the merchant agent's retail workspace, with analytics, inventory, and drafted changes waiting for human sign-off.

The reason both agents matter to a founder, even one who only wants a shopping agent, is that together they define the two halves of an autonomous store: the half that talks to customers and the half that runs the back office. Anthropic reports that retailers already running shopping agents on Claude have seen carts up to 35% larger and shoppers 60% more likely to complete a purchase - Anthropic. Treat those as vendor-reported figures, not audited results: no independent auditor produced them and no specific retailer is attached to the numbers. They are directionally useful (a well-built shopping agent lifts baskets and conversion) and worth exactly nothing as a guarantee. The honest version of the claim is that a good conversational shopping experience tends to sell more, which the market data in section 10 supports from third-party sources.

4. Fork it in an afternoon: the build path

Here is the concrete path from an empty directory to a running agent, followed by the harder path from a running demo to something you can put in front of paying customers. The demo is genuinely a few commands. The quickstart is: clone the repo, create a Python virtual environment, install requirements, copy the example environment file and add your Claude API key, install the example web dependencies, then run a vertical - GitHub. It runs on Python 3.11+ and Node 22, and needs nothing more exotic than an ANTHROPIC_API_KEY.

git clone https://github.com/anthropics/commerce-agents.git && cd commerce-agents
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env            # add your ANTHROPIC_API_KEY
(cd examples && npm ci)
python scripts/run_demo.py retail            # storefront on :3000, API on :8000
python scripts/run_demo.py retail --merchant  # the merchant portal instead

That gets you the ACME retail store and, with --merchant, the operator portal, both driven by a real Claude model against fake data. The next move is not to hand-edit prompts. It is to use the commerce-builder Claude Code plugin, which is the intended customization tool. It installs from the repo as a plugin marketplace and exposes four slash commands that scaffold an agent against your own systems rather than ACME's - GitHub.

• /scaffold-commerce-agent generates a new agent wired to your stack from a short interview about it
• /add-commerce-flow extends an existing agent with another skill
• /author-commerce-evals creates evaluation tests so you can measure regressions
• /review-commerce-agent analyzes an agent you already built and flags gaps

The reason to drive customization through the plugin rather than by hand is that a commerce agent's correctness lives in the seams between prompt, tools, and guardrails, and the plugin keeps those seams consistent. It reads the repo as its reference implementation, so the code it generates follows the same gate placement and backend contract as the examples. This is the same "let the agent do the wiring, you make the decisions" pattern that makes forking economical at all, and it pairs naturally with the broader Claude Code build workflow we cover in building software with AI.

The heart of forking is implementing two backend interfaces, and this is where "an afternoon" ends and "a real project" begins. The shopping agent expects a StorefrontBackend implemented over your catalog, cart, order, and policy systems. The merchant agent expects a MerchantBackend over your analytics, catalog, inventory, pricing, and campaign systems. The contract is defined by method docstrings in each role's backend.py and types.py, and each method receives a session object carrying the authenticated principal, so the host resolves credentials and never exposes them to the model - GitHub. Note the deliberate absence: StorefrontBackend has no payment method, because checkout is host-completed. You implement product search against your real database, but you do not implement "charge the customer," because the blueprint refuses to.

One agent definition, three runtimes, and the choice is a real trade-off rather than a formality. The Messages API path is the reference loop: you handle turns manually and every grounding rule is forced with tool_choice, which gives you maximum control and maximum protection. The Agent SDK path runs from the CLI, prefetches grounding, and runs nothing after the turn. The Managed Agents path (beta) is hosted: your agent calls your MCP server through a manifest, with the platform holding credentials per server - GitHub. The catch with the hosted path is that it drops some runtime-only protections (the forced grounding reads and the analysis budgets), substituting the platform's own approval prompt for the merchant gate. That is a genuine security trade you should weigh, not a detail: the more convenient runtime is also the one with fewer of the blueprint's own guardrails switched on.

Then comes the gap between the demo and production, which the repo states with unusual honesty. "The examples have no authentication and the MCP servers bind to loopback," and the defaults in the two config.py files are demonstration values, not production limits - GitHub. Going live means adding authentication and authorization on every route and every MCP server, host-resolved credentials the model never sees, rate limits and abuse controls in front of chat routes, your real business rules (fraud, eligibility, pricing, inventory) inside the backends, memory retention and deletion routes, and log hygiene strict enough that session IDs (which are credentials) never get logged. Auth is the first of these and the easiest to get wrong; our guide to giving an agent an identity, not an API key is the pattern to follow, and the full pre-launch pass is in our security checklist for AI-built apps. One more production dependency you will hit early: the agent reaches your real catalog and cart through tool calls, which in practice means an MCP server, and standing one up cleanly is its own small project we walk through in ship an MCP server for your product.

The strongest signal that this fork path is real, and not a demo that falls apart on contact with a live store, is that it already happened. Within weeks of the September 2 release, Shopify published a first-party implementation wiring the blueprint to a real storefront over its Universal Commerce Protocol and to the Admin API for merchants - GitHub. Community forks landed for Medusa v2 and Shopware, and tellingly, the Medusa fork fills the payment gap with Stripe Checkout, exactly as the design intends. The StorefrontBackend and MerchantBackend contracts turned out to be genuinely portable to real platforms, which is the thing you most want to know before you commit to forking.

5. The missing wallet: bolting on agentic payments

This is the section the blueprint forces you to write, because the blueprint refuses to. The shopping agent hands off a cart; something else has to take the money. Fortunately, 2026 is the year the payments industry raced to build exactly that "something else," and the builder's problem is now less "does a rail exist" and more "which of the several competing rails do I adopt." The market split into two layers you must bridge: checkout protocols that structure the cart, the session, and the handoff, and settlement rails that actually move the money. Claude Commerce Agents omit both, so you pick one from each.

The most concrete integration path today is the Agentic Commerce Protocol (ACP), the open standard OpenAI and Stripe released on September 29, 2025 (with Meta later listed as a co-creator) under an Apache-2.0 license - Stripe. ACP is what powers ChatGPT's Instant Checkout, and its mechanism is elegant: the agent works against your checkout-session endpoints, reads a product feed, and hands you a narrowly scoped Shared Payment Token that lets it initiate a purchase without ever seeing the buyer's card, while you stay the merchant of record and charge through any compliant processor. The current spec version is dated 2026-04-17 and ships as OpenAPI plus JSON Schema on GitHub - Stripe. Because it is open, you can implement it against a non-Stripe processor, though Stripe's Agentic Commerce Suite is the fastest drop-in on the merchant side.

Google's answer is the Agent Payments Protocol (AP2), announced September 16, 2025 with more than 60 launch partners including Mastercard, PayPal, Coinbase, American Express, and Adyen - Google Cloud. AP2 takes a different, arguably more rigorous approach to the trust problem: it gives the agent a cryptographically signed permission slip built from three signed Mandates (Intent, Cart, and Payment), carried as W3C Verifiable Credentials, so a payment network can verify the agent had genuine authorization for this specific purchase with these specific limits. It treats cards, bank transfers, and stablecoins as first-class rails, and it has an x402 crypto extension co-built with Coinbase for agent-to-agent settlement. Where ACP structures the checkout, AP2 structures the authorization, and the two are not mutually exclusive.

Behind those protocols sit the settlement rails, and the card networks moved aggressively. Visa introduced its Trusted Agent Protocol on October 14, 2025, built with Cloudflare, letting merchants recognize a trusted agent through agent-specific cryptographic signatures, and it says it has already completed hundreds of secure agent-initiated transactions - Visa. Mastercard shipped Agent Pay in April 2025 and then Agent Pay for Machines on June 10, 2026 with more than 30 partners, settling across cards, bank accounts, and stablecoins - Mastercard. Both use scoped agentic tokens: the issuing bank mints a credential limited to a maximum spend, allowed merchants, and a session lifetime, so the agent can pay but cannot overspend. The crypto camp offers a leaner alternative in Coinbase's x402, which revives the dormant HTTP 402 status code so an agent pays in stablecoin and a facilitator settles onchain, with no interchange - Coinbase. The following table maps the rails a forked agent can plug into.

The reassuring pattern for a builder is that these rails converge rather than fragment. The same names (Coinbase, Cloudflare, PayPal, Stripe, Adyen, Google) recur across ACP, AP2, the x402 Foundation, and Mastercard's machine payments simultaneously, so betting on one rarely locks you out of the others. The practical recommendation is to start with ACP if your near-term distribution is ChatGPT, because you get the checkout structure and the token exchange in one adoption, and layer a settlement rail (a card network's agentic token, or x402 if you are selling to other agents) underneath. Whatever you choose, put hard spending controls on the agent's side of the wall, the way the card networks scope their tokens; our guide to letting an AI agent spend money safely covers the caps, merchant locks, and real-time controls, and if you are billing customers rather than paying suppliers, the mechanics live in set up metered billing for your AI product.

6. The 2026 substrate that makes this cheap

The reason forking-and-shipping is a realistic afternoon-to-fortnight project rather than a quarter-long slog is that the model and tooling substrate underneath it got dramatically cheaper and more capable in the six weeks before this guide. Three things changed at once, and each attacks a different bottleneck. Understanding them is not trivia: it is how you keep the running cost of a shopping agent, which is a multi-turn, context-heavy workload, from quietly becoming your largest line item.

The first change is context. On September 1, 2026, Claude Fable 5.1 shipped a 1 million-token context window into Claude Code and the Claude Platform, with 128K max output - Anthropic. For forking, that means the whole commerce-agents codebase, your catalog schema, and your backend contracts can sit in a single session while an agent adapts them, which is why the plugin-driven scaffold works as well as it does. The second change is cost: Fable 5.1 cut prompt-cache read pricing from the standard $1 per million tokens to $0.25 per million, a 75% reduction - TechGenyz. That single number is why a shopping agent is affordable, and section-6 math below explains it. The third change is reach: on August 19, 2026, Anthropic moved Computer Use, the new Browser Use tool, the Files API, and the Agent Skills API all to general availability on the same day - EnterpriseDNA. Browser Use in particular is a genuinely new tool (not a rename of Computer Use) that gives Claude a structured accessibility-tree view of a page, so an agent can operate a real checkout instead of only chatting about one - The New Stack.

Now the token economics, because this is where founders either save a fortune or waste one. A shopping agent's cost is dominated by one structural fact: the system prompt, the tool definitions, and much of the product context form a large static prefix that is re-sent on every single turn of a conversation. Sent naively, a 20-turn shopping chat pays for that prefix 20 times. With prompt caching, the cached prefix is billed at roughly 10% of the input rate, and on Fable 5.1 the cached read costs $0.25 per million instead of $1 - Finout. The variable cost per turn then collapses to the small delta of new user and browse tokens. Getting caching right is not optional for a commerce agent; it is the difference between a viable unit economic and a ruinous one, a point we make generally in price your AI product to beat token costs.

The second lever is model tiering, and it is where the current Claude lineup pays off. You do not run every turn on the flagship. You route cheap classification, routing, and extraction to Haiku 4.5 or Sonnet 5, and reserve Opus 5 or Fable 5.1 for the genuinely hard planning steps. The chart below shows why that routing matters: the price spread from Haiku 4.5 to Fable 5.1 is tenfold on input and tenfold on output.

A shopping agent that runs mostly on Sonnet 5 with occasional Opus 5 escalation, batches where it can (batch processing is 50% cheaper), and caches its prefix aggressively costs a small fraction of an all-flagship loop. The disciplined version of this is a routing policy, which we cover in cut AI agent costs with model routing, and the broader case for Fable 5.1 as a build-and-run substrate is in our guide to Claude Fable 5 for coding and company building.

The competitive backdrop is that the cost of an autonomous build cycle keeps dropping from multiple directions at once. Cognition released SWE-2 on September 10, a near-frontier coding model that scores 50.0% on FrontierCode 1.1 (within about a point of Fable 5.1) at 64% lower cost, per third-party reporting - MarkTechPost. Cursor shipped Projects, a persistent coordinator agent that plans work and delegates it to thousands of parallel cloud subagents that keep running with your laptop closed - AI Weekly. And for product imagery, Alibaba open-sourced Qwen-Image-2.1 on September 20, a 7-billion-parameter image generation and editing model with native transparent output, though its research-only license means a shipped commercial store must license it separately or use a cleared alternative - TechNode. The through-line: every input to building and running a store agent (intelligence, context, imagery, orchestration) got cheaper in the same quarter Anthropic gave away the agent itself.

7. Distribution: getting your agent (and products) found

A forked shopping agent on your own domain has one glaring weakness that the scoring table captured as a 3 out of 10 on reach: no one is there. The blueprint gives you the conversation, but not the shoppers. In 2026, distribution for a store agent splits into two separate wins that used to be one, and understanding the split is the difference between building something buyable and building something bought. The first win is discovery: being surfaced by the big AI shopping surfaces when a shopper asks. The second is checkout: actually closing the sale, wherever the shopper is. After a pivotal strategy change this year, discovery matters more than owning the buy button.

That change came in March 2026, when OpenAI mothballed the first version of ChatGPT's hosted Instant Checkout, saying it "did not offer the level of flexibility that we aspire to provide" and that it would let merchants use their own checkout while OpenAI focused on product discovery - CNBC. Read that carefully, because it reframes the whole distribution game: the largest consumer AI surface decided that owning discovery, not the transaction, is the prize. For a forked-agent builder, the lesson is that a clean, fresh, machine-readable product feed is now your most valuable distribution asset, because it is what gets you surfaced. The full playbook for that is our guide to selling your product inside ChatGPT, and the broader discovery discipline is in get your products recommended by ChatGPT.

The demand on those surfaces is real and growing fast, though from a small base. Traffic to US retail sites from generative-AI sources rose 693% year over year during the 2025 holiday season, per Adobe Analytics, and continued at 393% in Q1 2026 - Digital Commerce 360. The chart below shows the trajectory, and the first-principles reading is important: the growth rate is decelerating not because interest is fading but because the base is widening. Triple-digit growth off a tiny base is a nascent channel, not a majority of sales, and you should size the opportunity accordingly.

The surfaces themselves are worth knowing individually, because their economics differ sharply. Perplexity runs a free merchant program with zero fees, zero commissions, and free shipping it funds itself, opened agentic shopping to all US users in February 2026, and reports around 45 million monthly active users skewing high-income - Alhena. Google is the reach heavyweight: its Shopping Graph indexes over 60 billion listings and handles over a billion daily shopping sessions, and its Universal Cart, announced at I/O on May 19, 2026, aggregates carts across Search, Gemini, YouTube, and Gmail - Google. OpenAI's ChatGPT has the largest raw audience but reportedly charges merchants around a 4% transaction fee and gates feed onboarding to approved partners. The strategic point for a forked-agent builder is that distribution has consolidated into a toggle model: a clean feed plus one protocol integration (ACP, UCP, or an MCP storefront) gets you onto multiple surfaces at once, so your leverage is feed quality and protocol coverage, not a bespoke integration per channel. The three-layer version of this (discovery, checkout, and machine-to-machine payment) is laid out in sell to AI agents.

Two 2026 developments complicate the picture and belong in any honest distribution plan. On September 15, Cloudflare flipped its defaults to block mixed-use AI crawlers on ad-bearing pages for new and free customers, while leaving pure search crawling allowed - TechCrunch. The practical effect is that agent visibility is now something a merchant may have to consciously opt into rather than get by default, which cuts both ways: it protects your content but can hide your store from the very agents you want buying from it. And on September 16, OpenAI introduced ChatGPT Ads with a Sponsored Agents test, letting merchants pay to enter a labeled conversation with a shopper, with Shopify as the first ecommerce partner - PYMNTS. It is a US-only alpha today, so treat it as an early-mover watch item rather than a scaled channel, but it signals that paid distribution into agent conversations is arriving almost as fast as the organic kind.

8. The competitive map: every other way to build

Forking Anthropic's blueprint is one way to put a shopping agent in front of customers, and an honest guide has to place it against the alternatives rather than assume the fork wins. The scoring table near the top of this guide ranked eight approaches; this section explains the reasoning behind the ones a founder is most likely to weigh, so the numbers are arguments rather than assertions. The overarching structural point is that the choice is really between three archetypes: fork and own (Anthropic's blueprint, or self-assembly on commercetools and Vercel), plug into a demand surface (ChatGPT, Google, Perplexity), and adopt a platform's turnkey stack (Shopify, Salesforce, or a describe-it builder like Founden).

Shopify scored highest (7.7) for a specific reason: it bundles the two things the fork lacks. Its Storefront MCP reached general availability in early 2026 and is auto-enabled on Shopify Plus, letting agents like Claude and ChatGPT search a catalog and build carts, while its Universal Cart and Shop Pay solve checkout, and it co-developed the Universal Commerce Protocol with Google - Stellagent. A Shopify merchant gets multi-surface distribution nearly for free because the platform auto-generates the feeds and agent-readable endpoints. The trade is ownership and fees: you ride Shopify's rails and pay for them, and the agent surface is Shopify's, not yours. For many stores that is a fine trade. For a founder who wants the agent to be a differentiated core asset, it is the thing the fork exists to avoid.

commercetools with Vercel (6.7) is the closest developer-grade equivalent to forking a blueprint, and comparing them clarifies both. Its Commerce MCP exposes an API-first, headless backend to agents in a protocol-neutral way (it speaks MCP, ACP, and UCP), and its AI Plugins can turn Claude Code or Cursor into a commerce builder that ships a storefront to Vercel from a single prompt - commercetools. The difference from the Anthropic fork is what you own versus rent: with commercetools you rent a powerful, protocol-fluent backend and own the frontend and agent; with the fork you own everything and wire the backend yourself. Salesforce Agentforce (4.8) sits at the opposite extreme: powerful and enterprise-grade, but priced at $2 per conversation or $125 per user per month, requiring a Service Cloud foundation, and carrying a typical five-to-eleven-month implementation - Coworker. It is the incumbent path for a large retailer, not a fast builder's tool, and its score reflects that mismatch with the audience of this guide.

Our own product, Founden, belongs in this map as the describe-it-and-run-it archetype, and it is scored by the same evidence standard as every other row, landing mid-pack at 6.7. Where forking hands you code to adapt, Founden takes a description of the business and builds and operates the whole company from it: the website, the app, the billing, and the admin, from one conversation, with the founder owning the output - Founden. The trade against a fork is the mirror image of the trade against Shopify: you give up line-by-line control of the agent's internals in exchange for not assembling the backend, the payments wiring, and the hosting yourself, and for having the operating layer run on autopilot rather than on your own on-call rotation. It scores well on ship speed and reasonably on ownership and cost, and honestly low on built-in reach, because like a fork it builds the store but does not bring the shoppers. It is the right choice for a founder who wants a running store rather than a codebase, and the wrong one for a team whose entire thesis is a bespoke agent they must own down to the prompt. That is the same build-it-yourself-versus-have-it-built tension we examine for the back office in build your own CRM instead of buying SaaS and for staffing the whole operation in hire an AI workforce to run your company.

The venture market is validating this whole space from the demand side, which is the strongest evidence that the opportunity is real rather than hyped. Consumer shopping-agent startups raised heavily and credibly in 2026: Daydream, an AI fashion agent from Stitch Fix veteran Julie Bornstein, raised a $50M seed from Forerunner, Index, and GV - Newcomer. Phia, founded by Phoebe Gates and Sophia Kianni, raised a $35M Series A at a $185M valuation and reports over a million users - GlobeNewswire. And on the merchant side, Spangle AI, from former Amazon leaders, raised a $15M Series A at a $100M valuation to generate storefronts that capture agent-driven traffic - GeekWire. The pattern across the funded companies is instructive: capital is concentrating in the picks-and-shovels layer (catalog middleware, payment identity, storefront generation) and in verticalized consumer agents with real brand relationships, not in generic "shop for me" bots. A founder forking the blueprint should read that as a map of where the defensible positions are.

9. Safety, trust, and the law

A shopping agent is not a chatbot with a nicer voice. It touches money, it consumes untrusted text from the open web, and in 2026 it operates under a thickening layer of disclosure law. The blueprint's authors clearly understood this, because the single best thing they shipped is not the agents but the safety harness, and copying its philosophy is the highest-leverage decision you make when forking. The core principle is that gates run inside the tool call, not in the prompt. Fencing, provenance gates, caps, memory validation, and the merchant approval gate all execute inside tool execution on all three runtimes, which means a clever prompt cannot talk the agent out of them - GitHub. If you take one architectural idea from the whole release, take that one.

The merchant agent's write path is the pattern to copy for any agent that changes business state. It is a two-phase, stage-then-apply flow: proposed changes are validated against configured guardrails (items per change, price move size, promotion depth, restock size, campaign budget, protected fields) when they are staged and again at apply time, and apply succeeds only for change IDs a human explicitly approved through a real route - GitHub. The diagram below shows the flow. The reason it matters is that it makes the dangerous action (mutating a live listing or price) impossible to trigger from the conversation alone, which is exactly the property you want when the conversation can be poisoned by untrusted input.

The reason this rigor is non-negotiable for commerce specifically is prompt injection, which maps directly to money movement in a way it does not for most agents. Prompt injection was the fastest-growing attack class in 2026, up 340% year over year per OWASP - Help Net Security. It is no longer theoretical for shopping agents: researchers documented injection payloads embedded in public web pages that contained fully specified payment details and instructions for a payment-enabled agent to execute a transaction without user confirmation - Help Net Security. Palo Alto's Unit 42 warned that an agent able to autonomously trigger refunds could be turned into a fraud engine, with bot farms initiating thousands of voided returns in an hour to drain a retailer's cash - Unit 42. The privilege the agent holds (to pay, refund, or transact) is exactly what makes an injection catastrophic rather than cosmetic, which is why the blueprint fences every piece of third-party text before the model sees it.

The market has noticed, and investors are funding an entire "agent assurance" category on the thesis that these businesses only exist because agents are already running in production. In a roughly three-week window in September 2026, three startups raised a combined ~$125M: AIR emerged from stealth with a $50M seed to vet the skills and add-ons agents use, AIUC raised a $40M Series A to certify and insure agents, and Raindrop raised a $35M Series A to catch silent agent failures in production - SiliconANGLE. The chart makes the cluster concrete.

The legal layer is the last piece, and it is disclosure-first and multi-jurisdictional, so a store agent has to reason about it wherever it operates. Apple turned data-sharing disclosure into a submission gate: since November 13, 2025, App Store Guideline 5.1.2(i) requires an app to name any third-party AI it sends personal data to and get explicit consent first, or fail review - TechCrunch. California's SB 243 (companion chatbots, effective January 1, 2026) and SB 1050 (AI-generated ad performers, effective January 1, 2027) extend the disclosure-first trend to consumer AI - Jones Walker. And the EU AI Act's Article 50 transparency duties took effect August 2, 2026, requiring disclosure at first interaction, with a grace period to December 2, 2026 for machine-readable marking of synthetic outputs - artificialintelligenceact.eu. The unifying principle is simple to state and easy to forget: tell the shopper they are talking to an AI, tell them where their data goes, and get consent. The full EU picture for a founder is in make your AI app EU-compliant by Dec 2026.

10. Market reality: adoption, conversion, and where agents fail

Having covered how to build, pay, distribute, and secure a shopping agent, the honest question is whether shoppers actually want one, and the data gives a split answer worth reasoning through rather than cherry-picking. The strongest signal is that AI-influenced commerce is already large in absolute terms. During Cyber Week 2025, Salesforce measured $67 billion in AI and agent-driven sales, influencing roughly 20% of all purchases, within a record $336.6 billion of global spend - Salesforce. That is not a fringe channel. But "AI-influenced" is doing heavy lifting in that number, and separating influence from autonomous purchase is the key to reading the market correctly.

The conversion data is where a builder should focus, because it speaks to whether an agent lifts the funnel rather than just touches it. Adobe found that AI-referred traffic converted 31% higher than other sources over the 2025 holiday, rising to 54% higher on Thanksgiving and 38% higher on Black Friday, with shoppers arriving from AI assistants spending 45% more and bouncing 33% less - Digital Commerce 360. The chart shows the conversion lift by day. The cleanest, least-hyped signal in all of this comes from first-party agents: Salesforce reported that retailers running agents on their own properties grew US sales about seven times faster (13% versus 2%) than those without - Salesforce. A shopper who engages an agent is a higher-intent shopper, and an agent on your own store captures that intent instead of handing it to a marketplace.

The forecasts for where this goes by 2030 are enormous and wildly divergent, and the divergence is the insight, not a flaw. McKinsey estimates agentic commerce could generate $3 to $5 trillion globally by 2030, including up to $1 trillion in orchestrated US retail - Digital Commerce 360. Bain forecasts a more conservative $300 to $500 billion in US agentic commerce, and eMarketer lands near $144 billion - Bain. The chart below shows the spread, which is roughly 28-fold. The reason is definitional: firms disagree about whether "agentic commerce" means AI-influenced browsing or fully autonomous agent checkout, and the number you cite is meaningless without the definition attached. A builder should ignore the headline trillions and anchor on the measured, third-party conversion deltas above.

Now the counter-narrative, because a guide that only sells the upside is not useful. Adoption is outpacing trust. Around 49% of consumers used AI to shop in 2025, yet trust in AI shopping sits near 35%, and 86% of shoppers who used AI for product research still verified the recommendation elsewhere before buying - Alchemer. Roughly 30% of consumers worry an agent will upsell them and 24% worry it will be inaccurate, while 61% say they are more likely to shop with brands that explain how they use AI - YouGov. The legal ground is unsettled too: a court enjoined Perplexity's Comet agent from shopping inside Amazon's logged-in surface in March 2026, and although an appeals court vacated the injunction on August 4, the question of whether an agent may transact inside another company's authenticated surface remains open - GeekWire. The practical takeaway for a forked-agent builder is that transparency and grounded accuracy are not compliance chores; they are the conversion strategy, because the funnel converts but confidence lags.

11. The 2027 outlook: what to build now

Reasoning forward from the structure rather than the hype, the direction of travel is clear even where the timing is not. The reasoning layer of commerce is now a commodity you can fork for free, the payment rails are standardizing in public, and the distribution surfaces are consolidating into a few feeds and protocols. When the inputs to a category commoditize simultaneously, value migrates to whoever combines them with something that does not commoditize: a specific catalog, a real brand relationship, an unusual vertical's rules, a trusted customer base. That is where a founder should aim, and it is exactly what the funded startups in section 8 demonstrate, with capital concentrating in verticalized agents and integration infrastructure rather than generic assistants.

Y Combinator's posture is a useful demand signal precisely because it is measured rather than breathless. Its Fall 2026 Request for Startups named agentic commerce, but folded it inside the crypto and payments-rails ask with the rationale that agents "need payment rails," and its Winter 2027 batch has an application deadline of November 2, 2026 - Y Combinator. The signal is that the near-term money is at the transaction layer, not in another shopping bot, which aligns with where the venture funding actually went. A founder deciding what to build in this space should weight infrastructure and verticalization over horizontal "shop for me" ambition, because the horizontal layer is the one the big platforms are giving away or subsidizing.

The concrete near-term shifts to build toward are agent-to-agent commerce and machine payments, which is where the rails are being laid right now. Mastercard's Agent Pay for Machines and Coinbase's x402 are explicitly about agents paying agents, and Google's AP2 has a crypto extension for the same purpose. The store you fork today talks to human shoppers, but the interfaces you expose (a clean feed, an MCP endpoint, an ACP checkout) are the same ones another company's buying agent will use tomorrow. Building for agent-readability now is not speculative; it is the cheapest insurance against the next surface. The broader shape of a business that runs this way, with agents handling operations end to end, is the subject of our guide to the autonomous business, and the integration surface that makes it possible is in top integrations for your online business.

The honest uncertainty is trust and law, and both cut against moving too fast. If consumer trust stays near 35% and shoppers keep double-checking every recommendation, autonomous purchase stays a minority behavior for longer than the trillion-dollar forecasts imply, and the winning products will be the ones that earn trust through transparency and grounded accuracy rather than the ones that automate the most aggressively. If the legal question of agents transacting inside authenticated surfaces resolves against agents, the protocol-based, merchant-of-record approaches (ACP, AP2, PayPal-as-MoR) become mandatory rather than optional. Neither of these is a reason to wait. They are reasons to build the grounded, transparent, protocol-native version of a store agent, which is the version the fork already nudges you toward.

12. Conclusion: a decision framework

The clean way to decide what to do with Anthropic's blueprint is to separate three questions that the market keeps conflating. First, do you want to own an agent or rent a commerce experience? If the agent is a core, differentiated asset of your business, fork the blueprint and accept that you are signing up to build the wallet, the auth, the distribution, and the guardrails around it. If the agent is a feature your store needs rather than the thing your business is, a bundled platform or a describe-it builder will get you there faster, which is why Shopify and the managed options scored above the bare fork in our table.

Second, where will your shoppers actually be? If your near-term demand is inside ChatGPT, adopt ACP and optimize your feed, because discovery is the win now that OpenAI handed checkout back to merchants. If it is Google, get your Merchant Center feed clean and add UCP. If it is your own store, the fork plus a payment rail gives you the most control over the experience, and first-party agents show the strongest, least-hyped sales lift in the data. The answer determines your integration order, and getting that order right saves the weeks that the payments and distribution work otherwise consumes.

Third, be clear-eyed about what "shipping" means, because the gap between the demo and production is the whole job. The git clone is an afternoon. The StorefrontBackend, the ACP integration, the authentication on every route, the guardrail config, and the grounded accuracy that earns a skeptical shopper's trust are the actual product, and they are worth doing well because they are also your moat. Anthropic gave away the shopping brain. The wallet, the store, the trust, and the distribution are still yours to build, and in a market growing this fast off a base this small, being early and building it right is the advantage. Whether you fork the blueprint and wire it yourself, plug into a demand surface, or describe your store to a builder like Founden and let it run, the winning move is the same: ship the grounded, transparent, agent-readable version, and ship it before the trust curve catches up with the technology.

This guide reflects the AI shopping-agent landscape as of September 2026. Model names, pricing, protocol versions, and platform features in this space change monthly, so verify current details against primary sources before building or buying.