The AI Agent Authority Ladder

How much should an AI agent actually be allowed to do?

An AI agent might be capable of: Reading your CRM. Searching documents. Drafting emails. Updating records. Creating tasks. Sending messages. Changing opportunity stages. Triggering workflows. Taking actions in other software.

But capability is not permission. The important question is not: What can the AI do? It is: What should this AI be allowed to do for this particular job?

The Agentic Selling Authority Ladder gives businesses a practical way to think about that decision. It runs from read-only access through to controlled independent action, with escalation available throughout.

Capability and authority are different.

Suppose an AI system can: Read an incoming sales enquiry. Search your CRM. Draft a response. Send the response. Change the opportunity stage. Technically, all five actions may be possible. But your business might decide otherwise.

That is not limiting the usefulness of AI. It is designing the workflow.

1. READ

AI can access and understand approved information.

This is the lowest level of operational authority. The AI may be allowed to read: An enquiry. A CRM record. Meeting information. An email thread. Approved documents. Product information. Internal knowledge. Account history. Defined public information.

But it does not change anything. It does not contact anybody. It does not create a task. It does not alter a record. It gathers and understands.

Read-only does not mean low value.

Consider a Meeting Preparation Agent. Its entire job could be: Identify tomorrow's sales meetings. Gather relevant approved account context. Prepare a concise briefing. That may save somebody from searching: CRM. Email. Meeting notes. Documents. Previous actions. The agent does not need permission to change a single system. It can still be useful. Read-only agents matter.

Example: Account Research Agent

The agent can: Read CRM history. Read approved previous interactions. Search agreed internal knowledge. Gather defined external context. It cannot: Change the CRM. Create tasks. Contact the customer. Change opportunity information. Its output is simply: Here is the context you need. For some jobs, that is enough.

2. RECOMMEND

AI can suggest what should happen next.

Now the AI moves beyond gathering information. It interprets the context and makes a recommendation. For example: This enquiry appears to belong to the Enterprise team. This opportunity appears to have no next action. This account may need review. This CRM record may be a duplicate. This customer appears to be waiting for us. This meeting may need technical support. Nothing happens automatically. A person decides whether to follow the recommendation.

Recommendation is useful when judgement still belongs to a person.

Imagine an AI Lead Routing Agent. It reads: The enquiry. Company information. Existing relationship. Service requested. Routing rules. Then recommends: Assign to Sarah because this is an existing account and the enquiry relates to Service B. A person can accept or change that recommendation. The AI contributes understanding. The person retains the decision.

Recommendations should explain themselves where useful.

Instead of: Recommended action: Follow up consider: Recommended action: Complete the promised proposal update before contacting the customer. Reason: The meeting record shows our team agreed to send the revised document first. That gives the person something they can assess. The objective is not to make AI sound authoritative. It is to make the recommendation useful.

3. PREPARE

AI prepares the work. A person remains the operator.

This is where AI can remove substantial administrative work without independently taking the final action. The AI might prepare: An email. A CRM update. A proposal section. A meeting brief. A follow-up. A handover. A research brief. A task. A customer response. A person reviews it. Then the person decides what happens.

Preparation is often a strong starting point.

Suppose a salesperson finishes a meeting. AI could prepare: The meeting summary. CRM notes. Next actions. Customer commitments. Internal commitments. A follow-up email. But nothing is written or sent yet. The salesperson reviews the prepared work. Corrects anything necessary. Approves what should happen. This can deliver useful assistance while keeping important actions controlled.

Preparation also creates evidence.

If people repeatedly approve the AI's work unchanged, that tells you something. If they frequently correct it, that tells you something too. You can observe: Where AI performs well. Where context is missing. Which actions are predictable. Which situations cause mistakes. Where human judgement remains important. That evidence can inform whether any action should move further up the authority ladder.

4. ACT WITH APPROVAL

AI prepares the action and a person authorises it.

At this level, the AI is connected to the system that can perform the action. But the action waits for approval. For example: AI prepares a customer email. Person approves. AI sends it. Or: AI prepares a CRM change. Person reviews. AI updates the record. Or: AI prepares a task and proposed owner. Manager approves. AI creates and assigns it. The person is not manually recreating the action. They are approving it.

Approval should be meaningful.

A badly designed approval process can become: AI generates action. Human clicks approve. Human clicks approve. Human clicks approve. Human clicks approve. Eventually the human stops reading. That is not necessarily useful human control.

Ask: What does the approver need to see? Can they understand why the action is proposed? Can they easily change it? Can they reject it? Can they escalate it? Is approval required because the consequence justifies it? Or because nobody has thought through the workflow yet? Human approval should have a purpose.

Example: Follow-Up Agent

The agent identifies that a follow-up is appropriate. It gathers context. It prepares the message. It shows: Why the follow-up is due. What happened last. Who owes the next action. The proposed message. The salesperson can: Approve. Edit. Reject. Delay. Escalate. Only after approval does the system send anything.

5. ACT WITHIN LIMITS

AI can perform specific actions independently.

This is where greater autonomy begins. But it should not mean: "Do whatever you think is best." It means: The AI can perform clearly defined actions when agreed conditions are satisfied. For example: Create an internal CRM task. Apply an agreed internal classification. Add an approved note. Route a standard enquiry. Request missing internal information. Update a low-consequence field. Send a narrowly defined internal notification. The exact actions depend on the business.

Limits make autonomy useful.

An independently acting agent should have boundaries around things such as: Which actions it can perform. Which systems it can change. Which records it can change. Which customers or opportunities it can act on. What information it may use. Which values it may write. How often it can act. What conditions must be true. What conditions immediately require escalation. Autonomy without boundaries is not the objective. Controlled authority is.

Example: New Enquiry Agent

The agent may independently: Create an internal task. Apply an agreed enquiry category. Attach the enquiry to a clearly matched account. Notify the appropriate internal owner. But it may require approval to: Send an external response. Create a new account where a possible duplicate exists. Change commercially significant information. And it may be prohibited from: Agreeing pricing. Making contractual commitments. Inventing missing customer information. Different actions. Different authority.

6. ESCALATE

AI knows when to stop.

Escalation is one of the most important capabilities in an agentic workflow. An agent should not be expected to solve every situation. It should know when: Information is missing. Sources conflict. The request is unusual. The decision is outside its authority. The consequence is too high. The customer requests an exception. The agent cannot establish the correct account. The workflow has reached an agreed boundary. A sensitive situation occurs. A person needs to decide. Then it should stop.

Escalation is not failure.

Consider two agents. AGENT A: Always produces an answer. Even when information is unclear. AGENT B: Completes routine work when the situation fits its boundaries. When it does not, it says: "I cannot establish the correct action from the available information. Human review required." Agent B may be the more useful system. Knowing when not to act is part of useful agency.

Escalation needs a destination.

Do not define escalation as: "Ask a human." Define: Who? Salesperson? Sales manager? Account owner? Technical specialist? Finance? Operations? Shared review queue? And what should they receive? A useful escalation might contain: What happened. What the agent found. Why it stopped. What information conflicts. What decision is required. Relevant sources. That makes escalation part of the workflow rather than a dead end.

Escalation exists across the ladder.

It is not simply Level 6.

The visual ladder is useful. But there is an important nuance. An agent operating at READ may need to escalate because information is unavailable. An agent at RECOMMEND may need to escalate because the situation is outside its criteria. An agent at PREPARE may need to escalate because it cannot safely prepare the work. An agent acting with approval may flag an exception before requesting approval. An agent acting within limits must escalate when it reaches those limits. So think of escalation as an exit route running alongside the entire ladder.

The ladder is not a race.

Level 5 is not better than Level 3.

Businesses can easily fall into this thinking: Read-only AI is basic. Recommendations are more advanced. Preparation is better. Approval is nearly autonomous. Independent action is the goal. That is the wrong way to use the framework. The question is: What level of authority makes sense for this action? A high-consequence action may permanently remain at: PREPARE or: ACT WITH APPROVAL. That can be the correct design.

More autonomy is not automatically progress.

If an agent prepares excellent meeting briefs, there may be no reason to give it additional authority. Its job is preparation. If an agent identifies possible duplicate CRM records, there may be no reason to let it merge them independently. Its job may be recommendation. If an agent prepares commercial proposals, human approval may always be appropriate. The goal is not to climb. The goal is to place each action at the right level.

Authority belongs to the action.

Not the agent.

This is the most important part of the framework. Do not ask: "How autonomous is our Enquiry Agent?" Ask: What authority does it have for each action? For example:

One agent can sit on several levels at once. Authority belongs to the action, not the agent.

Build an authority map.

For every agent, list its actions. Then assign authority.

This is much clearer than writing: Autonomy: Medium. What does medium mean? The action map tells you what the system can actually do.

Start lower when uncertainty is higher.

If you are unsure whether an action should happen independently, you can begin with: RECOMMEND. Or: PREPARE. Then observe. How often is the recommendation correct? How often does a person change it? Which cases create problems? Which exceptions appear? What information is missing? How consequential are mistakes? You can use evidence from the workflow to decide whether authority should change.

Autonomy should earn its place.

An action might move from: PREPARE to: ACT WITH APPROVAL and eventually: ACT WITHIN LIMITS. But only if doing so genuinely improves the workflow. Do not increase autonomy simply because the system has been running for three months. Time is not evidence. Useful performance is.

Authority should be able to move down too.

Authority moves both ways. It is not an upward staircase.

Suppose an independently acting agent begins making more mistakes because: The sales process changed. A CRM field changed. A new product was introduced. The model changed. Customer behaviour changed. A data source became unreliable. A new exception appeared. The correct response may be: Move the action back to approval. Or preparation. Or recommendation. Authority should not only move in one direction.

Human in the loop is not one thing.

People often describe an AI system as: Human in the loop. But where is the person? Before the AI works? After it gathers information? Before a recommendation becomes an action? Before external communication? Only when something unusual happens? After the action for audit? Different workflows need people at different points. The Authority Ladder helps make that explicit.

Example: Meeting Preparation Agent

Gather account context: READ. Gather previous meeting information: READ. Identify outstanding actions: RECOMMEND. Prepare briefing: PREPARE. Change CRM: NOT REQUIRED. Contact customer: NOT REQUIRED. Missing account information: ESCALATE. This agent may never need more authority. And that is fine.

Example: CRM Agent

Read meeting output: READ. Identify relevant CRM changes: RECOMMEND. Prepare field updates: PREPARE. Update ordinary notes after approval: ACT WITH APPROVAL. Update agreed low-consequence internal fields: Potentially ACT WITHIN LIMITS. Change opportunity value: Could remain ACT WITH APPROVAL. Delete account: NOT PERMITTED. Possible duplicate: ESCALATE. Again, authority differs by action. This is a common pattern in AI CRM automation.

Example: Follow-Up Agent

Read opportunity history: READ. Determine who owes the next action: RECOMMEND. Prepare follow-up: PREPARE. Create internal reminder: ACT WITHIN LIMITS. Send standard customer follow-up: Perhaps ACT WITH APPROVAL. Make a new commercial promise: NOT PERMITTED. Sensitive customer response: ESCALATE. The fact that the agent can send an email does not mean every email should be independently sent.

Example: Research Agent

Search approved internal sources: READ. Search approved external sources: READ. Identify relevant context: RECOMMEND. Prepare account brief: PREPARE. Change CRM: NOT REQUIRED. Contact account: NOT REQUIRED. Conflicting information: ESCALATE. A research agent can be useful with almost no action authority.

Example: Sales Handover Agent

Read opportunity history: READ. Identify commitments: RECOMMEND. Prepare handover: PREPARE. Create internal handover task: ACT WITHIN LIMITS. Change owner: Potentially ACT WITH APPROVAL or ACT WITHIN LIMITS depending on process. Change commercial terms: NOT PERMITTED. Conflicting scope: ESCALATE. The authority map for an internal handover follows the consequence of each action.

Consequence matters.

Consider these actions: Prepare a meeting brief. Create an internal task. Change a CRM note. Send a customer email. Change an opportunity value. Agree a discount. Make a contractual commitment. They do not carry equal consequences. So why would they have equal authority? The greater the consequence, the more carefully you should consider: Approval. Validation. Boundaries. Logging. Escalation. Human judgement.

Reversibility matters too.

Ask: If this action is wrong, how easy is it to undo? An incorrect internal tag may be easy to correct. An inappropriate customer message cannot really be unsent. A changed CRM field may be recoverable. A commercial commitment may have much larger consequences. Reversibility is useful when deciding authority.

Visibility matters.

Ask: Will somebody notice if this goes wrong? An AI-generated internal briefing is visible to the salesperson. A background CRM change may be less visible. An autonomous workflow can perform many small actions without anyone noticing individual mistakes. That may require stronger monitoring. The less visible an action is, the more important observability can become.

Frequency matters.

An action performed twice a month and an action performed 10,000 times are different operational problems. Even a low error rate can matter when the action happens at scale. Authority decisions should consider: Frequency. Consequence. Reversibility. Visibility. Not simply whether AI appears capable of doing the task.

Think about authority before connecting the tool.

Do not: Connect the CRM with full permissions. Then decide what the agent should be allowed to change. Instead: Define the job. List the actions. Assign authority. Then provide the permissions required for those actions. Permission should follow the job.

Tool access should reflect the authority map.

If the agent only needs to: Read CRM records. Then it may not need write permissions. If it prepares emails but does not send them: It may not need independent send permission. If it can create tasks but not change opportunities: Those permissions should be different where the system allows it. Technical permissions should reinforce the workflow design. Do not rely only on: "Please don't do that."

Approval should happen at the right moment.

Suppose an agent: Researches an account. Prepares an email. Creates a task. Updates the CRM. Sends the message. Then asks: "Was that okay?" That is not approval. Approval needs to happen before the consequential action. Decide exactly which step requires it.

Escalation should happen before guessing.

An agent encounters: Missing information. Conflicting records. An unusual request. An ambiguous account. A decision outside its authority. The workflow should not reward it for always completing the task. Sometimes the correct outcome is: STOP. Then: ESCALATE.

What should determine an AI agent's authority?

Five questions help you decide. There are no scores to add up.

There is no universal numerical formula. These questions help you make a practical decision.

Do not turn this into an autonomy score.

You could create: Consequence = 4. Reversibility = 3. Certainty = 7. Agent score = 72. Recommended autonomy = Level 4. It would look precise. But the precision would be invented. Different businesses have different: Risk tolerance. Processes. Customers. Systems. Controls. Regulatory obligations. Commercial consequences. Use the framework to structure a decision. Not to disguise judgement as mathematics.

A practical authority review

For every action, write: ACTION: What will the AI do? PURPOSE: Why does it need to do it? CONSEQUENCE: What happens if it is wrong? REVERSIBILITY: Can we undo it? VISIBILITY: Will we know? AUTHORITY: Read, Recommend, Prepare, Act with Approval or Act within Limits? ESCALATION: When must it stop? PERMISSION: What technical access is required? That gives you a usable authority map.

What about customer-facing actions?

Customer-facing activity deserves particular attention because: The customer experiences the action directly. Mistakes can affect trust. Context can be subtle. Messages can create commitments. An incorrect action may not be reversible. That does not mean: AI must never communicate with customers. It means customer-facing authority should be deliberately designed. A business may begin with: PREPARE. Then: ACT WITH APPROVAL. And only introduce limited independent communication for narrowly defined situations if there is a good reason.

What about internal actions?

Internal does not automatically mean harmless. An agent could: Change opportunity data. Reassign ownership. Alter pipeline stages. Create large numbers of tasks. Change forecasting information. Modify customer records. Internal actions can affect important business processes. Again: Authority belongs to the action.

What about read access?

Read access also deserves thought. An agent may not need action authority to cause problems if it has inappropriate information access. Ask: Which customers? Which records? Which documents? Which fields? Which systems? Which historical information? Which confidential information? The agent's information boundary is part of its authority.

The Authority Ladder is part of the job description.

When defining an AI agent, write down: What it is responsible for. What information it needs. What actions it can perform. Then place each action on the ladder. This turns: "We want a fairly autonomous sales agent." into something much more useful: "The agent can independently create internal tasks, can prepare customer communications for approval, cannot alter pricing, and must escalate commercial exceptions." Now you can build around it. See our guide to writing a job description for an AI agent.

The Authority Ladder is part of testing too.

Testing should not only ask: Did the agent produce the right answer? Also test: Did it stay within its authority? Did it ask for approval when required? Did it avoid prohibited actions? Did it escalate when the situation fell outside its boundaries? Did it use only approved information? Did it stop when the job was complete? A capable agent that ignores its boundaries is not performing the job correctly.

The Authority Ladder is part of monitoring.

After deployment, look at: Actions completed. Actions approved. Actions changed by people. Actions rejected. Escalations. Unexpected actions. Permission failures. Cases where escalation should have happened but did not. Cases where approval adds no value. This can show where the workflow needs adjustment.

You can move different actions independently.

Imagine six months later. Your Follow-Up Agent performs well. You might decide: Internal reminder creation: ACT WITHIN LIMITS. Customer email: Still ACT WITH APPROVAL. Commercial commitment: Still NOT PERMITTED. Sensitive response: Still ESCALATE. You do not need to promote the whole agent. You adjust the authority of individual actions.

A useful agent is not the one with the most freedom.

It is the one that: Has a clear job. Has the information it needs. Has appropriate permissions. Performs useful work. Knows its limits. Escalates when necessary. And operates at an authority level that makes sense for the consequence of each action. That may involve considerable autonomy. Or almost none. Both can be agentic.

The goal is not to reach the top. The goal is to give AI enough authority to be useful while keeping control where it matters.

Frequently asked questions

Do not ask how autonomous your AI can be.

Ask how autonomous it needs to be.

Start with the job. Break it into actions. For each action, ask: What information does it need? What happens if it is wrong? Can it be reversed? Will somebody notice? Does a person need to approve it? When should the AI stop? Then assign the authority. READ. RECOMMEND. PREPARE. ACT WITH APPROVAL. ACT WITHIN LIMITS. ESCALATE. The goal is not to reach the top. The goal is to give AI enough authority to be useful while keeping control where it matters. Autonomy should earn its place.