AI Reliability in Practice
AI Reliability in Practice
People in the Loop: When an AI Process Should Hand Work to a Person
People in the Loop: When an AI Process Should Hand Work to a Person
Highlights
Reliable automation does not mean that no person is ever involved. It means that people are involved where the process needs them, and nowhere else, and that the agent cannot decide on its own to skip them.
Escalation is often the right answer. In the IT service management benchmark, GPT-4.1 on its own escalated 1% of tickets and took wrong automated actions on 14%. On Thunk.AI it escalated 6% and was more than 99% reliable on the rest.
Escalating too much is also a failure. In the AML benchmark, models on their own made 9 to 40 unnecessary escalations each. Every one costs an investigator's time.
People belong where a mistake is costly or cannot be undone. Approval gates, step reviews and tool approvals are placed there, and the rest of the process runs on its own.
People also belong at design time. The most valuable human input is often the process owner's decision on an ambiguity, made once and applied to every case.
Gates are platform rules. In Thunk.AI, a required approval applies whatever the agent decides.
Highlights
Reliable automation does not mean that no person is ever involved. It means that people are involved where the process needs them, and nowhere else, and that the agent cannot decide on its own to skip them.
Escalation is often the right answer. In the IT service management benchmark, GPT-4.1 on its own escalated 1% of tickets and took wrong automated actions on 14%. On Thunk.AI it escalated 6% and was more than 99% reliable on the rest.
Escalating too much is also a failure. In the AML benchmark, models on their own made 9 to 40 unnecessary escalations each. Every one costs an investigator's time.
People belong where a mistake is costly or cannot be undone. Approval gates, step reviews and tool approvals are placed there, and the rest of the process runs on its own.
People also belong at design time. The most valuable human input is often the process owner's decision on an ambiguity, made once and applied to every case.
Gates are platform rules. In Thunk.AI, a required approval applies whatever the agent decides.
This article is about the boundary between the agent's work and people's work in an AI-automated process: where it should be, how to tell whether an agent is respecting it, and how the Thunk.AI platform enforces it.
1: Escalation is often the correct outcome
It is natural to read an escalation rate as a cost: every case handed to a person is a case the automation did not handle. The IT service management benchmark shows why that reading is wrong. GPT-4.1, given the workflow description and tools without the platform, escalated only 1% of tickets. It also took incorrect automated actions on 14% of tickets, actions that in production would cause outages. On Thunk.AI, the same model escalated 6% of tickets and was more than 99% reliable on the tickets it handled itself.
The lower escalation rate came from overconfidence, not capability. An agent that is uncertain and acts anyway produces errors nobody sees until they have consequences. An agent that recognizes uncertainty and hands the case over produces a cost that is visible and bounded. A reliable process measures both, and treats a correct escalation as a correct result.
2: Escalating too much is a failure too
The opposite failure is just as real. In the AML alert triage benchmark, every model given the procedure as a single step escalated alerts that the bank's rules clear or only monitor, between 9 and 40 times per model, and gpt-5-mini drafted 39 unnecessary suspicious activity reports. An over-cautious process moves work to people without making anything safer, and buries the cases that do need attention.
On Thunk.AI, the four models together made two unnecessary escalations in 328 alert runs. The difference was not a more cautious or less cautious model. The rules that decide when an alert needs a report were applied by code, so the agent had no reason to escalate out of uncertainty about the rules.
3: Deciding when to escalate is a judgment of its own
Whether a case is outside what the agent may do is a question that should be answered on its own terms, not as a side effect of other work. In the τ²-bench customer service work, the decision to transfer a customer to a human agent is made by an AI tool that judges only that: whether the request is one the agent can handle, from the customer's own words. The store's policy says a request that is within the agent's actions stays with the agent whatever happened to it, whether it was completed, refused by the policy or stopped by a system error. A customer insisting, or asking for a person, does not make it a different request. The tool that performs the transfer acts only on that judgment.
Separating the judgment from the action does two things. It lets the judgment be tested on its own, and it means that no amount of pressure in the conversation can produce a transfer the policy does not allow.
4: Where people should review or approve work
Not every step needs a person, and a process that sends everything for review defeats its purpose. The help center's advice is to start with the process fully automated and add a person where a mistake is costly or cannot be undone: a payment, a regulatory filing, a change to a production system, a message to a customer that cannot be recalled.
Thunk.AI offers several kinds of gate, at different points:
Before a work item starts or completes, a person approves it.
At a particular step, a person reviews and finishes the step, after the agent has done the work.
On a particular tool, a person approves each call before it runs, for actions such as sending or filing.
On a required fact, a step waits for a person when a property it needs to start or to finish is missing.
On errors, failures are escalated to the thunk's owner.
5: Gates are platform rules, not instructions
A sentence in the directions saying "ask for approval before filing" is something the model may or may not do. A gate is something the platform does. In Thunk.AI, a required approval applies whatever the agent decides, and a step that needs a person cannot finish without one. That is the difference between a process that usually involves people at the right points and one that always does.
6: People belong at design time as well
The most valuable human involvement in an AI process often happens before it runs. A procedure is full of questions only the business can answer, described in Instructions are ambiguous and incomplete. A process owner who decides each one once, with the decision recorded and built into the process, removes a whole class of cases that would otherwise need a person at run time, or worse, be decided differently by the model each time.
7: Asking and failing are different
When an agent cannot finish, it has two honest options. It can ask a person for something it needs, such as a missing document, a decision or an approval, and continue once it has it. Or it can report an error, when the case cannot proceed as given. Thunk.AI makes both explicit actions at the end of a run, so they are visible, counted and routed, rather than buried in a step that claims to be done.
This article is about the boundary between the agent's work and people's work in an AI-automated process: where it should be, how to tell whether an agent is respecting it, and how the Thunk.AI platform enforces it.
1: Escalation is often the correct outcome
It is natural to read an escalation rate as a cost: every case handed to a person is a case the automation did not handle. The IT service management benchmark shows why that reading is wrong. GPT-4.1, given the workflow description and tools without the platform, escalated only 1% of tickets. It also took incorrect automated actions on 14% of tickets, actions that in production would cause outages. On Thunk.AI, the same model escalated 6% of tickets and was more than 99% reliable on the tickets it handled itself.
The lower escalation rate came from overconfidence, not capability. An agent that is uncertain and acts anyway produces errors nobody sees until they have consequences. An agent that recognizes uncertainty and hands the case over produces a cost that is visible and bounded. A reliable process measures both, and treats a correct escalation as a correct result.
2: Escalating too much is a failure too
The opposite failure is just as real. In the AML alert triage benchmark, every model given the procedure as a single step escalated alerts that the bank's rules clear or only monitor, between 9 and 40 times per model, and gpt-5-mini drafted 39 unnecessary suspicious activity reports. An over-cautious process moves work to people without making anything safer, and buries the cases that do need attention.
On Thunk.AI, the four models together made two unnecessary escalations in 328 alert runs. The difference was not a more cautious or less cautious model. The rules that decide when an alert needs a report were applied by code, so the agent had no reason to escalate out of uncertainty about the rules.
3: Deciding when to escalate is a judgment of its own
Whether a case is outside what the agent may do is a question that should be answered on its own terms, not as a side effect of other work. In the τ²-bench customer service work, the decision to transfer a customer to a human agent is made by an AI tool that judges only that: whether the request is one the agent can handle, from the customer's own words. The store's policy says a request that is within the agent's actions stays with the agent whatever happened to it, whether it was completed, refused by the policy or stopped by a system error. A customer insisting, or asking for a person, does not make it a different request. The tool that performs the transfer acts only on that judgment.
Separating the judgment from the action does two things. It lets the judgment be tested on its own, and it means that no amount of pressure in the conversation can produce a transfer the policy does not allow.
4: Where people should review or approve work
Not every step needs a person, and a process that sends everything for review defeats its purpose. The help center's advice is to start with the process fully automated and add a person where a mistake is costly or cannot be undone: a payment, a regulatory filing, a change to a production system, a message to a customer that cannot be recalled.
Thunk.AI offers several kinds of gate, at different points:
Before a work item starts or completes, a person approves it.
At a particular step, a person reviews and finishes the step, after the agent has done the work.
On a particular tool, a person approves each call before it runs, for actions such as sending or filing.
On a required fact, a step waits for a person when a property it needs to start or to finish is missing.
On errors, failures are escalated to the thunk's owner.
5: Gates are platform rules, not instructions
A sentence in the directions saying "ask for approval before filing" is something the model may or may not do. A gate is something the platform does. In Thunk.AI, a required approval applies whatever the agent decides, and a step that needs a person cannot finish without one. That is the difference between a process that usually involves people at the right points and one that always does.
6: People belong at design time as well
The most valuable human involvement in an AI process often happens before it runs. A procedure is full of questions only the business can answer, described in Instructions are ambiguous and incomplete. A process owner who decides each one once, with the decision recorded and built into the process, removes a whole class of cases that would otherwise need a person at run time, or worse, be decided differently by the model each time.
7: Asking and failing are different
When an agent cannot finish, it has two honest options. It can ask a person for something it needs, such as a missing document, a decision or an approval, and continue once it has it. Or it can report an error, when the case cannot proceed as given. Thunk.AI makes both explicit actions at the end of a run, so they are visible, counted and routed, rather than buried in a step that claims to be done.