Receipts for agentic commerce

Anthropic's Claude Commerce Agents blueprint tells an AI agent what it may do in a store. Visa, Mastercard and Google are deciding how an agent may pay. Nobody in that stack keeps a record a stranger can check. This is what each layer covers, where each one stops, and what a signed receipt adds.

Everything about the blueprint below was checked against a fresh clone of anthropics/commerce-agents at commit fd4d592 (31 August 2026), the only commit in the repository. Sources are at the end.

What Anthropic shipped

On 2 September 2026 Anthropic published the repository under Apache-2.0: a reference blueprint, not a product, and it says so in its own README, "a reference implementation; it is not maintained and does not accept contributions." It contains two agents.

• A shopping agent a business embeds for customers. It searches a catalog, compares products, builds a cart, answers order and policy questions, and remembers what a customer tells it. Five flows, twenty tools under the default config.
• A merchant agent the staff use for the back office. It explains performance, maintains listings, acts on inventory and order alerts, prices and promotes, and drafts campaigns. Five flows, twenty-two tools. Every write is staged until a person approves it.

Each agent is defined once and runs on three of Anthropic's runtimes: the Messages API, the Claude Agent SDK, and Managed Agents. Four fictional verticals (retail, travel, telecom, ticketing) ship as runnable examples with eight web apps between them, plus a Claude Code plugin that scaffolds an agent against your own systems. The test suite collects 1,105 tests.

About Visa and Mastercard. Press coverage paired the launch with both networks. Read closely, the relationship is distribution: "Accenture, Mastercard and Visa are working with Anthropic to bring the blueprint to their clients and merchant networks." There is no technical integration in the code. Shopify and Priceline are named as merchants already running customer-facing agents on Claude. The "carts 35% larger, 60% more likely to complete" figures are Anthropic's own reported numbers, not an independent benchmark.

What the blueprint enforces, in plain words

The safety page is the most careful part of the repository. Every rule below is enforced inside the tool call, so it holds on all three runtimes.

• The model only reads fenced text. Product descriptions, reviews, and any third-party content are sanitized and wrapped before the model sees them. A listing that says "ignore your instructions" is just text.
• The cart accepts only what a search returned. A product id the model invents is refused. The refusal is returned as a normal result marked blocked with the gate's name.
• Nothing places an order or charges a card. The storefront interface has no such method. Checkout renders the cart and hands the customer a payment link the model never sees.
• Merchant writes are staged, then approved by a person. Price moves, restocks, and campaigns are staged changes. apply_change succeeds only for an id the host marked approved. Guardrails run at staging and again at apply.
• Memory is filtered. Facts about a customer are capped, categorized, and refused if they look like identifiers.

Where the blueprint ends

The same page lists what it leaves to you: authentication, credentials, rate limits, fraud and business rules, payment, memory as personal data, log hygiene, the approval surface, and the guardrail values. Three of those matter here.

The approval is a mark your code sets. The gate checks membership in a set called approved_change_ids. The example portal adds the id when a person clicks approve and removes it when the apply turn returns. The safety page says it directly: "The gate checks only that your code set the mark." When a change is applied, the reference stamps applied_by and applied_at on the change record, so your own database does keep a note of who applied what. That note is an ordinary database field. It can be edited, it proves nothing to anyone outside the company, and nothing stops the same approval from being used twice inside the same turn.

The checkout produces a card, not a record. When the model calls checkout, the presentation layer reads the cart and asks your backend where that cart is paid for. The answer is a hosted URL on a card. No artifact says "this exact cart, these lines, this total, went to payment," and nothing ties the order you later place back to the cart the agent built.

Logging is one line per model call. Each model call logs one INFO line: round, model, stop reason, token usage, time, and a twelve-character digest of the session id. Tool calls and gate decisions are not logged by default. This is deliberate and good hygiene, since the session id is also the request credential. It also means the record of what the agent did is whatever your host chooses to write down, in a form only your host can vouch for.

Where the payment layer ends

The card networks and the platform companies are building the other half of the stack: how an agent proves it is allowed to pay. Four efforts matter in September 2026.

We wrote about Mastercard's design in an earlier post. These are real and they are valuable. They answer "is this agent allowed to spend this money on this merchant," and the networks are the right party to answer it. Notice the shape they share: every one of them signs the moment of payment, stores the proof on the network's or the platform's own infrastructure, and says nothing about the merchant's back office, the refused cart add, or the price change an operator approved on a Tuesday afternoon.

Logs are not receipts

A log is written by the party that ran the agent, in its own store. It is editable, deletable, and silently skippable. It records successes by default; a refused call may leave no line at all. It proves something only to people who already trust the server.

A receipt is signed by the deployment's own key at the moment of the action. Any edit after signing breaks the signature, and every receipt names its parent, so a deleted one leaves a gap. A refusal is a signed statement, not an absence. It is verifiable on any machine, offline, without asking the store or a vendor.

The blueprint has rules. The networks have signed payment authority. Neither has a receipt for what the agent actually did between "find me a tent" and the payment link, or for what the merchant's agent changed and who allowed it. That is the gap, and it is the whole of it.

What Treeship adds

treeship-commerce is a Python package that plugs into the blueprint at three places, without changing a line of the reference. It records; the reference's gates keep deciding.

From the merchant demo, run on a clean machine with no model and no API key. Every id is real.

# the same change, applied three times
  apply (not yet approved)   blocked:approval       art_75dc2ed0…  art_eb5028ba…
  operator approves          grant signed           art_205dbb64…
  apply (approved)           ok                     art_e94e7f87…  art_24edaa84…
  apply again (replay)       blocked:approval       art_6085c563…  art_87d1f2fa…

# the sealed session, verified offline
  PASS replay-local-journal -- local Approval Use Journal passed, use 1/1
  24 passed, 0 failed, 1 warnings
✓ package verified

What a receipt never carries. The blueprint is strict about what reaches the model and the logs, and the receipts keep that discipline. Not the arguments, only their digest. Not the result text, which is fenced third-party content. Not the session id, only the same twelve-character tag the reference's own logs use. Not the payment URL, not the order reference, not the cart's lines. A holder of the original can recompute every digest; a holder of the receipt learns nothing from one.

Where Treeship ends. A receipt proves that this deployment's key signed, at that time, that this call was about to run with arguments of this digest, and what the gate decided. It proves a named person's approval was minted for change 42 and spent once. It proves a cart of this digest was handed to checkout and an order chained from it. It proves nobody edited any of it since. It does not prove the catalog was truthful, that the price was right, that the tool's answer was correct, or that money moved. Payment stays with the host and the networks. Treeship authenticates statements. It does not adjudicate commerce.

Who signs what

The same question from the reader's side: after a purchase, who holds signed evidence of each step?

Why this is the important piece

Three reasons, none of them about us.

1. Disputes will be about the steps, not the swipe. The networks can prove the agent was allowed to pay. The first wave of agentic commerce disputes will be "I never asked for that item," "the agent changed my order," "who lowered that price by 40%." Those live in the agent's actions and the merchant's back office, exactly where nobody is signing anything.
2. Merchants now have agents writing to their systems of record. The merchant agent is the less discussed half of the blueprint and the more consequential one. A staged price change applied by an agent under a human's click needs evidence that survives the click: who, what, when, once. A database column is not evidence.
3. Trust between parties needs proof that leaves the building. A marketplace seller, an auditor, a regulator, a customer in a chargeback: none of them can read your logs, and none of them should have to trust that you kept them honestly. A receipt they can verify on their own laptop is a different kind of object.

The blueprint's authors drew the line themselves: the gates are theirs, the record is yours. Treeship is that record, and it is built to be worth something to the people on the other side of the line.

Try it in five minutes

# in a clone of anthropics/commerce-agents
pip install -r requirements.txt
pip install treeship-sdk treeship-commerce          # 0.30.0
curl -fsSL https://treeship.dev/install | sh && treeship init
python -m treeship_commerce.demo                    # shopping: the gate, the hand-off, the order
python -m treeship_commerce.demo_merchant           # merchant: held, approved once, refused on replay

# or let Claude Code wire it into your own deployment
claude plugin marketplace add zerkerlabs/treeship
claude plugin install treeship-commerce@treeship
/add-treeship-receipts merchant

Docs: Claude Commerce Agents. Source: integrations/commerce-agents, Apache-2.0, 35 tests on a real ship over the reference's own mocks, run in CI against the reviewed commit. The earlier post, with the full receipt design: You can't have agentic commerce without tamper-proof receipts.

Sources

• anthropics/commerce-agents, README and docs/safety.md at commit fd4d592, checked on a fresh clone
• PYMNTS, "Anthropic Built the Shopping Brain and Skipped the Wallet", 3 September 2026: the Visa, Mastercard and Accenture distribution relationship, the "no payment protocol, no product catalog, no advertising layer" line, and the caveat on Anthropic's own figures
• Digital Commerce 360 and MarkTechPost on the launch
• Anthropic webinar, Building Claude Commerce Agents
• Visa Developer, Trusted Agent Protocol overview; Visa press release, October 2025
• Mastercard Agent Pay; Stellagent on Agentic Tokens and Verifiable Intent
• AP2 explained; ACP explained; Applied Technology Index, 2026 comparative analysis