Every agent we ship has an approval gate

There is a version of an AI agent that demos beautifully. You describe a goal, it reasons, it acts, and nothing in the loop asks a human for permission. It is genuinely impressive, and we have never shipped one.

We build agents that touch things people care about — a live storefront, someone’s spiritual practice, a company’s operational data. In every one of those, the question that decides whether the project survives contact with a real business is not "how capable is the model?" It is "what is the worst thing this can do before someone notices?"

Capability is not the constraint. Blast radius is.

DynoAgent, the agent inside our conversion product DynoWeb, has read access to a merchant’s live store data and can propose concrete changes to their storefront. It is the kind of access that makes the product useful and also makes it a liability if it goes wrong.

So every mutation passes through an explicit merchant approval gate before it touches anything. The agent does the expensive cognitive work — reading behaviour, forming a hypothesis, drafting the change, explaining its reasoning. The human does the cheap, decisive work: yes or no.

The approval gate is not a limitation we apologise for. It is the reason merchants grant the access that makes the agent worth having.

This turned out to be the thing that got people to say yes at all. Nobody hands storefront write access to a system they cannot predict. They will hand it to one that always asks.

What a gate actually needs

A confirmation dialog is not an approval gate. If the human cannot evaluate the decision in the time they will actually spend on it, you have built a rubber stamp and moved liability onto a user who cannot exercise it. Four things have to be true:

1. 01The proposed action is legible. Not the model’s chain of thought — the concrete change, what it affects, and why the agent thinks it helps.
2. 02The reasoning is inspectable, so a sceptical user can disagree on the merits rather than on vibes.
3. 03The action is reversible, with a rollback that is one action and not a support ticket.
4. 04The scope is bounded in advance. An agent with tools that can only do five things is far easier to supervise than one with an open-ended shell.

The fourth is the one teams skip. It is tempting to give an agent broad tools and rely on the prompt to keep it in line. Prompts are not a security boundary. The tool surface is the boundary; the prompt is a suggestion.

Where the gate goes matters more than whether you have one

Gate too early and the product is a chatbot that makes work rather than removing it. Gate too late and you are asking someone to approve a fait accompli.

The rule we use: the agent should do everything up to and including the point where the work becomes irreversible, and stop exactly there. Draft the email, do not send it. Stage the change, do not publish it. Compute the refund, do not issue it.

In SimranLock, our Sikh practice app, the Gurbani Companion answers questions grounded in scripture. There is no mutation to gate — but the same instinct applies to a different axis. In a living religious tradition, a confident wrong answer is not a bug, it is a harm. So the correct default is often to say less, and to stay tethered to the source text rather than generate around it.

The cost, honestly

Gates cost you some of the magic. A supervised agent is less astonishing in a demo than one that appears to run the whole business by itself. Adoption is slower because users have to build trust before they lean on it.

What you get back is a system that survives its first bad week. Every autonomous agent eventually does something stupid — the question is only whether that happens in front of a customer with no undo. We would rather ship the less impressive thing that is still running in a year.

If you are building something in this shape and want a second opinion on where the boundary should sit, that is a conversation we are always happy to have.