In a meeting about automation, people discuss capability. Someone runs a demo, the agent gets through ten typical requests, everyone nods, and the step goes live. Capability really has been proven at that point — for exactly those ten requests, and only as long as a person is standing next to it, watching. One question never came up in the room: what happens to the eleventh case at half past seven in the evening, when nobody is watching.
Why are “can the agent handle it” and “can we hand this over” different questions?
In its engineering write-up on agentic systems, Anthropic states the condition directly: agents fit where you can't hardcode a fixed path in advance and where you have some level of trust in their decision-making. The same text warns about the compounding errors that come with autonomous work. In that wording, trust is not a property of the model. It's your decision, and it gets made separately from the question of quality.
A way to sort decisions like this was described long before agents. In his 2015 letter to shareholders, Jeff Bezos split decisions into two types. Some are consequential and irreversible or nearly irreversible — one-way doors — and they have to be made slowly, methodically, with consultation. Others are reversible — two-way doors — and putting them through a heavyweight process does harm. One thing sets the type: whether you can go back. Neither the complexity of the decision nor its importance has anything to do with it.
Delegating a step to an agent gets sorted by the same criterion.
Sign one: is the error visible before the consequence?
Between the agent's action and its consequence there has to be a point where someone sees the result before it has done anything. An email sitting in the send queue has that point. An email that has gone out to the customer doesn't. Neither does a CRM record changed overnight: the next time anyone looks at it will be when a sales rep pulls up the history before a call, and by then nobody can reconstruct the difference between “that's how it was” and “that's what the agent wrote.”
The objection always sounds the same: but we'll be checking. The trouble is that people are bad at catching exactly the class of error that shows up here. A 2000 study by Skitka, Mosier, Burdick and Rosenblatt looked at two types of error people make when working with an automated aid: commission errors, where the person follows a wrong directive from the system, and omission errors, where the system flagged nothing and the person didn't notice the event on their own. Training focused on this bias reduced the number of errors of the first type and did not reduce the number of the second.
The instruction “check the agent's work carefully” works against errors you can see and doesn't work against silence. And in a step with no review point, the whole error is silence.
Sign two: does the right answer live inside the system?
The agent sees exactly what you gave it: records in the CRM, documents in the knowledge base, the message history, the instructions in the prompt. If the right answer at this step requires knowing what was agreed out loud yesterday, that there's a court case under way with this customer, or that their price has historically been different “because that's how it turned out,” the agent will produce an answer anyway. It will be plausible.
A plausible answer is worse than a wrong one. A wrong one gets caught because it jars. A plausible one moves on and surfaces two weeks later in a conversation with a customer who honestly doesn't understand where the new condition came from.
The check here is simple and takes a minute: write down where the right answer at this step comes from. Each source on its own line. If the lines include “from Marina's head” or “from an agreement that isn't written down anywhere,” the step isn't ready to hand over yet.
The useful part is that the result of this check is rarely a final verdict. In our practice, the right move is more often not to give up on delegation but to write down a rule that has so far lived only in conversation. That's an hour or two of work, and it's needed either way, because every new hire trips over the same rule. A separate breakdown of the case where there seems to be no data for the agent at all is in the article “We have no data for AI” below.
Sign three: does the consequence cost more than all the savings?
The third sign measures asymmetry. A signed contract, a mailing to a segment, a deleted record, a processed payment — each of these costs so much that a year of savings on the step doesn't cover one bad case. A one-way door.
The math here isn't done in adjectives. Take the cost of one bad outcome together with the hours to roll it back, multiply by a realistic frequency rather than the one you'd like, and compare that with how many hours a month delegation saves. If the first number is bigger, there's nothing to argue about, and no improvement in the model changes that arithmetic.
An important difference from the first two signs: reversibility is usually a property of your configuration, not of the action itself. Sending an email is irreversible. The same email placed in a queue with a two-minute delay and a visible cancel button is reversible. A mailing to a segment is irreversible. A mailing that starts with five percent of the list and stops at a complaint threshold is almost fully reversible. The third sign can often be engineered away, and that's the place to start before putting a step on the forbidden list.
What looks like a stop signal but isn't one?
“The agent sometimes gets it wrong.” It always sometimes gets it wrong, and so does a person in that seat. Error frequency on its own decides nothing until you've put two other numbers next to it: what one error costs and whether it's visible. A step with frequent, cheap and noticeable errors is a good candidate for delegation, not a bad one.
“The process is complex.” Complexity and irreversibility aren't related. Working through dozens of conditions in a price list is complex, but an error there gets caught at the approval stage and costs five minutes. Pressing “delete” is simple, and the consequence is irreversible. Complex processes with a cheap error are the best thing to hand to an agent first, because that's where a person spends the most hours on routine.
There's a third thing worth hearing separately: “I like doing this.” It isn't a delegation criterion, but it's a real factor in whether an automation sticks. Automations that take away the part of the job a person respects themselves for get quietly switched off — we wrote about that in our breakdown of why some automations stick and others die.
How to check a step in ten minutes: five questions
Go through them in writing, with the process owner, not with a developer. Record each answer in one sentence.
- Where does the action stop? Name the specific point where the agent's result hasn't yet become a consequence: a draft, a queue, a “pending approval” status. If there's nothing to name, the first sign applies.
- Who looks at that point, and why would they look there? A reviewer with no reason to open the queue isn't a reviewer. Any reason will do, as long as it exists: their name under the result, their metric, their customer.
- Where does the right answer come from? Write the sources out as a list. Every line that reads “from someone's head” is either the second sign or a task to write the rule down.
- What does one bad outcome cost, and how many hours does it take to roll back? Two figures, both in money and hours. If nobody in the room can answer this, the step doesn't pass until someone can.
- What do we do when this happens the third time? Not the first, specifically the third. The answer “we'll figure it out” means there's no procedure, and the third time you'll be figuring it out by hand too.
Ten minutes is an honest estimate for one step, provided the person who actually performs that step is in the room. If the test stretches to an hour, it usually turns out you're discussing three steps glued together instead of one.
What does a “no” actually mean — the person does everything by hand?
The five-question test doesn't give a binary answer. Refusing outright is the rarest outcome. More often, one of three ways out works:
- Narrow the scope. The agent takes the share of requests where the sign doesn't apply, and the rest goes to a person under an explicit rule. The rule has to be a check the agent itself can run, not a wish like “if the case is complex.”
- Add a checkpoint. The agent does everything except the last action: drafts the email, fills in the document, prepares the change to the record. A person presses the button. Most of the routine disappears that way, and the review point stays where it is.
- Split the step. Hand over the reversible part completely and leave the irreversible part with a person. This is most often where the gain is hiding, because the irreversible part usually takes a minute out of half an hour of work.
A checkpoint doesn't have to stay forever. Once you've taken a baseline for the acceptance rate and seen that the agent goes months without an error on this type of request, the checkpoint can be moved — but with a number in hand, not a feeling. How to calculate that baseline is covered in our companion piece on the autonomy rate.
What's the most common mistake when handing a step to an agent?
In 1983, Lisanne Bainbridge described a set of effects that still best explain why automation breaks exactly where it was supposed to help. Her formulation: by taking away the easy parts of the task, automation can make the difficult parts of the human operator's task more difficult. The person is left with monitoring and the rare hard cases, where they no longer have daily practice — and that's the very moment they're expected to step in fastest and most accurately.
In agent processes it looks like this. The step went to the agent, and a person was kept on as a checker “just in case.” Three months later they've seen ninety percent correct results in a row, they stop reading carefully, and at the same time they lose the skill of doing the work themselves. On paper there's control; in practice there isn't.
There are two ways out that work, and both are boring. Either leave the person enough live work of this type that their eye stays trained. Or turn checking everything into regular spot checks — exactly how to size the sample and what baseline to use when moving the checkpoint is covered in our companion piece on the acceptance rate.
What does Auspex do about this?
We run the five-question test before the agent gets access to production data, and we run it with the process owner, not with IT. Auspex is responsible for the process and the CRM under the agent; the agent itself is built and measured by Grow2.ai, our AI division. The answers are recorded in writing — not for formality's sake, but because after launch the same conversation turns into a search for someone to blame.
There's no universal list of forbidden processes: at two companies, a step that looks the same has different reversibility and a different cost of error. What stays the same is the requirement to name the review point and the person at it before launch, not after the first complaint. From there, it makes sense to move what was decided at this stage into the contract: the acceptance criterion and the limits of autonomy are exactly the clauses most often worded in a way that makes them impossible to verify.
Where do you start this week?
- Take one step you're about to hand to an agent right now and go through the five questions in writing with whoever performs that step. Ten minutes, a sheet of paper.
- If you get stuck on the third question, that's no reason to give up. It's a list of rules worth writing down, and you need it for new people anyway.
- If you already have agents running, run the test retroactively: on the steps you handed over three months ago, when nobody was asking about a review point yet.
If the test leaves you with steps you don't know how to approach, there are two ways in. For a diagnosis of the agent itself, it's the free AI audit at Grow2.ai. If the questions are broader and start with the process and the CRM under the agent, it's the CRM and automation audit at Auspex. Both links are below.
Sources
- Anthropic — Building effective agents
- Skitka, Mosier, Burdick & Rosenblatt (2000), Automation Bias and Errors: Are Crews Better Than Individuals? — International Journal of Aviation Psychology 10(1), 85–97
- Jeff Bezos — 2015 Letter to Shareholders (Type 1 / Type 2 decisions, one-way doors)
- Bainbridge, L. — Ironies of Automation. Automatica 19(6), 1983, 775–779