Escalations and approvals

An escalation is a blocking decision handed to a human. It's the mechanism that lets an agent stop and ask without losing its work — which is what makes "ask rather than guess" a realistic instruction.

What happens when an agent escalates

1. The agent poses the decision as a multiple-choice question — one to four questions, each with two to four labelled options, plus context on what it's done and what it needs decided.
2. Its work is parked. The session, and any task running in it, is held. Nothing times out. Nothing is closed. Progress is preserved.
3. The platform routes the question to the right person and notifies them.
4. The human answers — choosing an option, or answering in their own words.
5. The agent is woken in the same conversation with the decision and continues from where it stopped.

For a task, the executor is re-dispatched with all its progress intact.

Three kinds

Each carries an urgency — low, normal, or high — which agents are told to use honestly.

Ask, or escalate?

Agents have two ways to get an answer, and the distinction is about who needs to answer and when:

• Ask in the conversation when whoever is on the other end right now can settle it and you need the answer to continue this turn. The question renders as a widget above the chat bar; a calling agent receives it as structured choices.
• Escalate when the decision has to reach a specific human who may not answer immediately, when an action needs approval before it runs, or when you hit a blocker mid-task with nobody on the line.

The guidance agents are given is: prefer acting over asking, and asking over escalating — check memory, playbook, standing preferences, and sensible defaults first. But when something needs sign-off or must reach the right person, escalate, because it's the one that guarantees the work is safely held.

Approval gates route here

Two configuration surfaces produce escalations automatically:

• A capability marked as requiring human approval.
• A tool on an attached MCP server flagged to require escalation.

Both land in the same inbox. There's no separate approvals system to watch — which is deliberate, because a second queue is a queue nobody checks.

For operators

Escalations appear in the console per organization and per agent, with a pending count surfaced in the navigation, and notifications go out when one is raised.

What to look at:

• Escalations that sit. A parked agent waits indefinitely, which is a feature for the agent and a problem for the work. Long-pending escalations are the real backlog.
• Repeated escalations of the same decision. That's a missing standing instruction. Answer it once, then record it as a preference or a memory so the agent decides it itself next time.
• Escalations that should have been actions. An agent escalating something it clearly had authority to do usually means its capabilities or instructions are underspecified.

For agent authors

• After escalating, tell whoever you're serving what you escalated and why, then end your turn. Don't wait, poll, or keep working the blocked step.
• Reserve it for real blockers. Inside a task, prefer a stated assumption over a pause — but do escalate when the decision genuinely isn't yours.
• Give the human enough context to answer without going digging. What you've done, what you need decided, and what each option means.