An AI agent that asks permission before every small step is not much of an agent.
An AI agent that acts without meaningful limits is not much of a product people can trust.
The useful territory sits between those extremes.
As software moves from generating answers to completing work, product teams need a practical way to decide which actions should happen automatically, which should wait for approval, and which should never be delegated at all.
The answer cannot be a single universal permissions screen. Authority depends on the action, the context, the consequence, the person, and the system’s ability to recover when it is wrong.
My working framework begins with five questions.
1. Is the action reversible?
Reversibility is the cleanest first boundary.
Drafting a message is easier to undo than sending it. Holding an appointment is easier to undo than paying a deposit. Adding an item to a cart is easier to undo than placing the order. Preparing a file for deletion is easier to undo than permanently removing it.
Agents should generally have more freedom on work that can be reversed cleanly and cheaply.
This does not mean every reversible action is harmless. A draft can expose sensitive information if it is shared with the wrong collaborator. A temporary calendar hold can create confusion. A change to a CRM record can trigger downstream automation.
Still, reversibility gives us a useful default:
Autonomy should expand as the cost of restoring the prior state approaches zero.
Products should also be honest about whether reversal is real. “Cancel” is not the same as “undo” when a vendor charges a fee, a customer has already seen the message, or the deleted data cannot be recovered.
2. What is the consequence of being wrong?
Two actions can look technically similar and carry very different risk.
Sending a routine scheduling confirmation to a known vendor is not the same as sending a legal response. Ordering the same household filter at the usual price is not the same as selecting a medical device. Moving a low-priority internal meeting is not the same as canceling a customer commitment.
The agent needs a consequence model, not merely a tool permission.
A useful classification might include:
- Low consequence: easy to verify, easy to reverse, little reputational or financial impact.
- Moderate consequence: affects another person, creates a temporary commitment, or introduces a meaningful cost.
- High consequence: moves substantial money, creates legal or safety exposure, changes access, affects health, or is difficult to reverse.
- Prohibited: outside the system’s authority regardless of model confidence.
The product should make these categories visible. A person should understand why one action happens automatically while another pauses.
3. Is the authority specific or inferred?
A person saying “handle this” does not grant unlimited authority over everything connected to the request.
Suppose someone asks an agent to plan a family trip. The agent may reasonably research flights, compare lodging, map activities, and prepare an itinerary. It should not assume that the request authorizes a $7,000 purchase, a message to the children’s school, or access to another family member’s health information.
Authority should be scoped to:
- the stated objective;
- the systems required to pursue it;
- the spending or commitment limit;
- the people whose information may be used;
- the time period for which the authority remains active;
- the actions explicitly excluded.
The agent can propose an expanded scope. It should not quietly invent one.
This becomes especially important when memory is involved. A system may remember that the household usually prefers direct flights or that a business typically approves expenses below a certain amount. A remembered preference is not automatically a standing authorization.
Preference informs judgment. Permission enables action. The product must keep them separate.
4. Can the result be independently verified?
An agent should have more freedom when success can be checked against an external source of truth.
A calendar event can be confirmed through the calendar provider. A payment can be confirmed by the processor. A shipment can be confirmed by the carrier. A work order can be confirmed by the customer’s acceptance state.
Verification matters because the agent’s own completion of a plan is not proof that the real-world outcome occurred.
A system that sends an email and declares the issue resolved has confused activity with result. A system that submits a form and waits for the acceptance response understands the job more clearly.
Every consequential autonomous action should produce a receipt that names:
- what was attempted;
- what changed;
- the external confirmation received;
- any cost or commitment created;
- what remains unresolved;
- how the person can inspect or reverse the action.
Autonomy without verification is just confidence at a distance.
5. How certain is the context, not just the model?
Model confidence is only one source of uncertainty.
The agent may understand the sentence perfectly and still be missing a fact that changes the decision. The calendar may be incomplete. The price may have changed. A household preference may be outdated. A customer record may belong to the wrong account. The instruction may conflict with a policy the user did not mention.
The right question is not only, “How sure is the model about its interpretation?” It is also:
- How complete is the relevant context?
- How recent is the information?
- Which assumptions are being made?
- Are the systems of record consistent?
- Is another person’s consent required?
- Would a reasonable person expect to be asked here?
A capable agent should recognize when uncertainty is operational rather than linguistic.
“Needs review” is not a failure state. It is a sign that the product understands the boundary of its authority.
A practical autonomy ladder
These questions can become a simple product ladder.
Level 0: Observe
The agent can read permitted information, identify patterns, and surface needs. It cannot change external state.
Level 1: Prepare
The agent can research, draft, organize, calculate, and assemble options. A person approves the final action.
Level 2: Act within explicit limits
The agent can complete reversible or low-consequence actions inside a defined policy, such as scheduling within approved windows or reordering a familiar item below a spending cap.
Level 3: Act and notify
The agent can complete recurring, well-understood actions and provide an immediate receipt. The person retains a clear undo or escalation path.
Level 4: Escalate by exception
The agent owns an ongoing workflow, acts inside established boundaries, and involves a person only when a policy, uncertainty, or consequence threshold is crossed.
Level 5: Never delegate
Some decisions remain human because they involve rights, safety, intimate relationships, irreversible consequences, or authority the system should not possess.
The mistake is treating Level 4 as the goal for every task. Good product design chooses the lowest level that removes meaningful work while preserving appropriate control.
Approval should happen at the decision, not at the beginning
Many permission systems ask for broad access before the user understands what the agent will do. That is administratively convenient and psychologically weak.
The better moment for approval is when the meaningful decision becomes concrete.
Do not ask, “May I make purchases?”
Ask, “This is the same filter ordered last time, the price is $41.80, delivery is Friday, and it is within your $50 household-supplies limit. Place the order?”
Over time, the user may decide that this exact class of action no longer needs approval. The system can offer that policy explicitly:
Automatically reorder previously approved household supplies when the price is within 10 percent of the last order and the total is below $50.
Now autonomy is legible. The user can inspect it, edit it, or revoke it.
Trust grows through bounded success
People will not trust agents because a settings page says the product is safe. Trust will grow through a sequence of visible, appropriately bounded actions.
The agent prepares useful work. It pauses before the consequential step. It explains the decision clearly. It follows the result into the external system. It produces a receipt. It admits when it cannot finish. It remembers the correction without converting it into unauthorized freedom.
That behavior earns a larger operating envelope over time.
The future of agentic software is not maximum autonomy. It is earned autonomy: enough authority to remove the burden of coordination, with boundaries strong enough that the person never has to wonder what the system might do next.