An approval workflow is not the last line of defence against a bad AI output. If you think of it that way, you have already designed it wrong.
Approval workflows do not monitor what the agent does and intervene when something goes off-track. They decide — before anything runs — which actions the agent can take on its own, and which actions it cannot take without you. That is a different mechanism entirely, and understanding the difference changes how you build an agent system you can trust.
What most people assume approval workflows do
The common assumption is that approval workflows are reactive. The agent acts. Something goes wrong. The approval catches it.
This model puts the approval after the action. The damage is already done — a message sent, a record updated, a deal moved. The approval is reviewing an outcome, not preventing one.
An approval workflow built this way is not a control layer. It is an audit log with extra steps.
How approval workflows actually work
An approval workflow is a gate, not a monitor. It is built into the system before the agent runs, and it determines which actions the agent is allowed to take on its own.
When the agent reaches a defined action — sending a message, updating a record, escalating a request — it does not attempt the action. It prepares a draft, places the action in a review queue, and waits. The action does not run until a human releases it.
The agent cannot cross that line. It does not retry. It does not find a workaround. It waits until a human approves, edits, or dismisses the queued action. This is enforced at the system level — not by a prompt instruction the model is trying to follow.
An approval workflow is not a safety net. It is the line that defines what the agent can do without you.
What you are deciding when you design an approval layer
Designing an approval layer is deciding where you trust the agent and where you do not — yet.
Some actions are low-stakes: tagging a contact, logging a note, adding an item to a task list. Getting these wrong costs little. Reviewing each one defeats the purpose of having an agent. These run automatically.
Other actions carry real weight: sending a message to a client, updating a payment record, closing a deal, escalating a ticket. The cost of getting these wrong — and the value of a human check — justifies the review step. These go into the queue.
A well-designed approval layer does not put everything in the queue. It puts the right things there. That boundary is a deliberate design decision, not a default setting.
What systems without approval layers depend on
Without an approval layer, the only thing preventing an agent from taking a high-impact action is a prompt instruction — which the model is trying to follow, not enforced to obey. A prompt is guidance. An approval layer is a gate.
Prompt instructions can be misread. They fail on edge cases the author did not anticipate. Conflicting context in the input can override them. None of this is the agent misbehaving — it is the natural behaviour of a system built on instruction-following rather than enforced constraint.
An approval workflow does not rely on the model interpreting the instruction correctly. The action is structurally blocked until a human releases it. Those are different guarantees.
What a well-designed approval layer looks like in practice
In practice, a well-designed approval layer is invisible most of the time. The agent handles low-stakes actions automatically — logging, tagging, scheduling, drafting internal notes. The things that need a decision appear in a queue.
You review the draft client message. You dismiss the follow-up that went to the wrong contact. You approve the record update before it saves. Each decision takes seconds. The agent handles everything around those decisions.
The goal is not to review everything. The goal is to review the right things — and to know, without checking, that nothing else ran without you.