An agent you cannot audit is a liability

Every supply chain demo now has an agent. It reads the emails, chases the supplier, updates the booking and flags the delay. The demo is convincing, and the first question a buyer should ask is the one the demo never answers: when the agent updates the booking, what did it change, on whose authority, and can I put it back?

Those are audit questions, and they are the difference between a useful agent and an expensive incident. An agent that cannot answer them is not a feature. It is a new class of unmanaged change.

What an agent actually does

There are three levels of action, and they are often collapsed in the marketing. An agent can watch: read the record and surface what matters. It can suggest: draft the update, the follow-up or the rebooking, and leave the decision to a person. Or it can run: apply the change itself, at a scope it was given.

The value rises with the level and so does the risk. Watching is a reporting feature. Suggesting is a productivity feature. Running is an authority delegation, and it needs the controls any delegation needs: a scope, a limit, a log and a reversal.

The three questions an auditor asks

The first is what changed. Not that something changed, but the before and after of a specific field on a specific record, with a timestamp. The second is authority: which rule, instruction or person allowed this change, and was the agent inside the scope it was given. The third is reversibility: can the change be undone, and is the undo itself recorded.

A system that cannot answer all three is not ready for level three, no matter how good the model is. The model is not the control. The ledger is.

Watch, suggest, run

The sensible path is to let the organisation choose the level per capability, not per agent. Chasing a supplier for a missing packing list is a safe thing to run. Rebooking a container across a carrier is not the same decision, because the cost of being wrong is different and the approval chain is different. A single on switch treats every action as equal, which is how autonomy gets rolled back entirely after the first bad week.

Per-capability levels also make the rollout measurable. You can watch what the agent would have done for a month, compare it with what a person did, and only then let it act. That is a boring sentence and it is the difference between adoption and a pilot that never ends.

Why the record comes first

An agent grounded on a scattered record inherits the gap. It acts on a PO that changed in the ERP but not in the portal, or a carton that was packed but not booked. It is not wrong because the model is weak. It is wrong because the facts it read were already stale.

Ground the agent on an execution record and the situation changes. The facts it acts on are the facts the rest of the chain sees, at the same grain, with the same identity. Every action can be written to the same audit trail that carries human changes, and every reversal is a state transition on the record rather than a repair in a side system.

That is the argument for the record in one line: autonomy multiplies whatever the underlying data does. If the data is scattered, it multiplies reconciliation. If the data is execution, it multiplies throughput. Build the ledger before you build the autonomy.