Guardrails Before Autonomy: Designing Approval Flows for Commerce Agents

Every conversation about AI agents eventually reaches the same question: how much should the system be allowed to do on its own? It is usually framed as a dial between “fully manual” and “fully autonomous,” and teams argue about where to set it.

That framing is not very useful. Autonomy is not one setting for a whole system. It is a decision made per action, and the most reliable way to make it is to ask a more concrete question: if this action turns out to be wrong, how expensive is it to undo?

Sort actions by reversibility, not by intelligence

In a store, agent actions differ enormously in their consequences. Flagging a product with a thin description costs nothing if the flag is wrong. Publishing a reply to a customer review is visible to every future shopper. Raising an advertising budget spends real money immediately.

A practical design sorts every action an agent can take into three lanes:

Act freely. The action is reversible, low-impact, and bounded by hard rules. Creating an internal task, tagging a product for review, drafting a response that nobody sees until it is approved. The agent does these without asking.

Act, then report. The action is reversible and bounded, but someone should know it happened. A small price adjustment within a pre-approved range, with a rollback point saved before the change, belongs here. The agent acts and the change appears in a summary.

Ask first. The action is hard to undo, financially significant, or customer-facing. Budget increases, new spend, published content, and bulk changes beyond a defined size wait for a person.

Which lane an action belongs in is a business decision, not a technical one — and it should be easy to move actions between lanes as trust grows.

Hard rules are different from approvals

Approvals and rules are often confused, but they do different jobs.

A rule is a limit the agent can never cross, whether or not anyone is watching: a minimum margin, a maximum percentage change per run, a list of products excluded from automation. When an action would breach a rule, the right behaviour is usually to skip it and say so, not to quietly clamp it to the nearest allowed value. Clamping hides the fact that the agent wanted to do something outside its limits — information a person should see.

An approval is a checkpoint where a person decides. Approvals are expensive in attention, so they should be reserved for decisions where human judgment genuinely adds something. If every action needs approval, people stop reading what they approve, and the checkpoint becomes a rubber stamp.

Good systems use rules generously and approvals deliberately.

Separate the reviewer from the owner when it matters

For some decisions, one approval is not enough. In advertising, for example, it is reasonable for a specialist to review whether a proposed campaign structure makes sense, and for the business owner to approve whether the money should be spent. Those are different questions answered by different people.

Routing actions to the right person — and not to everyone — keeps approvals meaningful. A useful pattern is to let the specialist approve changes that redistribute existing spend, while anything that increases total spend goes to the owner.

Make every action explainable and reversible

Two mechanisms turn a set of guardrails into a system people can trust:

An activity log with reasons. Every recommendation and every action should be recorded with what triggered it, what data it used, what it changed, and who approved it. When something looks wrong, the first question is always “why did it do that?” — and the log should answer it without anyone reconstructing events from memory.

Rollback by design. Any bulk change should save the exact previous state before it runs, so that undoing it is one step rather than a recovery project. Rollback changes how people feel about automation. When a mistake costs one click to reverse, teams are willing to let the system act; when it costs a weekend, they are not.

Grant autonomy based on evidence

The safest path to an autonomous system is incremental:

1. Recommend only. The agent proposes; people act. Compare its proposals with what the team would have done.
2. Act within tight rules. Once proposals are consistently sound, allow the agent to act on the lowest-risk lane, with logs and rollback in place.
3. Widen the lanes. Move actions from “ask first” to “act, then report” only when the log gives concrete reasons to trust them.

Each step is reversible, and each produces evidence for the next one. That is the real purpose of guardrails: not to restrict an agent forever, but to make it safe to learn how much it can be trusted.