“We will keep a human in the loop.”
It is one of the most common promises made when an organisation begins using AI agents.
It sounds reassuring. It also leaves the most important question unanswered.
Where in the loop?
If a person checks every action, the agent is not meaningfully autonomous. It is a fast worker attached to a slow approval queue.
If the person only appears after something has gone wrong, the oversight is too late to be useful.
And if nobody has decided what the agent may do, “human in the loop” often means sending everything to the same manager just in case.
That does not create safety.
It creates supervision.
Human involvement should follow the decision
The useful boundary is not between work done by humans and work done by AI.
It is between decisions the organisation has already made and decisions it has not.
Imagine an agent preparing a customer proposal.
The business may already have decided that every proposal must use the approved service packages, protect a minimum margin and include standard legal terms. It may have decided that sales can reduce scope, move the start date or choose between three approved payment schedules without asking.
The agent should act on those decisions.
But the customer may request an unusual liability term. The available delivery window may require displacing another commitment. The deal may only work below the protected margin.
Those situations require authority or judgement the agent does not have.
It should ask.
An agent should not ask a person to remake a decision the organisation has already made. It should ask when the work reaches a decision that still belongs to a person.
Act, ask and stop
Since writing this piece I've settled on a third behaviour that completes the model.
Act when the organisation has already decided. Ask when a genuinely new decision or exception changes the commitment. Stop when the agent lacks the context, authority or safety required to continue.
Stop is not a failure state. An agent that cannot verify which customer it is dealing with, cannot establish the current price or cannot confirm a protected control should not press on and guess. Stopping, and saying why, is correct behaviour.
The two failure modes sit on either side of this boundary. Approval Addiction is too many routine checks: a human review after every meaningful action, until the agent works briefly and waits for a person. Permission Inflation is the opposite drift: every unclear decision escalating upwards because nobody has defined who may decide what. I cover both in the six AI agent failure modes.
Act, ask and stop is also question six of the six-question AI loop specification: the guardrails and limitations the agent works within.
Three different things often get called an escalation
Not every question from an agent is the same. Treating them as one category is how leaders end up reviewing everything.
There are three useful distinctions.
1. A prior decision
The organisation has already settled the matter.
The margin rule exists. The approved tone exists. The refund limit exists. The handoff requirement exists. The agent has enough authority to apply it.
This is not a reason to ask.
If the agent keeps escalating prior decisions, either the specification is unclear, the relevant context is not reaching the agent or the organisation does not trust the boundary it has set.
All three are fixable. None require a manager to keep answering the same question.
2. A genuinely new decision
The situation falls outside what the organisation has considered.
There is no established rule, no delegated authority and no obvious answer that can be inferred without changing the organisation’s position.
The agent should make the gap explicit, identify who owns it and present the decision well.
“We have not decided” is not a system failure. It is valid operating guidance.
3. An exception
The rule is clear, but an authorised person may choose not to apply it in this case.
This is different from an open decision.
The business may know that proposals below a particular margin are normally rejected while still allowing a commercial director to approve a rare strategic deal.
The agent should not pretend the rule is unclear. It should say which boundary would be crossed, why the exception is being requested and who has authority to approve it.
Most importantly, an approved exception should not silently become a new rule.
An exception is not automatically a lesson
This distinction matters because AI systems can observe decisions and adapt quickly.
Suppose a sales director approves a low-margin proposal for a customer that opens an important market. The next similar-looking opportunity arrives.
Should the agent assume the margin floor has changed?
No.
The first decision may have been a one-off exception. It may be the beginning of an experiment. Or it may reveal that the commercial specification should change.
Those are three different organisational commitments.
The agent can record what happened and surface the pattern. An accountable person decides whether the business has learned a new rule.
People approve exceptions. Evidence supports experiments. Owners change the specification.
Without that separation, a learning agent can gradually replace the organisation’s strategy with a trail of pressured decisions.
What should the agent do before it asks?
Escalation should not be a way for the agent to hand unfinished thinking to a person.
When it reaches a genuine boundary, it should assemble the decision.
A useful request should explain:
- what has happened;
- what outcome the work is trying to achieve;
- which existing rule, boundary or open question is involved;
- why the agent cannot proceed safely;
- the viable options;
- the likely trade-offs and affected people;
- who has authority to decide; and
- what will happen after the decision is made.
The agent carries the context and coordination. The person provides the judgement and authority.
Compare these two messages.
The customer wants a discount. What should I do?
And:
The customer has asked for a 12 per cent reduction. The proposal is currently at the standard package and would fall below the protected margin. We can keep the price, reduce the reporting scope, or seek a commercial exception. Reducing scope keeps the margin and delivery capacity within the current specification. The sales director owns exceptions below the margin floor.
The second message still needs a human decision if the exception is pursued.
But it does not require the human to reconstruct the entire piece of work before making it.
Decision gates are better than approval gates
An approval gate asks a person to confirm that work can move on.
A decision gate brings in a person because the work has reached a choice that changes something important.
The distinction sounds small, but it changes the design of the workflow.
Approval gates tend to accumulate. They are added whenever someone feels nervous. Over time, the person becomes responsible for spotting every possible problem in work they did not create.
Decision gates begin with explicit boundaries.
Inside the boundary, the agent acts. At the boundary, it stops. The person is not checking the agent’s homework; they are exercising authority the organisation has deliberately reserved for them.
This is decision-gated autonomy.
It does not remove human oversight. It concentrates human attention where it has the most value.
The four parts of a useful decision boundary
You do not need to predict every edge case. You need enough clarity for the agent to recognise when it has left familiar ground.
For each important boundary, define four things.
The rule
What must normally be true?
For example: the proposal must remain above the protected margin and use approved service terms.
The room to move
Which trade-offs can the agent or team make without asking?
It may be able to remove optional scope, change timing or choose an approved package.
The owner
Who has the authority and accountability to decide beyond that boundary?
Use a named role, not “leadership” or “the business.”
The decision brief
What evidence and options must be present when the matter is escalated?
This prevents the owner from becoming the person who has to find all the information as well as make the decision.
What about sensitive or high-risk work?
Decision-gated autonomy does not mean every agent should be given broad access and allowed to run until it feels uncertain.
Some controls sit outside the business specification.
Identity and access management determine which systems the agent can reach. Security controls protect data and infrastructure. Legal and compliance requirements may require particular records, reviews or approvals. Runtime monitoring helps the organisation see whether the system is behaving as intended.
Those controls still matter.
The specification answers a different question: given that the agent is allowed to perform this work, what does the organisation want it to achieve, which business rules apply and when must a person make the call?
Clear business boundaries complement technical and regulatory controls. They do not replace them.
How do you know whether the agent is asking too much?
Look at its questions over a week or a month and sort them into the same three groups.
We had already decided this
Improve the specification or make sure the agent receives the relevant part of it before work begins.
Every repeated question in this group is a supervision cost the organisation should not have to keep paying.
We had not decided this
Add it to the open decisions. Decide whether it needs an answer now, can be worked around or should remain a deliberate boundary.
Do not hide the uncertainty inside vague instructions.
This was a genuine exception
Check that the correct person made the decision and the reason was recorded. Then decide whether the exception remains isolated, becomes an experiment or suggests a change to the specification.
The goal is not to drive the number of questions to zero.
It is to remove avoidable questions while improving the quality of the ones that remain.
How this works in a spec-driven organisation
A spec-driven organisation gives each important product, service and repeated way of working a living specification.
People own the outcomes and the meaning of those specifications. People, agents and systems work from the decisions already captured inside them. Open decisions are visible rather than left as gaps for AI to fill.
This makes autonomy cumulative.
When a recurring decision is settled, every future person and agent can use it. When a new situation appears, it reaches the right owner with context. When an exception is approved, the organisation remembers why without pretending the underlying rule automatically changed.
One person’s judgement can guide much more work without requiring that person to personally touch every task.
That is the amplification specifications make possible.
Bottom line
An AI agent should act when the organisation has already made the decision and delegated authority inside clear boundaries. It should ask when the work reaches a genuinely new decision, needs an authorised exception or would cross a protected boundary.
“Human in the loop” is too vague to design an operating model around.
The useful question is which decisions people should make once, which decisions an agent can apply repeatedly and which moments still require human judgement.
The goal is not to remove people from the loop.
It is to stop using people as the loop.
BusyWork Dispatch helps businesses turn AI ideas into working software, automations and agents using specifications that make purpose, rules and open decisions explicit. The Workbook preserves the context; Dispatch connects it to real work and the people who own the boundary decisions. See how BusyWork works or book a call with Ben.
