Escalation policy

Rules that send a run to a different control path when a stated condition appears, such as an unresolved error, uncertain classification, policy conflict, spend limit, or unusual consequence.

An escalation policy defines what happens when the normal path no longer has enough evidence or authority to continue. A run might stop, ask for missing information, invoke a specialist model, open a ticket, switch to simulation, or wait for an authorized person. A customer-service agent can resolve a documented password-reset case, route an uncertain refund to a payment-policy check, and send a legal complaint to the responsible team. The destination follows the trigger; escalation does not automatically mean manual approval.

Builder example

A useful policy separates ordinary variation from conditions that change the decision. If the policy triggers on everything, the agent becomes a queue. If it ignores uncertainty and limits, the normal path acts outside its evidence. Define the trigger from observable state, name the destination, preserve the work already completed, and state what information the next step needs.

Common confusion: An escalation policy is complementary to an autonomy budget, but they address different questions. The autonomy budget defines scope: how many steps, which tools, what data. The escalation policy defines triggers: which conditions cause the agent to stop and defer. An agent can be within its autonomy budget and still hit an escalation trigger.