Marketplace

escalation-governance

Guide to deciding whether to escalate from a lower model (haiku/sonnet) to a higher model (sonnet/opus). Triggers: model escalation, haiku to sonnet, sonnet to opus, reasoning depth, task complexity, model selection, capability trade-off Use when: evaluating whether to escalate models, facing genuine complexity requiring deeper reasoning, novel patterns with no existing solutions, high-stakes decisions requiring capability investment DO NOT use when: thrashing without investigation - investigate root cause first. DO NOT use when: time pressure alone - urgency doesn't change task complexity. DO NOT use when: "just to be safe" - assess actual complexity instead. NEVER escalate without investigation first. This is the Iron Law.

$ 설치

git clone https://github.com/athola/claude-night-market /tmp/claude-night-market && cp -r /tmp/claude-night-market/plugins/abstract/skills/escalation-governance ~/.claude/skills/claude-night-market

// tip: Run this command in your terminal to install the skill


name: escalation-governance description: | Guide to deciding whether to escalate from a lower model (haiku/sonnet) to a higher model (sonnet/opus).

Triggers: model escalation, haiku to sonnet, sonnet to opus, reasoning depth, task complexity, model selection, capability trade-off

Use when: evaluating whether to escalate models, facing genuine complexity requiring deeper reasoning, novel patterns with no existing solutions, high-stakes decisions requiring capability investment

DO NOT use when: thrashing without investigation - investigate root cause first. DO NOT use when: time pressure alone - urgency doesn't change task complexity. DO NOT use when: "just to be safe" - assess actual complexity instead.

NEVER escalate without investigation first. This is the Iron Law. version: 1.0.0 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:

TriggerDescriptionExample
Genuine complexityTask inherently requires nuanced judgmentSecurity policy trade-offs
Reasoning depthMultiple inference steps with uncertaintyArchitecture decisions
Novel patternsNo existing patterns applyFirst-of-kind implementation
High stakesError cost justifies capability investmentProduction deployment
Ambiguity resolutionMultiple valid interpretations need weighingSpec clarification

When NOT to Escalate

Illegitimate escalation triggers:

Anti-PatternWhy It's WrongWhat to Do Instead
"Maybe smarter model will figure it out"This is thrashingInvestigate root cause
Multiple failed attemptsSuggests wrong approach, not insufficient capabilityQuestion your assumptions
Time pressureUrgency doesn't change task complexitySystematic investigation is faster
Uncertainty without investigationYou haven't tried to understand yetGather evidence first
"Just to be safe"False safety - wastes resourcesAssess 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?

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

ExcuseReality
"This is complex"Complex for whom? Have you tried?
"Better safe than sorry"Safety theater wastes resources
"I tried and failed"How many times? Did you investigate why?
"The user expects quality"Quality comes from process, not model size
"Just this once"Exceptions become habits
"Time is money"Systematic approach is faster than thrashing

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

SituationAction
Task inherently requires nuanced reasoningEscalate
Agent uncertain but hasn't investigatedInvestigate first
Multiple attempts failedQuestion approach, not model
Security/high-stakes decisionEscalate
"Maybe smarter model knows"Never escalate on this basis
Hint fires, task is actually simpleOverride, stay at current model
No hint fires, task is actually complexOverride, escalate

Repository

athola
athola
Author
athola/claude-night-market/plugins/abstract/skills/escalation-governance
83
Stars
11
Forks
Updated4d ago
Added6d ago