Your AI Agent Needs an Escalation Path: Introducing Escalation Engineering A developer writing as miruky has proposed "Escalation Engineering," a design practice for specifying how an AI agent hands off control when its current model, tools, information or authority cannot complete a task. The proposal defines a contract covering the new owner, permitted actions, evidence, return conditions and limits, and ships a reference implementation on GitHub that runs locally without an API key. The author positions the practice alongside prompt, context, harness, loop and graph engineering, citing RouteLLM and LangGraph interrupts as prior work on routing and pause-and-resume mechanisms. Hi, I'm miruky. Imagine asking a coding agent to update an authentication library and publish a release. It can inspect the code, edit a dependency, and run checks. Then the same failure returns. Or the checks pass, but publishing requires permission the agent does not have. Both situations need an explicit decision about how work continues. I want to make that decision a design object. I call the practice Escalation Engineering. The reference implementation is available at miruky/escalation-engineering https://github.com/miruky/escalation-engineering , and the example runs locally without an API key. Escalation Engineering is the practice of designing how an AI system moves to an appropriate execution path when its current agent, model, tools, information, or authority cannot meet the task's requirements. The contract specifies the new owner, permitted actions, evidence, return conditions, and limits. An escalation might send a diagnosis to a specialist, request a decision from a human, switch to a more capable model, restrict an agent to proposing changes, or end the run. The destination depends on what is missing. More reasoning capacity can help with an unfamiliar API; a release approval must come from an authorized reviewer. The proposal gives these choices a common contract. Routing, human oversight, approval gates, and recovery already have substantial prior work. For example, RouteLLM https://arxiv.org/abs/2406.18665 studies choosing between stronger and weaker models, and LangGraph interrupts https://docs.langchain.com/oss/python/langgraph/interrupts provide pause-and-resume mechanisms. Escalation Engineering asks how those mechanisms participate in a complete transfer of control. An ordinary retry keeps the same owner and execution contract. An escalation can introduce another model, specialist, tool, evidence source, or authorized decision maker, or select a terminal stop. The policy chooses that change from the prerequisite the current path is missing. I think of it as a control plane for autonomous work. An execution plan describes the tasks. The escalation policy decides who may continue, with which tools and evidence, and under what return conditions. Both can be implemented in the same graph or program. In the release example, changing from the coding agent to a debugging specialist changes the owner of the diagnosis. The specialist receives the failing input and relevant code. Publishing still requires its own approval, even after that specialist resolves the defect. In my previous article on Prompt through Graph Engineering https://dev.to/miruky/from-prompt-to-graph-engineering-explained-with-one-bug-18mb , I used one bug to explain several design perspectives. The same perspectives help locate escalation work. | Practice | Main design question | Example in the release task | |---|---|---| | Prompt Engineering | Instructions for the model | Describe the required compatibility behavior. | | Context Engineering | Information available at this step | Supply the current API and failing input. | | Harness Engineering | Tools and constraints around execution | Allow local edits and checks. | | Loop Engineering | Attempt, inspection, and revision rules | Repair an observed defect within a retry budget. | | Graph Engineering | Coordination among tasks and participants | Route implementation through an independent review. | | Escalation Engineering | Execution ownership when the current path is insufficient | Request a specialist or a scoped release decision. | I use these as complementary questions. The Graph Engineering paper https://arxiv.org/abs/2608.21156 already discusses dynamic structures involving tasks, agents, and system state. A graph can encode escalation policies too. The named control contract specifies requirements that can be inspected across implementations, including a single-agent loop. Consider a workflow that routes a failed check to another agent. Its next destination is specified. To describe the escalation completely, we still need the recipient's permitted actions, the evidence it receives, what counts as resolving the blocker, and what happens if it cannot resolve it. The release task contains two kinds of limits. An agent may lack the knowledge to repair an incompatibility. It may also lack authorization to publish the resulting artifact. Increasing model capability addresses the first limit; authorization remains subject to the application's policy. A useful everyday analogy is a technician fixing a broken oven in a rental apartment. A more experienced technician can diagnose a difficult fault. Replacing the entire kitchen still requires the property owner's decision. Experience does not sign the purchase order. For an agent, keep four properties explicit. Capability describes what it can solve. Authority describes what operations it is permitted to perform. Autonomy describes how much it may do without a fresh decision. Accountability identifies the person or organizational role responsible for the permitted scope. Assigning work to a model does not transfer a human's organizational accountability to that model. Escalation can reduce autonomy. A coding agent that finds conflicting requirements might keep read access while losing permission to edit. It can prepare alternatives until the product owner chooses the requirement. A security specialist might inspect an authentication change without receiving release credentials. That is why I avoid a universal ladder from a small model to a large model to a human. A permission boundary can require a human immediately. A routine transient failure might justify a bounded retry. A prohibited operation should stop. The policy should choose the route from the actual condition. The coding agent is updating an authentication dependency. It has local inspection and editing tools. Publishing is owned by the release controller. Suppose the same compatibility check fails after three repair attempts. In this illustrative policy, that condition asks a debugging specialist to investigate. Three is a chosen limit for the example; another application should set its limit from its own cost and failure tolerance. The trigger should come from observable state. A process exit status, repeated failure signature, missing required field, conflicting source, exceeded budget, or requested operation outside an actor's capabilities can be inspected by the host application. A model's statement that it is "95% confident" needs calibration against outcomes before it can support a numerical confidence threshold. The destination should supply the missing resource. Debugging expertise goes to the specialist. A disputed requirement goes to its owner. Release authorization goes to the authorized reviewer. An unavailable reviewer leaves the consequential action paused until its deadline; the timeout policy can close the request. Send a difficult diagnosis to a model selected for that kind of problem, a domain specialist, or an additional diagnostic tool. Send conflicting evidence to an independent verifier. Record what the destination adds and what must be verified before the ordinary execution path resumes. The specialist needs enough state to begin a different diagnosis. A whole chat transcript can bury the failing input, current artifact, and actual decision request. The packet should preserve the goal, current state, relevant evidence, remaining uncertainty, and permitted next action. For the later release approval, a conceptual packet could look like this. These fields describe the contract; the repository's Python API creates its own canonical packet. { "goal": "Publish the compatible authentication update", "operation": "publish local", "artifact": "auth-update.whl", "artifact digest": "sha256: