There is plenty of discussion about making AI agents more autonomous. But to me, autonomy does not mean acting as often as possible. It also means recognizing situations where an action should wait.
Incomplete information. A request outside the mandate. Excessive risk. Required approval. These cases may be less impressive in a demonstration, but they deserve a central place in designing a system for real work.
An answer and an action do not carry the same consequences. Preparing a draft leaves an opportunity for review. Changing a record or sending a commitment to a customer already changes something in the business.
Autonomy starts with a clear mandate.
The team defines the goal and boundaries of the mandate, which it needs to be able to revise or withdraw. It specifies what the agent may access, propose and execute. Which account does the action apply to? Which fields may it change? Which decisions remain with a person?
A general instruction such as “handle customer requests” leaves too much room for interpretation. A useful mandate defines scope, conditions and boundaries. Those boundaries need to be checked by the system authorizing the action; they should not depend only on how a model phrases its response.
A stop needs a reason people can understand.
An agent may prepare a proposal without having all the conditions needed to execute it. That distinction needs to be visible. A confident-sounding response does not establish that the record, permissions or rules have been checked.
We can define several stopping situations, each with a different next step. Some need additional information. Others need approval. An action outside the mandate should stay blocked, even when it seems technically possible.
Insufficient information: identify what is missing before continuing.
Ambiguous reference: present the options and ask for clarification.
Outside the mandate: do not execute, and involve the appropriate owner.
High risk or required approval: prepare the record for a human decision.
Check the conditions before acting
01Missing informationIdentify what is needed.
02Ambiguous referenceConfirm the correct record.
03Outside the mandateBlock the action and hand it over.
04Approval requiredPrepare the decision for the right person.
If a condition is not met, pause the action and prepare a clear handoff.
An example: changing an order already being prepared.
Consider an illustrative scenario. An email asks to change an order in progress. The agent finds a matching record and prepares the change. That is not enough to authorize it. The requester’s identity, current order status, applicable terms and approving person’s role still need to be checked.
If preparation has already started, several records match or the change exceeds the mandate, the workflow should pause the action. The agent can gather useful information and present a clear proposal. The record should not imply that a change is complete while it is awaiting a decision.
Approval then applies to a specific action. If information changes before execution, its conditions need to be checked again. A previous approval should not become general permission to carry on.
Ask for help without abandoning the work.
A simple “I can’t do that” does not always give the team what it needs. A useful handoff describes the request, information consulted, prepared proposal and condition preventing progress.
It also identifies who needs to decide and what state the record will remain in while waiting. The person takes over prepared work with uncertainty made visible. An approval request should not disappear into a notification with no owner.
A wrong answer is an error. A wrong action can become an incident.
Evaluate useful actions and useful stops.
An agent completing a task should be assessed on the quality of its result. We also need to examine cases where it should not have acted. Did it block a request outside its mandate? Identify missing information? Present an actionable request for help? Avoid repeating an action already performed?
Testing should also examine unnecessary stops. A system that blocks everything slows the work down. The goal is useful scope, explicit conditions and understandable decisions, rather than the greatest number of actions or refusals.
For a first pilot, I would favour representative situations with expected actions and stops defined alongside the business team. We observe errors, unjustified blockers and the quality of recovery. Autonomy becomes behaviour to validate, rather than an impression created by a demonstration.
Questions to ask before delegating
✓ What is the agent’s exact mandate, and which actions are prohibited?
✓ Which information and permissions must be checked before each action?
✓ Which cases require a stop, clarification or approval?
✓ Who takes over the record, with what information and what status while waiting?
✓ How will we test unjustified actions, unnecessary stops and recovery after approval?
