Resolver：エージェントの知性をルーティングする

In "Thin Harness, Fat Skills", I introduced five definitions for building agent systems that actually work. Skills got all the attention. People bookmarked the skill-as-method-call pattern, the diarization concept, the thin harness architecture. Good. Those matter. But the one that got almost no attention is the one that matters most. Resolvers. And the reason they got ignored is the same reason they're so important: they're invisible when they work, and catastrophic when they don't. A resolver is a routing table for context. When task type X appears, load document Y first. That's it. One sentence. But that one sentence is the difference between an agent that compounds intelligence and an agent that slowly forgets what it knows. This is the story of how I learned that the hard way. The 20,000-line confession My CLAUDE.md was 20,000 lines. I'm not proud of this. Every quirk, every pattern, every lesson I'd ever encountered with Claude Code, every convention for my codebase, every edge case I'd been burned by. I kept adding. The file kept growing. It felt productive. It felt like I was making the model smarter. I wasn't. I was drowning it. The model's attention degraded. Responses got slower and less precise. Claude Code literally told me to cut it back. That's when you know you've gone too far — the AI is telling you to stop talking. The instinct is natural. You want the model to know everything. So you cram everything into the system prompt, the instructions file, the context window. You're trying to make the model omniscient by proximity. It doesn't work. 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 was about 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. That 200-line file is the resolver. It replaced 20,000 lines of instructions. And the system immediately got better — faster responses, more accurate filing, fewer hallucinations. Not because the model got smarter. Because I stopped blinding it with noise. The misfiling that revealed everything I asked my agent to ingest Will Manidis's essay "No New Deal for OpenAI" — a devastating policy analysis of OpenAI's industrial policy brief. It's the kind of piece that breaks down a company's regulatory strategy, maps the political implications, names the institutional actors. Sharp civic analysis. The agent filed it in `sources/`. Wrong. `sources/` is for raw data dumps and bulk imports. CSV files. API exports. Scraped datasets. This was political analysis — it belongs in `civic/`, where policy pieces, political actors, and institutional dynamics live. Why did it happen? The idea-ingest skill had hardcoded `brain/sources/` as the default directory. It didn't consult the resolver. It had its own half-assed filing logic baked into the skill itself. When no explicit path was given, it fell back to `sources/` the way a lazy intern throws everything in the "misc" folder. One misfiled article. I could have fixed it and moved on. Instead I pulled the thread. The audit When I caught the Manidis misfiling, I audited every skill that writes to the brain. I have 13 of them. Skills for ingesting articles, PDFs, meeting transcripts, videos, investor updates, voice notes, tweets. Each one writes pages to the brain repo. Only 3 out of 13 referenced the resolver. The other 10 had hardcoded paths. Idea-ingest defaulted to `sources/`. PDF-ingest defaulted to `originals/`. Meeting-ingest wrote to `meetings/`. Each skill had internalized its own filing assumptions. Each one was a potential misfiling waiting to happen. This is the pattern that kills agent systems. Not a dramatic failure. Not a hallucination that produces nonsense. A slow, silent drift where information goes to the wrong place, connections don't form, and the knowledge base gradually becomes a junk drawer with 14,700 files in it instead of a structured intelligence layer. The fix wasn't fixing 10 skills individually. That's whack-a-mole. You fix one, another drifts. The fix was a shared filing rules document — `_brain-filing-rules.md` — and a mandate that every brain-writing skill reads `RESOLVER.md` before creating any page. One rule. Ten skills fixed. The filing rules doc also catalogs common misfiling patterns. Sources vs. originals. People vs. companies (when someone IS a company). Civic vs. sources (the Manidis case). Every mistake, documented, so the same mistake can't happen a different way. Zero misfilings since. Every new skill that writes to the brain now has a two-line mandate at the top: *Before creating any new brain page, read `brain/RESOLVER.md` and `skills/_brain-filing-rules.md`. File by primary subject, not by source format or skill name.* The invisible skill problem The above example talks about where to put files in your memory repo, but it applies to skill files (fat skills) and code to call (fat code) as well. A resolver routes tasks to skills. But what happens when a skill exists and the resolver doesn't know about it? For my OpenClaw, we built a signature-tracking system inside the executive assistant skill. It worked perfectly. Tracked DocuSign deadlines, surfaced unsigned documents, drafted reminders. Beautiful piece of engineering. Completely invisible. When someone asked "check my signatures" or "what do I need to sign," the system shrugged. The resolver didn't have a trigger for signatures. The skill existed. The capability existed. The system couldn't reach it. It's like having a surgeon on staff but not listing them in the hospital directory. This is worse than not having the skill at all. A missing skill is honest — the system says "I can't do that" and you know to build it. A skill that exists but isn't reachable creates the illusion of capability. You think the system handles signatures. It doesn't. And you don't find out until the moment it matters. After a month of building, we had 40+ skills. Some created in response to specific incidents, others spawned by sub-agents running crons. Nobody was maintaining the resolver table. Skills were being born but not registered. The system had capabilities it didn't know it had. So I built resolver trigger evals. A test suite of 50 sample inputs with expected outputs: Input: "check my signatures" Expected: executive-assistant (signature section) Input: "who is Pedro Franceschi" Expected: brain-ops → gbrain search Input: "save this article to brain" Expected: idea-ingest + RESOLVER.md Two failure modes. False negative: skill should fire but doesn't, because the trigger description is wrong or missing. False positive: wrong skill fires, because two triggers overlap. Both fixable by editing markdown. No code changes. The resolver is a document, and documents are cheap to fix. I told my Claw: "Make sure the resolver is tested and also there are proper eval LLM tests for all the prompts and skills that use the resolver." This isn't optional. If you can't prove the right skill fires for the right input, you don't have a system. You have a collection of skills and a prayer. The meta-skill The trigger evals catch routing failures. But there's a deeper problem: skills that exist but have no path from the resolver at all. Not a wrong path — no path. I was debugging a skill that should have fired and didn't. The usual drill: check the trigger description, check the resolver table, trace the chain. And I realized there was no systematic way to verify that a skill was reachable. You could check one skill at a time. You couldn't check all of them. So I invented `check-resolvable`. A meta-skill that walks the entire chain — AGENTS.md → skill file → code — and finds dead links. I told my agent: "Check if there is a direct line between the agents.md resolver all the way to this running. And then remember this as a 'check-resolvable' skill. The skill should actually check if this skill or codepath is either directly called out in the resolver or callable via something in the resolver. And if it isn't, figure out what resolvable skill should call it." First run found 6 unreachable skills. Six capabilities the system had built but couldn't access. A flight tracker that nobody could invoke by asking about flights. A content-ideas generator that only ran on cron but couldn't be triggered manually. A citation fixer that existed in the skills directory but wasn't listed in the resolver at all. Six. Out of 40+. Fifteen percent of the system's capabilities were dark. Fixed in an hour. Just added triggers to AGENTS.md. Now check-resolvable runs weekly. It's the resolver equivalent of a linter — it tells you what's broken before a user discovers it the hard way. Context rot Here's the thing nobody tells you about resolvers: they decay. Day 1, the routing table is perfect. Every skill is registered. Every trigger is accurate. Every path resolves. You feel like a genius. Day 30, three new skills exist that nobody added to the resolver. They were built in response to real needs, by sub-agents running at 3 AM, and nobody updated the table. Day 60, two trigger descriptions don't match how users actually phrase things. The skill handles "track this flight" but users say "is my flight delayed?" The description says one thing. The user says another. The skill doesn't fire. Day 90, the resolver is a historical document. An artifact of what the system *used to* be able to do. Not what it can do now. I noticed the system was drifting. Skills were being invoked by direct instruction — "read skills/flight-tracker/SKILL.md" — instead of through the resolver, because the resolver didn't have the right triggers. The system worked because I knew which skill to call. That's not a system. That's a person with a filing cabinet. Yesterday, in office hours with a YC company, a CTO asked me: "Could an RLM be used to solve context rot particularly around resolvers?" The idea: a reinforcement learning loop where the system observes every task dispatch. Which skill fired. Which didn't. Which tasks had no match. Which tasks matched the wrong skill. And periodically — maybe nightly, maybe weekly — it rewrites the resolver based on observed evidence. Not a human maintaining a table. The table maintaining itself. Eight hundred task dispatches over a month. The system sees that "is my flight on time" never triggers flight-tracker but "check my flight" does. It rewrites the trigger description. The system sees that pdf-ingest fires for investor update emails, but investor-update-ingest should have caught them first. It adjusts priority. This is forward-looking. We haven't fully built it. Claude Code's AutoDream system — memory consolidation during idle time — is a primitive version. It reviews accumulated context and compresses it. Apply that principle to the resolver specifically, and you get a routing table that improves with use. A resolver that learns from its own traffic. That's the endgame for agent governance. Resolvers are fractal One more principle, and it's the one that makes everything click. Resolvers compose. They exist at every layer of the system, not just the top. The skill resolver lives in AGENTS.md. It maps task types to skill files. "Who is this person?" → brain-ops. "Ingest this PDF" → pdf-ingest. "Check my calendar" → google-calendar. This is the one everyone thinks of. The filing resolver lives in RESOLVER.md. It maps content types to directories. Person → `people/`. Company → `companies/`. Policy analysis → `civic/`. This is the one that caught the Manidis misfiling. The context resolver lives inside each skill. When the executive assistant skill fires, it has its own internal routing: email triage goes one way, scheduling goes another, signature tracking goes a third. Sub-routing within the skill. Claude Code already has this pattern. Every skill has a description field. The model matches user intent to skill descriptions automatically. You never have to remember that `/ship` exists. The description *is* the resolver. It's resolvers all the way down. The same architecture, at every layer. That's what makes it scale from 5 skills to 50, from 1,000 files to 25,000, from a toy demo to a production system that processes 200 inputs a day. The shape of the thing Let me pull this together. A resolver is 200 lines of markdown that replaced 20,000 lines of crammed context. When it's missing, skills invent their own filing logic and everything slowly degrades. When it's present but untested, capabilities go dark — you have a surgeon the hospital can't find. When it's tested but static, it rots within 90 days. When it's tested and self-healing, the system compounds. The pattern: Load the right context at the right moment. Don't cram. Mandate that every skill consults the resolver. Don't trust individual filing logic. Test the routing, not just the output. Trigger evals. Audit reachability. Check-resolvable. Weekly. Make the resolver learn from its own traffic. The endgame. The resolver is the governance layer of an agent system. The traffic cop, the filing clerk, the org chart, and the institutional memory, all in one document that a model can read in 200 milliseconds. Almost nobody is building them explicitly. Everyone is cramming 20,000 lines into the system prompt and wondering why the model seems dumber than it should be. The model isn't dumb. It's drowning. Give it a routing table and watch what happens. The thing I didn’t realize I was building Up to this point, I’ve been describing resolvers as a technical pattern. A way to make agents work better. Route tasks. Load the right context. Avoid drowning the model. That framing is true. It’s also too small. What I actually built is closer to management. Think about what’s happening in a real system with 40+ skills and 25,000 files. You don’t just have code. You have an organization. Skills are employees. Each one has a capability. Some are specialists. Some are generalists. Some only run on cron. Some are user-facing. The resolver is the org chart. It defines who handles what, how tasks get routed, and what happens when something doesn’t match. It’s also escalation logic — when one path fails, where does it go next? The filing rules are internal process. Where information lives. How decisions get recorded. What counts as a “person” vs a “company” vs a “policy analysis.” Without that, you don’t have a knowledge base. You have a junk drawer. check-resolvable is audit and compliance. It doesn’t care if the code is beautiful. It asks a simpler question: can the system actually do what it claims? Are there capabilities that exist but can’t be reached? Trigger evals are performance reviews. Given a real input, does the right part of the organization respond? If not, you don’t retrain the model. You fix the description. You update the routing. You make the org legible. Once you see it this way, a lot of the confusion around agents disappears. The problem isn’t that models aren’t smart enough. The problem is that we’ve been building organizations with no management layer. Just a pile of talented employees and a vague hope they’ll coordinate. Resolvers are that missing layer. And once you treat them that way, the goal changes. You’re not just wiring up tools. You’re designing an organization that can grow, adapt, and stay coherent over time. That’s a different problem. And a much bigger one. I want you to build your own brain Everything in this article — the resolver pattern, the trigger evals, check-resolvable, the filing rules, the self-healing loop — runs in production, every day, on my personal agent. It processes 200 inputs daily. It has 25,000 files. It compounds. I open-sourced the entire system. My open source project GBrain ships with the resolver pattern built in. `gbrain init` creates RESOLVER.md, the decision tree, and the disambiguation rules. Your agent starts filing correctly from day one. The check-resolvable skill comes built-in. You don't have to discover these patterns by breaking things — the system embodies them. GStack is the coding layer. Fat skills in markdown. 72,000+ stars on GitHub. The skills in GStack call the knowledge in GBrain. Together they're the full architecture: intelligence on tap. OpenClaw or Hermes Agent is the conductor — the thin harness that runs the agent loop, manages sessions, and executes crons. GBrain and GStack are skills that plug into it. Your agent reads GBrain's compiled truth before answering. Your crons run the rollup pipelines while you sleep. This isn't a SaaS product. It's an architecture. The source code is open. The skills are markdown. The brain is a git repo you own. If any piece disappeared tomorrow, your knowledge survives as plain text files. This is the new dawn of personal software. This is not packaged software. This is software that you build for yourself, but with the fat skills and fat code and thin harness that is your own personal mini-AGI. The future is already here, and I want you to have it in your pocket. The architecture fits on an index card. The knowledge fits in a git repo. The only thing missing is you starting. -- GBrain to build your personal mini-AGI in OpenClaw or Hermes Agent github.com/garrytan/gbrain GStack to help you build faster in Claude Code github.com/garrytan/gstack