/escalation-governance

name: escalation-governance
description: 'Assess whether to escalate models. Use when evaluating reasoning depth.'
alwaysApply: false
category: agent-workflow
tags:
- escalation
- model-selection
- governance
- agents
- orchestration
dependencies: []
estimated_tokens: 800

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:**

| Trigger | Description | Example | |---------|-------------|---------| | Genuine complexity | Task inherently requires nuanced judgment | Security policy trade-offs | | Reasoning depth | Multiple inference steps with uncertainty | Architecture decisions | | Novel patterns | No existing patterns apply | First-of-kind implementation | | High stakes | Error cost justifies capability investment | Production deployment | | Ambiguity resolution | Multiple valid interpretations need weighing | Spec clarification |

When NOT to Escalate

**Illegitimate escalation triggers:**

| Anti-Pattern | Why It's Wrong | What to Do Instead | |--------------|----------------|---------------------| | "Maybe smarter model will figure it out" | This is thrashing | Investigate root cause | | Multiple failed attempts | Suggests wrong approach, not insufficient capability | Question your assumptions | | Time pressure | Urgency doesn't change task complexity | Systematic investigation is faster | | Uncertainty without investigation | You haven't tried to understand yet | Gather evidence first | | "Just to be safe" | False safety - wastes resources | Assess actual complexity |

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?
• [ ] How many ways does this codebase already implement the concern,

and which one is current?

Two coexisting implementations of one concern make a task look harder than it is. That is a knowledge gap: count them with a reference search and read both before escalating (`docs/knowledge-corpus/decoherence.md`, which calls them models of a concern).

**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

Reasons That Do Not Justify Escalation

Escalation needs a reason tied to the task. These common ones fail the four steps above, and the constraint behind each says why:

• "This is complex" needs the attempt that showed the current model

falls short. Complexity alone does not predict model failure.

• "Better safe than sorry" names no risk. A larger model spends more

without reducing a risk nobody identified.

• "I tried and failed" needs the attempt count and why it failed. A

failure not yet investigated is often a context problem that a larger model would repeat.

• "The user expects quality" is met by process: tests, review and

evidence. Model size does not supply them.

• "Just this once" still needs the documented reason, since an

exception repeated without one becomes the default.

• "Time is money" favors investigation. Thrashing on a larger model

is slower than a systematic pass on the current one.

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