An AI agent without an escalation path is an unowned decision

We spend a lot of time deciding what an AI agent is allowed to do. We spend far less time designing what happens when it should stop.

The permission boundary is only part of the operating model. A system can stay within its technical permissions and still leave the organization with a decision nobody is equipped to make.

Imagine an agent preparing a customer workspace. It can create resources, apply a standard configuration and verify access. Halfway through, the requested configuration conflicts with an existing policy. Some steps are complete. Others are waiting. The customer expects a usable workspace.

Stopping is the right action. But a message saying “human review required” leaves several questions unanswered. Who receives it? What has already changed? What decision is needed? What happens if nobody responds?

Those questions belong in the design before the agent is given responsibility for the workflow.

Define the conditions for stopping

Permissions describe what an agent may do. Escalation rules describe when continuing requires judgment beyond its delegated authority.

I would make the stopping conditions explicit for each workflow:

• The requested action falls outside an approved policy or consequence boundary.
• Required evidence is missing, stale or contradictory.
• A tool result leaves the system's actual state uncertain.
• Repeated attempts are no longer making useful progress.
• The task reaches a time, cost or risk limit.

These conditions need to be testable. “Escalate when uncertain” is difficult to operate if the only evidence is the model's own confidence statement. Where confidence scores are used, they need evaluation against the actual task and consequences. A missing authorization or an irreversible action should not become acceptable because a score is high.

OpenAI's practical guide to building agents similarly identifies retry thresholds and high-risk actions as reasons for human intervention. The engineering work is translating those principles into the specific workflow, with limits that can be enforced outside the model.

Give the exception a receiving owner

“Send it to the team” is a weak ownership model.

An escalation needs a receiving role with the authority to make the decision, a way to identify the person currently covering that role and a fallback when that person is unavailable. The right owner may be a product manager, an operations lead or an engineer. It depends on the decision being transferred.

The workflow also needs a response window and a safe waiting state. A delay of an hour has different consequences for a report-generation task and a customer-facing provisioning task. There is no useful universal timeout.

For the workspace example, the agent might preserve the resources already created, prevent further changes and route the policy conflict to the designated platform owner. If review is not acknowledged within the agreed window, the fallback owner is notified. Any cleanup must itself be authorized and safe.

Posting a notification should not count as a completed handoff. The receiving system needs to record acknowledgment, or make the absence of acknowledgment visible. Otherwise the agent has stopped, but the responsibility has not actually moved.

Send a decision someone can make

The person receiving an escalation should not have to reconstruct the entire run.

I would expect a concise decision record containing:

• The user's intended outcome and the decision now required.
• The stopping condition that was reached.
• Actions already completed and the resulting state.
• Relevant observations, source references and timestamps.
• A recommended next step, its consequences and any unresolved uncertainty.
• The response deadline and what happens while the task waits.

This is an evidence record. It does not require exposing private model reasoning or copying every available log into a ticket. Include what the owner needs, and keep access controls and sensitive data handling intact.

In the example, “configuration failed” is insufficient. “Workspace created; access remains disabled; requested setting conflicts with policy version X; recommend retaining the approved default pending a decision” gives the owner something concrete to review.

The record should also allow the owner to reject the recommendation. A handoff that makes approval easy but leaves rejection or correction unclear encourages rubber-stamping.

Make resumption a controlled step

Approval does not remove the need to check what changed during the pause.

The request may have been withdrawn. Another operator may have modified the workspace. The evidence used to make the recommendation may no longer be current.

Before resuming, the system should revalidate the relevant state and confirm that the approved action still matches the decision presented. A materially different action needs a new decision. Completed steps should not be repeated merely because execution resumes from an earlier point.

This is also why review should be tied to a specific action and scope. An exception approved for one workspace should not quietly expand the agent's authority across every future workspace.

Evaluate the handoff alongside the automation

A high automation rate can hide a poorly operated exception path.

I would review how often escalations reach the right owner, how long they remain unacknowledged, whether the evidence is sufficient and how often the owner has to restart the investigation. I would also test cases where the agent should have stopped but continued.

The goal is not to minimize escalation at any cost. Some escalations are evidence that the boundary is working. Others reveal missing context, a brittle integration or a policy that needs clarification. Separating those cases makes the next investment clearer.

Human review capacity belongs in the product plan too. If the system can generate exceptions faster than the organization can resolve them, a nominally safe design becomes a growing queue of unfinished customer work.

For me, safe autonomy includes a well-operated route out of autonomy. The agent should know when to stop, and the organization should be ready to own what happens next.

When your agent stops, can the receiving person make the next decision without rebuilding the story?

Further reading

• OpenAI on human intervention and failure thresholds
• NIST AI RMF on oversight roles and risk management
• Google SRE on explicit incident roles and handoffs