The Resolver Pattern
A resolver is a routing table for context. When task type X appears, load document Y first. 200 lines of markdown that replace 20,000 lines of crammed instructions. The difference between an agent that compounds intelligence and an agent that slowly forgets what it knows. Source: Filing Decision Tree; Skill Resolver; Agent Operations Hub
The Problem: The 20,000-Line Instruction File
The natural instinct is to make the model omniscient by proximity - cram everything into the system prompt, the instructions file, the context window. A CLAUDE.md that grows to 20,000 lines. Every quirk, every pattern, every convention, every edge case. It feels productive.
It isn't. The model's attention degrades. Responses get slower and less precise. The model itself will tell you to cut it back.
You can't make someone smarter by shouting louder. You make them smarter by giving them the right book at the right moment.
The Fix: 200 Lines
A numbered decision tree. Pointers to documents. When the model needs to file something, it walks the tree:
- Is it a person? →
/people/directory - A company? →
/companies/directory - A policy analysis? →
/civic/directory
Twenty thousand lines of knowledge, accessible on demand, without polluting the context window. The system immediately got better - faster responses, more accurate filing, fewer hallucinations. Not because the model got smarter. Because it stopped being blinded by noise.
Three Types of Resolver (Fractal)
Resolvers compose. They exist at every layer, not just the top.
Skill resolver (AGENTS.md / SKILL-RESOLVER.md) - maps task types to skill files. "Who is this person?" → brain-ops. "Ingest this PDF" → pdf-ingest. "Review this design" → gstack-design-review.
Filing resolver (RESOLVER.md) - maps content types to directories. Person → people/. Company → companies/. Policy analysis → civic/. Concept → concepts/.
Context resolver (inside each skill) - sub-routing within the skill. Email triage goes one way, scheduling another, signature tracking a third.
The same architecture at every layer is what makes it scale from 5 skills to 50, from 1,000 files to 25,000.
Garry Tan's X Article is the external articulation of the same pattern: resolvers are the governance layer that keeps skill-based agent systems from degenerating into hidden capabilities, hardcoded filing rules, and context rot. The article's concrete production audit found that most brain-writing skills had drifted away from the shared resolver, which is exactly why Kevin's wiki treats RESOLVER.md, SKILL-RESOLVER.md, routing doctors, and trigger evals as infrastructure rather than documentation garnish. Source: X/@garrytan and Glean mirror, 2026-07-04
Failure Modes
Silent misfiling
The most insidious failure. Not a dramatic hallucination - a slow, silent drift where information goes to the wrong place, connections don't form, and the knowledge base gradually becomes a junk drawer. Example: an article on OpenAI policy filed to sources/ (raw data dumps) instead of civic/ (policy analysis) because the ingestion skill had hardcoded its own filing logic instead of consulting the resolver.
The fix: a shared filing rules document and a mandate that every brain-writing skill reads RESOLVER.md before creating any page. One rule. Ten skills fixed.
Invisible skills (dark capabilities)
A skill exists but the resolver doesn't know about it. The system has a surgeon but the hospital directory doesn't list them. Worse than not having the skill - it creates the illusion of capability.
A resolver audit found 6 unreachable skills out of 40+ (15% dark). A flight tracker nobody could invoke. A citation fixer not listed in the resolver. Fixed in an hour by adding triggers.
The fix: check-resolvable - a script that walks the routing chain (SKILL-RESOLVER + hub + tool-hierarchy → skill files on disk) and reports dark skills (executable but unrouted and weak description → truly invisible), dead pointers (routing docs reference a missing file), and weak triggers. Implemented at scripts/check-resolvable.ts (npm run check-resolvable); its first run found 6 dead pointers (wrong namespace/path) in the resolver docs. Run it on every routing-doc edit and gate on 0 dead pointers. Pair with scripts/audit-rule-typing.ts (npm run audit-rule-typing) after changing Cursor rule alwaysApply modes — measures always-on token budget and flags heavy rules that should be Agent-Requested. Source: built 2026-06-13; updated for skill-registry model, 2026-06-27
Context rot
Day 1: the routing table is perfect. Day 30: three new skills exist that nobody added. Day 60: trigger descriptions don't match how users actually phrase things. Day 90: the resolver is a historical artifact of what the system used to be able to do.
The fix: trigger evals - a test suite of sample inputs with expected outputs. Two failure modes to catch: false negatives (skill should fire but doesn't) and false positives (wrong skill fires because triggers overlap). Both fixable by editing markdown. Implemented: scripts/trigger-eval.ts + config/trigger-evals.json (npm run trigger-eval) checks every realistic phrasing routes to an existing skill whose trigger surface (description + routing entry) covers it. Paired with check-resolvable (structure) as npm run routing-doctor; check-resolvable runs in the pre-commit gate.
Progressive disclosure for always-on rules (Jun 2026 lesson)
The operating layer can drift from the resolver ideal without violating the pattern — if heavy docs load only on demand. Wrong fix: delete or compact tool-hierarchy.mdc / SKILL-RESOLVER detail to save tokens. Right fix: flip bloated Cursor rules from alwaysApply: true to Agent Requested (~50-token description always in context; full body loads when the task matches). Same information, ~4.8K tokens saved per message on global rules alone. Resolver content stays complete; activation becomes typed. Pair with npm run check-resolvable before any routing audit — the first run had false dead-pointers from .md/.mdc alternation bugs. Source: Cursor session 0a6ab021, 2026-06-12; check-resolvable built 2026-06-13
The Endgame: Self-Healing Resolvers
A reinforcement learning loop where the system observes every task dispatch. Which skill fired. Which didn't. Which tasks had no match. Periodically rewrites the resolver based on observed evidence. A routing table that improves with use.
Claude Code's AutoDream (memory consolidation during idle time) is a primitive version. Apply that principle to the resolver specifically: a routing table that learns from its own traffic.
Resolvers Are Management
Once you see it, the confusion around agents disappears:
| Agent concept | Management equivalent |
|---|---|
| Skills | Employees with capabilities |
| Resolver | Org chart + escalation logic |
| Filing rules | Internal process |
| check-resolvable | Audit and compliance |
| Trigger evals | Performance reviews |
The problem isn't that models aren't smart enough. The problem is building organizations with no management layer. Just talented employees and a vague hope they'll coordinate.
Kevin's Implementation
Kevin's wiki implements the resolver pattern at two layers:
wiki/RESOLVER.md- filing resolver. Decision tree for where new wiki pages go (directory-level routing).wiki/SKILL-RESOLVER.md- skill resolver. Intent-to-skill dispatcher mapping all installed skills across 10 categories (always-on, wiki ops, ingestion, design, code review, QA, research, career, operational, animation).
The two resolvers serve different purposes and both are consulted: SKILL-RESOLVER to find the right skill, then RESOLVER to file the output correctly.
Timeline
- 2026-07-04 | Source-reviewed Garry Tan's "Resolvers: The Routing Table for Intelligence" X Article. The anonymous X article fetch exposed only a login shell, but search metadata and the readable Glean mirror confirmed that this page already captured the article's core resolver, dark-skill, misfiling, context-rot, and management-layer arguments. Source: X/@garrytan, 2026-04-15
- 2026-04-14 | Compiled the resolver pattern into the wiki. The core insight: route context with small routing tables instead of cramming everything into prompts. Kevin's wiki implements both skill-level and filing-level resolvers.
- 2026-06-13 | Added progressive-disclosure lesson: flip heavy Cursor rules to Agent Requested instead of deleting resolver detail; pair with
check-resolvablebefore routing audits. Source: session 0a6ab021, 2026-06-12