When to give an AI agent real authority, and how to bound it.

Most evaluation of agentic tooling focuses on capability: can it read the thread, find the record, draft the reply, update the field. Capability is the easier half, and it is improving quickly enough that it is rarely the deciding factor for long.

Authority is the harder half and it is a business decision rather than a technical one. It asks what the agent is permitted to do without a person confirming, and it is answered by consequence rather than by confidence. A system that is right nine times out of ten is excellent at drafting and unacceptable at issuing refunds.

Keeping the two separate clarifies a lot of confused conversations. "Can it do this?" and "should it be allowed to do this unsupervised?" have different answers, different evidence and different owners.

A practical framing: authority should be proportional to how quickly and cheaply a mistake can be found and undone — not to how often the system is right.

Treating this as on or off forces a bad choice between a tool nobody uses and a tool nobody trusts. In practice there are several rungs, and most useful deployments sit in the middle for a long time.

From least to most authority:

• OBSERVE

  The agent reads and summarises. It changes nothing. Useful for triage and research, and the only level where being wrong costs nothing but attention.

• DRAFT

  The agent prepares work a person sends. The person is the control, which only holds if they genuinely review rather than approve by habit.

• ACT REVERSIBLY

  The agent changes things that can be changed back cheaply: setting a status, assigning an owner, creating an internal record, scheduling. Mistakes here are recoverable.

• ACT IRREVERSIBLY

  The agent does things that leave the building or commit the business: sending to a customer, moving money, changing a price, promising a date. This rung needs justification rather than permission by default.

These are properties of the action, not of the model. The same agent can hold different authority for different actions in the same process, and usually should.

Deciding the rung is the policy. The boundary is the implementation, and it needs to hold when the agent behaves unexpectedly rather than only when it behaves as designed.

Three mechanisms do most of the work. Scope limits what the agent can reach at all. Rate and volume limits prevent a wrong decision becoming a thousand wrong decisions before anyone looks. And a stop gives a person a way to halt it without an engineer.

• SCOPE

  The narrowest set of systems, records and fields the agent needs. Read access is not free: an agent that can read everything can leak everything into a context it should not.

• VOLUME AND RATE

  A ceiling on how many actions it may take before a person confirms. This is what converts a bad decision into a small incident rather than a large one.

• AN OFF SWITCH

  A control an operations person can use immediately, without a deploy. If stopping the agent requires the person who built it, it is effectively unstoppable at 6pm on a Friday.

• A LEGIBLE TRAIL

  What it did, on what basis, and what it saw. Not for compliance theatre — for the moment somebody has to explain an action to a customer.

• AN ESCALATION ROUTE

  Where the agent puts work it should not handle, and who owns that queue. An agent with no route for uncertainty will either guess or stall silently.

The most common safeguard is a person approving the agent's output. It is also the safeguard most likely to be theatre, because review degrades predictably: when the output is usually right, approving becomes automatic, and the reviewer becomes a button rather than a check.

A review step is real when three things are true. The reviewer can see why the agent proposed what it did, not just what it proposed. Rejecting is as easy as approving, and rejected items go somewhere defined. And the rejection rate is visible — a review that has never rejected anything is not evidence of quality, it is an absence of evidence.

1. 01

   Genuine check

   Owner

   The reviewer

   Advances when

   Items are approved, rejected and corrected with a visible rate

2. 02

   Degrading

   Owner

   The reviewer, nominally

   Advances when

   Rejection rate falls toward zero while volume rises

   Ends when

   Becomes a formality nobody notices has changed

3. 03

   Formality

   Owner

   Nobody in practice

   Advances when

   Restored only by a visible failure

   Ends when

   An error reaches a customer and the review is found to have approved it

4. 04

   Removed deliberately

   Owner

   The process owner

   Advances when

   Replaced by a limit and a monitored exception queue

Authority is better granted incrementally, against observed behaviour on real work, than decided once in advance. The sequence below is deliberately slow at the start and unremarkable afterwards.

1. 01

   Name the action, not the role

   Decides

   Which specific action is being delegated?

   Output

   One action, scoped, rather than a job title handed to software.

2. 02

   Score it on the four properties

   Decides

   How reversible, detectable, wide-reaching and judgement-heavy is it?

   Output

   A defensible starting rung.

3. 03

   Run it at observe or draft on live work

   Decides

   What does it actually get wrong, and how wrong?

   Output

   A real error profile rather than an expectation.

4. 04

   Build the boundary before raising the rung

   Decides

   What are the scope, the limit, the stop and the escalation route?

   Output

   Controls that exist before they are needed.

5. 05

   Raise one rung and watch the rejection rate

   Decides

   Is the review still rejecting things?

   Output

   Evidence that the control is alive rather than assumed.

6. 06

   Review the exception queue on a schedule

   Decides

   What is the agent handing back, and is anyone dealing with it?

   Output

   An owned queue instead of an accumulating one.

An agent that only observes can be left alone. An agent that acts cannot, and the difference is usually missing from the business case. Raising the rung does not simply increase what the deployment is worth; it creates recurring work somebody has to be given time for.

That work has three parts. Someone reviews the exception queue on a schedule, which means the queue needs an owner with capacity rather than an owner in name. Someone watches the error profile for drift, because the systems the agent reads keep changing — a field is renamed, a form gains an option, a category quietly stops being used — and the agent will carry on acting on the world as it was. And someone owns the decision to lower the rung again, which is the control that almost never gets built, because nobody designing a rollout expects to need it.

The drift point deserves particular attention, because it is the failure that looks like nothing. A deterministic integration breaks loudly when a field disappears. An agent interpreting the same record will often continue, producing output that is structurally valid and quietly wrong, and the volume limit is then the only thing standing between that and a week of it.

None of this argues against granting authority. It argues for counting the supervision as part of the cost, so that the comparison being made is the honest one: not the agent against the manual work, but the agent plus its standing obligations against the manual work.

None of these is permanent. They are conditions that should be fixed before authority is granted, rather than reasons to avoid agents altogether.

• THE PROCESS IS NOT AGREED

  If two people would handle the case differently, delegating it to an agent picks one of them silently. Settle the process first.

• THE DATA IS NOT MAINTAINED

  An agent acting on records nobody keeps current produces confidently wrong output rather than obviously wrong output.

• NOBODY OWNS THE EXCEPTIONS

  An unowned exception queue lets work disappear faster than it did before, which is a worse outcome than the manual process.

• IT CANNOT BE EXPLAINED

  If the business could not explain the action to the customer it affected, it should not be taken without a person.

1. Capability and authority are separate decisions: whether an agent can do the work is a technical question, whether it may do it unsupervised is a business one.
2. Authority should be proportional to how quickly and cheaply a mistake can be detected and undone, not to how often the system is right.
3. Treat authority as four rungs - observe, draft, act reversibly, act irreversibly - and set it per action rather than per agent.
4. Reversibility, detectability, blast radius and judgement content are properties of the action that decide how high it can sit.
5. A boundary is scope, a volume limit, an off switch an operations person can reach, a legible trail and an owned escalation route.
6. A human review step is only a control if the reviewer can see the reasoning, rejecting is as easy as approving, and the rejection rate is visible.