Sources checked on 12 October 2026.
Imagine a sales manager asking an AI agent to prepare an offer for a hesitant customer. The agent reviews the correspondence, picks a suitable package and adds a discount to speed up the deal. The offer reaches the customer before the manager has opened it. The document is good and the figures are right, but the discount went beyond what the manager would have accepted. The problem began in the small gap between "prepare the offer" and "send it".
This is a hypothetical example, but it shows a real decision that comes before running any agent: what authority do we give it? Access to email or the customer system may look like a technical detail. It sets how far the system can turn its conclusions into actions that affect a commercial relationship. The speed that impressed the team can also be the reason a decision goes out before anyone has reviewed it.
What does the word "tool" mean here?
In a recent opinion piece, Rich Hickey distinguishes between a tool that a person steers continuously and automation that acts once it receives a request. One can disagree with applying that to language models, but the distinction raises a useful management question: how much control we assume we have when we say we are using AI, and how much control the process actually provides. [1]
The name alone will not settle how the work is designed. What helps a manager is tracing the move from information to recommendation, and from recommendation to commitment. Writing a draft offer gives the team something to review. Sending the offer changes the customer's expectations. Approving a price exception uses a commercial margin that belongs to the company. A system may carry out all three steps smoothly, yet each step calls for a different level of delegation.
Good delegation starts by describing what the agent may change in the world, and who bears the result of that change.
Four rungs of authority
A team can use a practical ladder of four rungs: suggests, then prepares for execution, then acts after approval, then acts within set limits. This is a proposed framework for structuring the discussion. Moving between rungs is a decision about each step of the work, and it does not have to cover every function the agent has.
In the sales example, the agent might suggest the package and the discount, prepare the offer in the system, then wait for the authority holder's approval before sending. It could be given the freedom to send a reminder about the offer date if the reminder text is approved and does not change the terms of the deal. That way the agent can act automatically within clear limits, while actions that commit the company still require approval.
The phrase "with human approval" needs design too. If the manager receives dozens of requests a day on a screen that shows nothing but an accept button, approval may turn into a formality. The reviewer should see the proposed action, what will change because of it, the information the agent relied on, and any exception to policy. They should also have a real chance to amend or refuse before the effect happens.
Every request also needs a known decision-maker and a clear waiting period. When approval does not arrive, the system keeps the offer as a draft and notifies the owner of the delay. The passing of time does not become automatic permission, and the decision is not passed to the first person available just to keep work moving. A substitute can be named in advance, provided they hold the same authority.
The limits also stay open to change. The process starts in a narrow scope, then widens once the team has evidence from real use that it can detect and fix mistakes. A successful demonstration alone does not answer that.
Reversibility determines how much to delegate
To decide the rung, start with two axes: how large the effect of the action is, and how easy it is to undo. Changing an internal classification that can be restored is different from a promise that reaches a customer. A team may be able to delete a message after sending it, but deleting does not necessarily restore trust or erase the expectation it created. Reversibility should be judged from the point of view of the person affected by the decision.
The matrix helps expose these differences before permissions are handed out. In a hypothetical customer-service example, the agent could be allowed to update a request's classification automatically, while making an exceptional commitment needs review. In procurement, it can prepare a purchase request, but choosing a new supplier or changing payment terms may call for a different authority holder. The limits follow the effect of the action and its context.
A small decision can repeat a thousand times
A ceiling on each operation is not enough. Small compensation payments across a large number of requests can add up to significant spending. So permissions need cumulative limits over a stated period, and rules that stop a large decision being split into smaller ones. The team chooses these limits according to its economics and its capacity to absorb a mistake; there is no single value that suits everyone.
The limits also cover stopping conditions: a key piece of information is missing, two sources conflict, or a request falls outside the approved cases. In these situations the agent shows what it knows and what it lacks, and refers the case to the owner. It does not need to invent a route to reach its goal of finishing. The team should test these cases deliberately before widening permissions.
Write the delegation like a management decision
Before launching the agent, bring together the business owner, the technical owner and the person who will receive the exceptional cases. Choose one task and write a short agreement for it that sets the required result, the permitted actions, the limits that call for approval, and who holds the right to stop it. If those present disagree about what a verb like "approve" or "settle" means, that is a disagreement about the decision, and it needs resolving before the system is set up.
Then turn the agreement into actual permissions. The agent's access should be limited to the data and actions the task requires. If its job is only to prepare the offer, it does not need permission to send it. Critical rules are enforced through controls that can be inspected, with a log showing the action, its time and the approval tied to it. The written instructions to the agent are part of the implementation, and they need limits that support them outside the conversation.
Measure what happened after execution
After launch, review a sample of completed actions, and every case that went beyond the delegation limit or needed correction. Ask how much time the agent saved, how much time the team spent on review and correction, and how clear the decision log is. A rise in referrals may be useful if it reveals cases that used to pass unnoticed. Reading the indicators needs the context of the work.
If the agent makes a mistake, the decision returns to the person responsible for the process: they suspend the affected permission, deal with its effects, and set what is needed before it is restored. A model cannot be held to account for the promise the customer received, whereas management can hold itself to account for the limits that allowed it to be made. That includes updating the delegation when the task, the agent's tools or its information sources change.
At your next meeting, open the list of actions your agent can carry out today. Pick the most consequential one, then trace who can stop it before it happens and who will deal with its consequences afterwards. If you cannot name the person and the step clearly, you have found a postponed management decision that deserves settling before you grant another permission.
Sources
[1] Rich Hickey: 'AI' Is Not a Tool. Opinion piece published on 12 October 2026.
The delegation framework, the matrix and the examples here are illustrative editorial proposals, not study results or documented cases.
One email when we publish. Research, product decisions, and what teams report back.
