Don’t Let Your Agent Decide the Write Sequence

That leaves a design question that teams often answer by accident: when one agent action has to update three systems, what decides the order, what happens on a retry, and what gets undone if the third write fails? If the agent is wired directly to each system’s APIs, the answer defaults to the model. The Autonomous Commerce Reference Architecture we published argues for a different owner, which it calls the capability layer. The report works through it with a running example: Ardmore, a fictional cabinet manufacturer whose agent finds and makes a substitution when the plant can’t fill a line on a builder’s order. That one substitution writes to the ERP, to the project system the builder sees, and to the plant schedule. Each of those writes also leaves a record, and how you store that record decides how quickly you can answer the hard questions later.

For years, integrations have exposed each system’s functions separately and left the calling application to sequence them. That works when a person wrote the sequence, tested it, and reviewed it. An agent chooses its steps as it goes, so if you point it at those same APIs, it improvises the update order on every run and nobody checks the choice. The sequence ends up living in a prompt, where it can change from one run to the next, and reviewing it means reading a transcript instead of reading code.

The report’s answer is a layer between agents and the systems they act on. A capability is one business operation with stated preconditions, stated effects, and a stated reversal, orchestrated across however many systems it takes. “Substitute a line on a released order” reads from four systems and writes to three, and the agent sees it as a single call that either happened or didn’t.

Inside the capability, the write order is fixed. In the example from the report, our sample firm Ardmore writes to the ERP first because it holds the commercial record everything downstream reconciles to. The project system comes second because it holds the commitment the builder sees, and the plant schedule comes last because writing there releases material. No transaction spans all three systems, so the capability is the thing that owns the sequence.

The first is idempotency. Retries are normal in agent work: runs time out and resume, models return malformed responses, and network calls fail ambiguously after they may already have succeeded. Every capability that writes should accept an idempotency key and honour it for a stated window, so a second call with the same intent doesn’t produce a second substitution. The window has to cover the runtime’s resumption horizon, because a key honoured for an hour won’t protect a run that resumes the next morning, and that’s the run most likely to repeat itself.

The second is compensation. A rollback undoes a change that never became visible, while a compensation is a new action that reverses one that did, the way a refund offsets a payment instead of deleting it. If the ERP and project system writes succeed and the plant schedule write fails, the report allows three responses: retry within a stated budget, compensate the two successful writes and report that the call didn’t happen, or stop and escalate with the partial state described precisely enough for a person to act on. A retry with no budget isn’t on that list because it never reaches a final state. The report adds one requirement that’s easy to miss: record each compensation as an action in its own right, so the audit trail shows what actually happened.

A capability is defined in business terms, so its implementation can change underneath it. When the ERP is replaced, the capability description, the agent, and the work description all stay as they are, and only one implementation gets rewritten. For many CIOs that’s reason enough to build the layer as part of their first agentic use cases, not after them.

The same logic applies to selling to agents you don’t control. The Agentic Commerce Protocol from OpenAI and Stripe and Google’s Universal Commerce Protocol both define how outside agents call a seller’s checkout. Each protocol sets the format and the handshake, and the checkout behind it still needs a fixed write order, idempotency, and a defined reversal. A seller that builds that capability once can expose it through both.

The report asks you to record each compensation as its own action. We’d add one step: decide where that whole record lives while you build your first agentic use cases. Every capability call leaves a trail of what the agent was trying to do, what it read, what it wrote, and anything it reversed. Most teams keep that trail as a log. A log is fine for checking what happened on one call, but it’s much less useful when you find out a field was wrong and need to know everything that relied on it.

That’s a question about connections. This order used that field, the field came from that system, and the same field fed these other orders. A graph database such as Neo4j stores records with those connections already in place, so you can ask the question directly instead of piecing the answer together from logs. In Neo4j, “which orders relied on this field?” is a single query. With a few capabilities and a short history, it’s a small job, and each new capability adds to the same record. If you wait, you end up rebuilding those connections from logs that were never meant to show them, usually in the middle of a problem.

A capability that gets write order, retries, and reversal right can still write a wrong decision cleanly. Chapter 15 follows one Ardmore substitution that passed all five boundary conditions and the freshness check, and wrote to all three systems in the right order. It was still wrong, because one field in the project system was recent and incorrect. Nobody noticed for nine weeks. Rebuilding the decision took twenty minutes, but finding the other orders that relied on the same field took four days of engineering. The chapter explains what Ardmore changed afterwards and why the model, the prompt, and the agent weren’t on that list. Chapter 7 also covers setting precedence field by field when systems disagree, sizing for agent read load, and containing prompt injection and tool poisoning, and it ends with a single test you can run against your own stack.

Download the Autonomous Commerce Reference Architecture for the full architecture, the complete Ardmore worked example, and the templates in Appendix A.