Ownware
Guide · Sep 3, 2026

Staged writes: letting an AI run your back office without losing the keys

Anthropic's merchant-agent blueprint stages every write for a person to approve, and puts the safety in code rather than in the prompt. That is the right pattern, and it is a good test to hold any "AI for your business" tool against.

The nervous question about putting an AI anywhere near a business system is not "will it be useful". It is "what happens the day it is confidently wrong about a price".

Anthropic's commerce-agents blueprint, open-sourced on 2 September 2026 at github.com/anthropics/commerce-agents under the Apache License 2.0 (read 3 September 2026), answers that question with a mechanism rather than a reassurance. It is worth understanding even if you never build an agent, because it gives you a specific thing to ask any vendor selling you one.

The mechanism, in the blueprint's own words

The repository describes the merchant agent as one that "explains performance, maintains listings, acts on inventory and order alerts, prices and promotes, and drafts campaigns; every write is a staged change the host's approval surface applies" (read 3 September 2026).

The design article, the anatomy of effective commerce agents, is more specific (read 3 September 2026):

"every write tool produces a staged change with a server-generated ID, and apply_change succeeds only for IDs that have been approved through a real surface."

Read the two halves of that sentence separately, because both are load-bearing.

A server-generated ID. The agent does not choose the identifier of its own pending change. It cannot manufacture one, and it cannot approve one it invented.

Approved through a real surface. Not approved by the model saying it was approved. Approved by a person, in an interface, that then applies it.

So the agent's output is never a change. It is a proposal with a number on it, sitting in a queue, waiting for a human who can read it and say no.

The line that should be quoted more than it will be

"The prompt is where safe behavior starts, but in commerce it can't be where safety is enforced."
the anatomy of effective commerce agents (read 3 September 2026)

And, on the consumer half:

"No model tool call moves money or changes the business. Order placement, payments, refunds, price changes, and campaign launches all end in an action the harness controls instead of the model."

This is the distinction that separates a serious agent product from a demo. If the guardrail is a sentence in a prompt, it is a request. Prompts are text, text is negotiable, and a model that has been argued into ignoring an instruction has not broken anything — it has done what text does. If the guardrail is the absence of a function, it is a wall.

The blueprint puts it structurally on the buying side too: the backend interface the shopping agent calls "has no charge method at all". There is no clever prompt required to stop the agent charging a card, because there is nothing to call.

The test this gives you

You can now ask any "AI for your business" tool three questions, and the answers are checkable rather than atmospheric:

  1. When the assistant changes something, what exactly happens? If the answer is "it makes the change", the guardrail is a prompt. If it is "it creates a pending change that you approve", the guardrail is the design.
  2. What can it do that cannot be undone? Refunds, deletions, sends, price publishes. Ask for the list. A vendor who has thought about this has the list ready; a vendor who has not will describe their model's good judgement.
  3. Where is the record? If an agent acted on your data, there should be a line saying so, written where the agent cannot edit it.

None of those questions require you to understand anything about models. They are the same questions you would ask about a new member of staff with a company card.

What this store's own agent door does, and does not, do

We can answer question one, because Deliora — the software this store runs on — has an agent door, and it was built the same way by instinct before the blueprint existed to name it.

From the product's own feature list: agents connect over MCP to list orders and pull revenue statistics and, with an admin key, mint deal codes, "under the same guards a person faces; there are deliberately no refund, price-edit or customer-email tools."

That is the pattern by omission. The reason an agent connected to this store cannot issue a refund is not that it has been told not to. It is that no refund tool was written. Likewise a support seat "sees orders, customers and licenses without the power to wipe or configure the shop", and there is an "append-only audit trail across browser, API and agent" — question three, answered in the schema rather than in a promise. How to connect an assistant to it is a page on this site, and connecting Claude to an invoicing app is the same idea walked through end to end.

Now the limits, because this is where a page like this usually stops being honest.

Deliora does not implement the blueprint. There is no MerchantBackend, no stage_listing_update, no apply_change, and no staged-changes queue. What exists is the narrower, older discipline the blueprint formalises: destructive tools were never written, roles are enforced, and the audit trail is append-only. Those are not the same thing, and this guide would be worth less if it blurred them.

A missing tool is not a security model. Omission stops the tool you did not write. It does nothing about a key that leaks, a role granted too widely, or an agent given an admin credential because it was easier. Read securing a self-hosted business app before you hand any credential to anything.

And staging is not correctness. A staged change a tired person approves at the end of a Friday is a change. The queue buys you a moment to notice; it does not notice for you. The blueprint is explicit that approval happens through a real surface — the quality of that surface is doing more work than the word "staged" suggests.

The one-line version

An assistant that proposes is a colleague. An assistant that acts is a liability with good manners. The blueprint's contribution is to make that difference something you can check in code rather than something you have to trust — and the same test works on tools you buy, not only on agents you build.

The other half of this pair is what a buying agent reads on your store before it recommends you, which is the same blueprint from the customer's side. If you want to poke at the software itself rather than read about it, the Deliora demo is seeded and open, admin included, and the product page is $99 once with the source in the box.

Own your tools

Stop renting your own business.

Every tool in this store is a one-time purchase: install it on your own server, keep your own data, and never see a renewal invoice.

Affiliate program
Recommend tools people own — earn 35% on every sale. 90-day tracking, instant delivery, payouts by Lemon Squeezy.
Become an affiliate →