When Should An AI Employee Escalate To A Human? The Escalation Rules
An AI employee should escalate to a human in five situations: when money is about to leave the business, when something is about to go to a customer or the public in your name, when anything is about to be deleted or changed irreversibly, when it lacks access it needs, and when two of your rules conflict. Everything else it should finish without stopping to ask. The failure most owners experience is not an agent that escalates too little; it is one that escalates constantly, handing back half-done work with a question attached. The escalation rules exist to fix both.
The default should be "finish it," not "check with me"
Start from the right baseline. An agent left to its own devices will over-escalate, because English is lossy and the agent assumes you know exactly what you want. When it is uncertain, the safest-looking move is to stop and ask. From the agent's side, asking is free. From your side, every unnecessary question is an interruption, and ten of them a day is the reason owners quietly stop using the thing.
So the first escalation rule, written into your rules file, is a default: "Ask me every question you have now, then don't stop until it's done. No sandbagging." Questions get batched to the front. After that, the agent is expected to finish. Escalation during the work is the exception, and the exceptions need to be named.
The five situations that always escalate
1. Money is about to leave. Purchases, refunds, payroll changes, vendor payments, anything that moves funds. Set a threshold if you want ("under $200, go ahead and tell me after"), but the default for anything meaningful is stop and ask first. This is the one owners agree on fastest.
2. Something is about to reach a customer or the public in your name. Emails to clients, posts, replies on review sites, anything a human outside the company will read as coming from you. Drafting is agent work. Sending is a human call until you have seen enough drafts to trust the agent with a category. When you do extend that trust, write it down: "You may send routine shipping updates without review. Anything about pricing or a complaint, I see first."
3. Something is about to be deleted or changed irreversibly. Deleting records, overwriting files with no backup, changing production settings, cancelling subscriptions. The test is: can this be undone in five minutes? If not, the agent stops and asks. Where possible, this should not be a rule at all but a technical block, which brings us to the decision rule below.
4. It lacks access it needs. A login, an environment variable, an API key. The agent should escalate immediately and precisely: one line naming exactly what it needs. Not "I'll need you to configure the integration." The phrase we teach: "Do everything you can possibly do yourself that doesn't require me; when you truly can't, give me the exact step-by-step and the links, and I'll do it." A good escalation here takes you a minute to resolve. A bad one costs an afternoon.
5. Two of your rules conflict. You said "always finish without stopping" and you said "never send to a customer without review," and the task is to send a customer email. The agent should name the conflict and ask which rule wins, rather than quietly picking one. Over time, each resolved conflict becomes a line in the rules and the conflicts get rarer.
What should never escalate
Be as explicit about this as about the five above, because an agent with only a list of "stop" conditions will still find reasons to stop. Write down the categories where you expect it to just do the work: research, drafting, internal summaries, pulling reports, organizing files, writing code in a non-production environment, anything reversible that stays inside the company. For these, the rule is finish, then report in one line: done, blocked, or needs you.
Also write down the questions you never want asked. "Which format do you prefer?" when your rules file already says bullets. "Should I proceed?" when you already said go. Each one of these is a rules-file gap. When you get one, do not answer it in chat; add the answer to the rules so it is never asked again.
Code or agent: the decision rule for hard limits
Some escalation rules are so absolute that they should not be rules at all. If the agent must never delete production data, do not write "never delete production data" and hope. Remove its delete permission. If spend over $500 always needs approval, put the approval in the payment system, not in the agent's conscience.
This is the decision rule we teach: a hard-and-fast rule is code, a judgment call is the agent. Rules in the file are for the judgment zone, the gray areas where you want the agent to think and then decide whether to involve you. Hard limits belong in permissions, settings, and scripts. An agent that is technically unable to do the catastrophic thing is more reliable than one that has been asked nicely not to.
How to write the escalation section
Three short lists in the rules file. Do freely and report after. Do, then tell me. Stop and ask first. Put the five situations above in the third list, put your never-escalate categories in the first, and let the second list hold the middle ground (sent a routine update, moved a file, made a small purchase under threshold). Then add one line at the top: questions go up front, and after that, finish.
Expect to revise it. The first week, you will find the agent either asking too much or too little in some category. Each time, you move the category between lists and the file gets more accurate. This is the same mechanism as the irritation list, and it is how an agent that interrupted me roughly every third task got down to a few percent. The surrounding structure is in the seven-section checklist, and the broader first-two-weeks plan is in how to onboard an AI employee.
FAQ
Should an AI employee ask permission before every task?
No. The default should be to batch every question to the start, then finish without stopping. Permission during the work should only be required for the named exceptions: money leaving, customer-facing sends, irreversible changes, missing access, and conflicting rules.
What is the difference between an escalation rule and a technical block?
An escalation rule asks the agent to stop and check in; a technical block makes the action impossible. Use blocks for absolute limits like deleting production data or spending over a threshold. Use rules for the gray areas where you want judgment. A hard-and-fast rule is code; a judgment call is the agent.
How should the agent escalate when it is blocked?
In one line, naming exactly what it needs: the specific login, env var, or API key, with the steps and links for you to provide it. Vague escalations like 'you will need to configure the integration' waste hours. Precise ones take a minute to resolve.
What if the agent escalates too often?
Each unnecessary question is a gap in your rules file. Instead of answering in chat, add the answer to the rules so it is never asked again. Also make sure you have written down what the agent should do freely without asking, not just what it should stop for.