Cybersecurity
CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.
Discover →
Linux Services & Systems
Domains, hosting, PEC, email infrastructure, network services and Linux systems. Open Source infrastructure support and management.
Discover →
On 1 September Anthropic opened commerce-agents, Apache-2.0 licence, in Python. It presents itself as a reference blueprint for building shopping agents and merchant agents, and the part worth attention is not the domain but how the write path is designed.
Two roles, defined once
There are two agents, on opposite sides of the same shop.
The shopping agent is the one a business embeds in its own customer-facing application: it searches, compares, plans, fills the cart, answers questions about orders and policies and remembers what the customer tells it. The merchant agent is the one staff use for the back office: it explains performance, maintains listings, acts on inventory and order alerts, sets prices and promotions and drafts campaigns.
Each is defined once through four elements the repository keeps separate: the prompt, the skills, the tool contracts and the gates. From that single definition the project carries the same agent onto three different runtimes: the Messages API, the Claude Agent SDK and Managed Agents.
The package structure follows the same idea. There is a commerce-common holding what both roles share, meaning config, fencing, memory, skills, grounding, presentation, executor frame and events. Then for each role a core holding types, backend, prompt, tool contracts, gates and executor, with the runtimes alongside changing only the turn loop.
It is the same separation between core and extension points we found reading DeepSeek Harness, applied here to a domain with direct financial consequences.
Where the write stops
This is the part that makes the repository useful even to people who sell nothing online.
The note at the head of the documentation is explicit: “Nothing places an order, charges a card, or changes a live listing”. Checkout does not complete. It renders the cart for the host application to finish. And every merchant agent write is a staged change applied by the host’s approval surface, meaning by a person.
The sentence closing that note is the one that matters most for anyone assessing the architecture: “Business rules, authorization, and compliance are the deployment’s”. The blueprint does not claim to carry business rules, authorisation and compliance with it: it states they stay with whoever puts it into production.
In the merchant agent’s core, alongside the tool contracts, two distinct entries appear: change guardrails and gates. They are the same idea translated into code: the agent can propose a change but cannot apply it. The point where it stops is declared in the definition rather than left to the prompt.
What can be run
The repository is not only architecture. It carries four runnable verticals, retail, travel, telecom and entertainment, each with a storefront for the customer and a portal for the merchant, running on the same libraries and starting with one command.
For anyone wanting to start from their own systems there is a Claude Code plugin, commerce-builder, with commands to scaffold a project against those systems, add a flow, author the evaluations and review an agent that already exists.
Everything in the demos is openly fictional, with a single made-up company.
What we think
What seems most useful is that the stopping point is a property of the design rather than a recommendation. In most integrations we see, the boundary between what the agent proposes and what the agent executes lives in a sentence of the system prompt, which is the least robust place it could be. Here the gate is an element of the agent’s definition, at the same level as the tool contracts. It survives the change of runtime, because the same agent on Messages API, on the Agent SDK or on Managed Agents stops at the same point.
It is the same principle we described writing about security and governance of the agentic loop, where the point was that security lives in the harness and not in the prompt. The same principle is in the human checkpoints of TrueForge.
The second observation concerns the division of responsibility, which is stated rather than implied. A blueprint writing out that business rules, authorisation and compliance stay with whoever deploys it is more honest than one letting you believe it has solved them. For anyone working in Italy that means the parts falling under regulation, from consumer rights to payment data handling, do not come from the blueprint and have to be designed separately.
The practical criterion we take from this, for anyone assessing an agent that touches transactions, is to look first at where the code prevents the write, rather than at what the prompt asks it not to do. If the answer is that no such point exists, what is being built is not an agent with human supervision but an agent with a polite request for supervision.