A gate is a state in a process, not a box on a form
A purchasing team deploys an assistant that can prepare purchase requests, and it works. Six months later the same team lets it raise the requests, because asking a person to press a button on every proposed order was judged too slow. The approval was never removed, only moved behind a flag nobody reads. A chief operating officer now owns a process in which a machine commits spend above a threshold.
That is not a policy failure; the approval existed on paper. It failed because approval was treated as a feature to be switched on rather than as a state machine with defined transitions, evidence and behaviour when nothing happens. A gate that does not specify what happens on silence is not a gate; it is a delay.
The approval request is the real output of the workflow
When a system holds an action for a person, the artefact that matters is not the pending action but the request: a small, self-contained statement of what is proposed, why, on what evidence, what happens if it is approved, and what happens if it is not. That request is what a person reads at seven in the morning, so its quality determines every decision that follows.
A useful request answers four questions without opening another system: what is being proposed, in the business's own vocabulary; which records were read and which checks passed or failed; what the exposure is if the proposal is wrong; and what the system does next, so the approver chooses between defined outcomes rather than guessing.
It also records the identity of the requester, because a request raised by a service identity differs from one raised for a named commercial manager, and the difference decides who may approve it. Our renewal demonstration follows this pattern: the decision is written to an approval request, then audited separately.
Escalation needs a clock, an owner and a default
Most approval processes assume the approver is present, attentive and able to decide. Real operations are none of those things: a commercial director is in meetings, on leave, or has left the company. An approval that waits indefinitely for someone who may never respond is the commonest cause of a workflow appearing to work while the business quietly stops using it.
Three things fix this, and all belong in the specification before the system goes live: a clock, stating how long the request may wait before it escalates; an owner, naming who receives it next and what authority that person holds; and a default, stating what happens if nobody responds, usually to do nothing and let the record show the request is still open. The default must be written down, because an unwritten default is decided by whoever writes the code.
The exception queue is where the operating cost lives
Designers spend their attention on the successful path, the path easiest to demonstrate and least costly to run. The cost of an automated workflow is concentrated in the cases it cannot handle, and without a home they surface as complaints, as silent workarounds, and as the manual process that never went away.
An exception is not a failure state. It is a routing decision, and it deserves the same design attention as the main path. Each exception type needs a name, an owner, a time limit, the evidence needed to close it and a defined next state. The queue is also the best diagnostic the system produces: one concentrating in a single type shows where the process definition is incomplete. That concentration is treated in managing exceptions before they become expensive failures.
The question is not whether the system asked for permission. It is what happened while it was waiting for the answer.
Audit has to reconstruct the decision, not just the action
An audit record showing that a message was sent on a given date proves very little. A record showing which rules were evaluated, in which version, what each returned, which records were read, what the approver saw and what they decided reconstructs the decision. Only the second kind survives a serious question three months later, because the first cannot explain itself.
This is easier when the rules driving the workflow are stored as data with versions, severities and owners rather than embedded in prompt text, so a rule changed on a Tuesday can be explained by pointing at the version in force on Monday. Our demonstration works this way: a small numbered rule set, each rule versioned, with the outcome and the records it read captured on every evaluation. The wider discipline is in building auditability into AI-enabled business processes.
A sequence for introducing approval gates
- Classify every action by consequence and reversibility, and write the classification down where the approver can see it.
- Define the states, the transitions and the owner of each state, including the state a request is in when nobody has responded.
- Specify the request content, and check that an approver can decide from it without opening another system.
- Give every exception type an owner, a time limit and a closing condition, and make the queue a daily review item with a named person.
- Test the failure paths deliberately: a partial write, a duplicated request, a rule changed mid-flight, an approver who never replies.
The measures to review are the size and age distribution of the exception queue, the proportion of requests decided within the agreed time limit, the number of actions reversed after approval, and how long the evidence for a named decision takes to produce.
Approval and exception handling determines whether an agentic workflow can be operated by someone other than its authors, the discipline described in enterprise AI deployment. A working instance of the pattern, on synthetic data, is in our renewal demonstration.