TL;DR

  • Scope autonomy by reversibility, consequence, explicit authority, verification, and current context.
  • Approve concrete commitments with visible details; a remembered preference is not permission.
  • Use the proposed autonomy ladder per action, keeping prohibited decisions outside the agent’s scope.

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.

Before selecting an autonomy level, define the workflow and its exception paths so the permission model refers to a specific operating process.

To check those permissions under pressure, test the boundary between completion and authorization with denied actions, stale approvals, and conflicting records.

1. Is the action reversible?

Give an agent more room to act when the prior state can be restored reliably, promptly, and at acceptable cost. Check downstream effects before calling an action reversible. A draft, calendar hold, or record edit can still expose information, affect another person, or trigger a separate automated process.

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?

Set autonomy according to the consequence of an incorrect action, not simply whether a tool permits it. Consider financial commitment, other people’s interests, access changes, and recovery options. Define which actions are routine, which require a specific approval, and which remain outside the agent’s authority regardless of confidence.

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?

Authority should name the goal, allowed actions, systems, spending limits, affected people, and duration. A broad request to handle a problem does not settle each of those boundaries. Let the agent propose additional access or a commitment, but require an authorized decision before expanding the original scope.

In this hypothetical example, 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?

Allow autonomous action only with a suitable way to verify its outcome. Check confirmation from the system responsible for the result and preserve that evidence in a readable receipt. Finishing a plan, submitting a request, or receiving a plausible message does not by itself establish that the intended change occurred.

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?

Check whether the facts that authorize the action are complete, current, and consistent. A model may understand an instruction while relying on an old price, the wrong account, or an expired approval. When a missing fact could change permission or consequence, obtain that fact or route the decision for review.

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

Choose a level of autonomy for each class of action, from observation and preparation to execution within explicit limits. The ladder below is a proposed design aid, not an industry standard or maturity score. Use the lowest level that removes useful work while preserving appropriate authority, verification, and recovery.

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

Ask for approval when the proposed action is concrete enough to evaluate. Show the item, price, recipient, timing, and relevant limits rather than requesting broad permission without context. A recurring rule can replace repeated approvals later, but it should remain explicit, inspectable, revocable, and limited to the agreed action.

The better moment for approval is when the meaningful decision becomes concrete.

Do not ask, “May I make purchases?”

For example, using hypothetical prices and limits: “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 a policy explicitly, using these illustrative thresholds:

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

Build autonomy through a record of useful actions performed inside clear limits. Make outcomes visible, explain exceptions, and retain a practical way to revoke access or change policy. More freedom should follow evidence about a particular workflow, not a general claim that the agent is capable or trustworthy.

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.

Frequently asked questions

Should an AI agent ask before every action?

Not necessarily. Define a permitted class of routine actions with clear limits and verification. Ask for approval when a proposed action exceeds those limits, relies on missing context, or creates a commitment the standing rule does not cover.

Can the agent infer permission from past preferences?

A preference can help rank options. It does not automatically authorize spending, disclosure, or action on another person’s behalf. Convert repeated decisions into a standing rule only through an explicit authorized choice.

Is this autonomy ladder a safety certification?

No. It is a proposed product-design framework. A real implementation still needs enforceable permissions, workflow-specific tests, monitoring, and accountable review. Selecting a level does not establish that those controls work.