1. Run the suite against what you have
137 statements, one report row per statement. You see the gaps before anyone writes code.
Practice
Commerce agents
Shopping and merchant agents over a real store, built test first against the contract and checked with a suite anyone can run.
What we build
- Storefront and merchant backends over a live catalogue, cart and admin API
- Carts and sessions that survive a restart
- Staged changes applied exactly once across processes and crashes, with undo
- Hosted checkout and order placement, held when the amount does not match the cart
- The cart revalidated before it is paid for
- Order actions for the shopper: cancel, return, report a problem
What we ship in the open
The reference blueprint for Claude Commerce Agents ships four mock backends and states that it is not maintained and accepts no contributions. Two things are missing from it: an adapter for a real store, and any way to check an adapter against the contract.
We built both.
- commerce-agents-medusa, a Medusa v2 storefront and merchant backend with Stripe checkout and a durable change ledger
- commerce-agents-conformance, 137 numbered statements from the contract as pytest mixins, one report row each
Running the contract as tests against the examples of the reference found a dozen departures. All are reported, and a maintained fork has adopted twelve.
How an engagement starts
2. Close the gaps test first
Each gap gets a failing test that fails for the right reason, then the fix, then an attempt to break the fix.
3. Keep it closed
The suite goes in your CI, so the next change cannot quietly reopen a gap.
Payments and protocol Healthcare agents Start a conversation