Your agent handles the standard 80% fine and then stalls the moment a real customer does something real. That is not a model problem, it is a context problem. You gave it the process and never gave it the exceptions, so it either fills the gap with a guess or shuts down. The fix is a written decision log, one row per "it depends," with the condition, the rule, and the reason attached.
Why does my AI agent freeze or guess instead of asking?
Models are trained to be helpful. When there is a hole in the context, the model does not see a hole. It sees an empty slot and fills it with the most plausible thing, which is usually close to right and occasionally expensive.
Freezing is the other failure mode, and it usually shows up right after you tell the agent to be careful. Careful with no definition is paralysis.
In my experience the real problem sits upstream of the agent. The exceptions live in your head. Maybe in the head of one long-term operator who has been with you since the beginning. Nobody wrote them down, partly because writing them down felt obvious, and partly because most of them only come up four times a year.
The process document always describes the happy path. The business actually runs on the two hundred small judgment calls nobody recorded.
How do I find the exceptions that are actually worth writing down?
Do not start by auditing your SOPs. Start by auditing your interruptions.
For two weeks, keep one page called Decisions I Keep Making. Notion or a shared Google Doc is fine. Every time someone walks over, Slacks you, or forwards a customer email asking "what do we do here," that is a candidate. Every time you hear yourself say "well, it depends," write down what it depends on. That second part is the whole exercise.
Then pull the last 20 escalations out of your inbox or help desk and cluster them. What felt like 200 exceptions is usually 12 patterns wearing different clothes.
Sort by what a wrong answer costs you in money or trust. The top 10 by cost get written first. Some of the bottom 50 should be routed to a human forever, and that is a fine outcome.
Rough number: one business function, say refunds or scheduling, usually needs 30 to 60 rules before the agent stops guessing. You do not need all of them on day one.
What does a useful exception rule actually look like?
"Use judgment on refunds" is not a rule. It is a wish. The agent reads it, nods, and invents something.
Every rule needs four fields:
- Trigger: the condition, in the customer's own words where you can.
- Rule: what to do.
- Why: one line of reasoning.
- Escalate if: the boundary, the point where the agent stops and hands over.
Here is a real one from a wedding venue. A couple wants their deposit back 45 days out. Trigger: cancellation inside 60 days, date is rebookable. Rule: offer one date move, no cash refund. Why: we can resell the date and we would rather keep the booking. Escalate if: they mention a bereavement or a medical emergency, in which case full refund, no policy language, no questions asked.
The Why field is doing more work than it looks like it is doing. It lets the model generalize to a near miss you never wrote down. A rule without a reason is brittle. A rule with a reason bends.
You also need to write the negative space. Say plainly what the agent is not allowed to decide. Pricing exceptions above a certain dollar amount, anything involving a lawyer, anything involving a press inquiry. Those go to a human, always, and "always" has to be written down somewhere.
Where do I put these rules so the agent actually reads them?
Context loading matters more than prompt wording. Two things to get right.
First, keep the exception list always loaded, not retrieved. If your list is under roughly 150 rows, it should sit in context every single time: in a Claude Project, in a custom instruction block, in a markdown file you feed the agent. Retrieval is great for a knowledge base and bad for exceptions, because a retrieval miss produces exactly the failure you are trying to eliminate. The agent confidently applies the happy path to a case that has a written rule sitting two inches out of reach. I go through the full loading setup in the AI OS playbook if you want the architecture.
Second, organize by domain, not alphabetically. Refunds, scheduling, pricing, vendors, hiring. Agents do better with grouped rules because related exceptions share the same underlying logic.
On tooling: Notion works well as the source of truth when non-technical staff need to edit it, and you can pull it into your agent through the API. A plain markdown file in a repo works better if you are building in Cursor or Claude Code, because you get version history for free. Airtable is good when the decision table gets wide. n8n or Make handles the routing when a rule says hand this to a human.
How do I keep the exception list from rotting?
Ten minutes a week. Pull every escalation the agent kicked to a person. Each one is either a missing rule or a rule that is wrong. Add it or fix it, and date the change.
Retire rules that have not fired in six months. Stale rules are not free. They eat context and they add noise the model has to weigh against the rule that actually matters.
Version the list, and write a line about why you changed something, because six months from now you will not remember and neither will the person who inherited the file from you.
What's becoming clearer to me is that this is the actual job. Not prompt engineering. Context engineering. The founders I know who get real work out of AI agents for founders and operators are not the ones with the cleverest prompts. They are the ones who spent a boring Saturday writing down what they already know.
FAQ
How many exception rules does an agent need before it stops guessing? Usually 30 to 60 for one business function. Start with the 10 that cause the most interruptions and the highest cost per wrong answer, ship those, then watch what still escalates.
Should my agent guess when it hits a case with no rule? No. Give it one standing instruction: name the missing rule, propose a decision, route it to a human, log it. A visible gap is useful. An invisible guess is the only real failure.
Can I just paste my SOP into the agent and let it figure out the exceptions? That produces interpolation, and interpolation looks like competence right up until it costs you a customer. The SOP is the 80%. The AI agent edge cases are a separate document you write on purpose.
I wrote the full playbook for this. How to Build Your Own AI Agent Operating System walks you through the exact architecture I use, step by step. You can get it at a.mastermindshq.business/ai-os-book.