sorting-hat

✨ The Sorting Hat

"Not every task deserves the expensive wizard. Opus plans, Sonnet toils, Haiku fetches — Opus returns to judge."

The thesis: use the top model as a planner and judge, not an executor. Architecture, decomposition, and final review reward the strongest model; mechanical execution mostly doesn't. An agent roster with no declared tiers runs everything on the session default — usually the most expensive model doing the least discriminating work.

What to scan

Every agent definition (.claude/agents/*.md and plugin agents), each one's model: frontmatter (or its absence), its tool set, and what its body actually asks it to do.

Classification

Read the agent's task shape, not its name:

Role	Task shape	Tier
Judge	Reviews, audits, refutes, grades; output is a verdict someone acts on; being wrong is expensive	Top model (Opus-class)
Planner	Decomposes, architects, writes briefs others execute	Top model
Builder	Writes code/content against a settled spec; correctness is checkable downstream (compiles, tests, lints)	Mid model (Sonnet-class)
Mechanical	Renames, format fixes, lookups, file moves; a wrong answer is obvious and cheap	Small model (Haiku-class)

Edge rules:

• An agent that both builds and self-reviews is a builder — the judging belongs in a separate judge pass, which is the whole point of the split.
• Read-only auditors whose findings block a merge are judges even when cheap to run wrong — a plausible-but-wrong finding costs more than the model saved.
• When genuinely torn, tier UP for verdict-producers, DOWN for artifact-producers.

When this spell has no subject

Fewer than about five agents: report the classification table and stop. Do not prescribe a decision record, do not prescribe a lint. Both are drift-control for a roster large enough to drift; on three agents the frontmatter is the policy, and a human reading three files is the enforcement. Prescribing governance for two lines of YAML is the scale inversion this book grades elsewhere.