escalation-governance

Escalation Governance

Overview

Model escalation (haiku→sonnet→opus) trades speed/cost for reasoning capability. This trade-off must be justified.

Core principle: Escalation is for tasks that genuinely require deeper reasoning, not for "maybe a smarter model will figure it out."

The Iron Law

NO ESCALATION WITHOUT INVESTIGATION FIRST

Escalation is never a shortcut. If you haven't understood why the current model is insufficient, escalation is premature.

When to Escalate

Legitimate escalation triggers:

When NOT to Escalate

Illegitimate escalation triggers:

Decision Framework

Before escalating, answer these questions:

1. Have I understood the problem?

• Can I articulate why the current model is insufficient?
• Have I identified what specific reasoning capability is missing?
• Is this a capability gap or a knowledge gap?

If knowledge gap: Gather more information, don't escalate.

2. Have I investigated systematically?

• Did I read error messages/outputs carefully?
• Did I check for similar solved problems?
• Did I form and test a hypothesis?

If not investigated: Complete investigation first.

3. Is escalation the right solution?

• Would a different approach work at current model level?
• Is the task inherently complex, or am I making it complex?
• Would breaking the task into smaller pieces help?

If decomposable: Break down, don't escalate.

4. Can I justify the trade-off?

• What's the cost (latency, tokens, money) of escalation?
• What's the benefit (accuracy, safety, completeness)?
• Is the benefit proportional to the cost?

If not proportional: Don't escalate.

Escalation Protocol

When escalation IS justified:

1. Document the reason - State why current model is insufficient
2. Specify the scope - What specific subtask needs higher capability?
3. Define success - How will you know the escalated task succeeded?
4. Return promptly - Drop back to efficient model after reasoning task

Common Rationalizations

Agent Schema

Agents can declare escalation hints in frontmatter:

model: haiku
escalation:
  to: sonnet                 # Suggested escalation target
  hints:                     # Advisory triggers (orchestrator may override)
    - security_sensitive     # Touches auth, secrets, permissions
    - ambiguous_input        # Multiple valid interpretations
    - novel_pattern          # No existing patterns apply
    - high_stakes            # Error would be costly

Key points:

• Hints are advisory, not mandatory
• Orchestrator has final authority
• Orchestrator can escalate without hints (broader context)
• Orchestrator can ignore hints (task is actually simple)

Orchestrator Authority

The orchestrator (typically Opus) makes final escalation decisions:

Can follow hints: When hint matches observed conditions Can override to escalate: When context demands it (even without hints) Can override to stay: When task is simpler than hints suggest Can escalate beyond hint: Go to opus even if hint says sonnet

The orchestrator's judgment, informed by conversation context, supersedes static hints.

Red Flags - STOP and Investigate

If you catch yourself thinking:

• "Let me try with a better model"
• "This should be simple but isn't working"
• "I've tried everything" (but haven't investigated why)
• "The smarter model will know what to do"
• "I don't understand why this isn't working"

ALL of these mean: STOP. Investigate first.

Integration with Agent Workflow

Agent starts task at assigned model
├── Task succeeds → Complete
└── Task struggles →
    ├── Investigate systematically
    │   ├── Root cause found → Fix at current model
    │   └── Genuine capability gap → Escalate with justification
    └── Don't investigate → WRONG PATH
        └── "Maybe escalate?" → NO. Investigate first.

Quick Reference