Your agent shipped to production looking solid.
It passed testing. It handled the happy path. Then real work started and you watched it do one of two things: act on something it should not have decided alone, or go silent on an input it did not know how to handle.
Neither mode triggered an alert. Neither mode told anyone a human should look.
This is not a model problem. It is not a prompt problem. It is an escalation design problem, and it is the fastest way an agent breaks a real operation.
You probably have authorization nailed down.
Authorization is the governance question: who approved this decision class before the agent went live? What are the decision boundaries? Which actions require which approvals? You built a permission model. You set confidence scores. You defined what the agent is allowed to touch.
That is good work. It is not enough.
Escalation design is different. It is the real-time operational question: what does the agent do when it encounters a situation outside its trained scope? When confidence dips below safe. When the action consequence is too high to decide alone. When the situation is not in the training set at all.
Authorization happens before deployment. Escalation happens during production, in the moment, when the agent is live and an edge case shows up.
Most teams ship with authorization and no escalation path. Then they wonder why their agent either guesses on hard cases or freezes with no signal.
An agent without a defined escalation path has two failure modes.
First mode: it acts past its competence. The agent has a task. It has permission to complete that task. An edge case arrives that the agent was not trained for. But the agent has no instruction to pause or route to a human. So it acts anyway. It uses whatever confidence signal it has left and makes a decision it should never have been allowed to make.
The damage compounds slowly because nobody knows it happened.
Second mode: the agent stalls. The situation is ambiguous. The confidence threshold is not met. But the agent has no escalation instruction, so it does nothing. It hangs silently. It does not alert anyone. It does not route the work to a human. It just stops.
The operation moves forward without it. The work piles up. Nobody realizes the agent has failed until the backlog is weeks long.
Neither mode alerts you in real time. Neither mode preserves human oversight. Both modes break the operation because there is no defined path back to a human when the agent is uncertain.
Stop thinking of escalation as something to handle after your first incident.
Escalation is architecture. Build it before the agent touches production.
Before go-live, define exactly three conditions under which your agent stops and routes to a named human:
Condition One: Confidence Below Threshold.
Your agent processes input and generates a confidence score for its decision. You set a threshold during testing. Below that threshold, the decision is not safe to make alone.
Define what happens when confidence dips below threshold. Does the agent pause? Does it route the work to a human? Which human? Does that human have the context to decide? Does that human have the capacity?
Do not leave this as a question. Answer it before the agent goes live.
Condition Two: Action Consequence Above Defined Severity.
Some decisions matter more than others.
An agent that routes internal emails is lower consequence. An agent that approves customer refunds or changes billing terms is higher consequence. An agent that modifies customer data or deletes records is critical consequence.
Define the severity levels for your operation. Then define the threshold: above this severity, the agent escalates to a human, no matter how confident it is.
Document it. Publish it. Make sure the named human knows they are the escalation point.
Condition Three: Situation Type Not Covered in Training.
Your agent was trained on a dataset of decisions and outcomes.
Real production will have situations that were not in that dataset. Maybe it is a new customer type. Maybe it is an unusual combination of conditions. Maybe it is something you did not anticipate.
When the agent encounters a situation type it was not trained to recognize, it should pause and escalate.
Build a mechanism to flag "situation type not in training set." It does not have to be perfect. It just has to be defined before the agent touches live work.
You do not need a flowchart that looks like architecture documentation.
You need a simple routing table. Something a team member can point to and say: "if this happens, the agent goes here."
Here is what that looks like:
Scenario: Agent processes a customer support request.
If confidence on the decision is below 0.72, escalate to support_supervisor.
If the decision affects revenue over $5,000 in any direction, escalate to finance_lead.
If the request type is not in the training dataset, escalate to support_supervisor and tag it as "new situation."
That is it. Not elegant. Not automated. Just clear.
Name the humans. Make sure those humans know they are on the escalation path. Make sure they have capacity for it. Make sure there is a way to log and track what gets escalated, so you know if your agent is escalating too much (sign of a capability problem) or too little (sign of an oversight problem).
Test this decision tree before the agent goes live. Test it with your team. Test it with the named humans. Do not assume it works just because it looks reasonable in a document.
An agent without escalation design fails invisibly or recklessly.
An agent with escalation design fails loudly and in a controlled way. The work routes to a human. The human decides. The failure is visible. The operation keeps moving.
The difference is not subtle. It is the difference between a tool you can trust in production and a tool that will quietly break something you care about.
Design your three escalation conditions now. Define which human owns each condition. Make sure that human understands what they are deciding and why. Test it.
That is how you move an agent from demo to production without the operation falling apart.
If your agent needs escalation paths designed before go-live, Acrein Group does this work. We build and run agentic operations in production across our portfolio companies, and escalation design is the first operational question we answer before the agent touches live work.
The right conversation at the right moment changes everything. Let's have it.
Talk to us