The Anatomy of My Claude Code System [2026]

What My Claude Code System Actually Looks Like

I lost track of my own Claude Code system a while back. Not in a dramatic way. Someone asked how many moving parts it has and I did not have a real number. Agents, hooks, rules, skills, a memory server, a knowledge graph, a scoring loop that edits its own routing config. At some point a pile of files stops being a pile and starts being a system, and I missed the exact moment it happened.

So I did what I do when I stop trusting my own mental model: I made something re-derive the whole thing from scratch. What came back reads less like a config folder and more like a body. There is a part that decides. Parts that react without deciding anything. A part that remembers. A part that wires everything else together. A part that keeps the whole thing alive when a piece breaks. I wrote all of it up as a 48-page field guide, The Anatomy of a Thinking System, and this post is the tour.

Want the shortest path into any one piece? The free 3-pattern guide covers delegation, memory, and the knowledge graph - three of the five organs below, at concept level.

What Is the Mind of a Claude Code System?

The mind is the orchestrator sitting between me and every subagent. On each message it makes one binary call: handle this directly, or delegate it out. That call runs on a score, not a vibe - scope over 2 files, a research task, a security keyword, each nudges the number up or down, and past a threshold the message routes to a subagent and a model tier instead of staying with me. I wrote up the trait system behind that call in my delegation deep dive, and the exact formula in score-based auto-delegation.

Reflexes and Instincts: The Parts That Never Ask

Reflexes act before I would even think to ask. A hook is a shell command wired to a lifecycle event, no model call involved, so it fires instantly and it never forgets to fire. Next to the hooks sit the always-on rules, the CLAUDE.md-and-friends layer read into context on every single turn whether the task needs it or not. Between the two, a large share of the boring correctness work never touches a token of reasoning. The hook types and working examples live in Claude Code hooks; how I keep the always-on layer from bloating context is in CLAUDE.md rules.

Where Does a Claude Code System Keep Its Memory?

Memory is a separate server, not a chat log. It holds two kinds of things: memory that decays if nothing touches it again, and memory pinned as permanent because I marked it that way. Sessions read from it at the start and write back at the end, so a decision from three weeks ago can still shape what happens today. The full setup is in my persistent memory guide; what changed once I stopped restarting sessions to force a clean state is in session management.

The Wiring: How 600+ Parts Find Each Other

None of the organs above matter if they cannot find each other, which is the wiring's job. Every rule, agent, command and skill registers itself as a node, and the connections between them are explicit edges, not something Claude has to infer from a filename. I built in redundant discovery paths on purpose, so if one lookup route misses a component, at least one other route still finds it. The graph structure and why flat files stopped working past a few dozen components is the whole subject of my knowledge architecture post.

Staying Alive: Self-Healing on a Leash

The last organ keeps the other four honest. A scheduled job checks the system's own health and repairs what it can without waking me up. A separate, more restrained process is allowed to mutate its own routing config based on what worked, but only inside a gate: reversible changes apply on their own, anything touching the safety-critical core stops and waits for me. I wrote up the hook pattern behind the self-correction in self-correcting Claude Code workflows, and a case where the self-regulation did not work is documented, honestly, in a negative result on agent self-regulation.

Does Any of This Actually Work?

Architecture is cheap to describe and expensive to prove. So before I call any of the five organs above real, here is what my own instrumentation actually found, not what I assumed going in.

The system runs on somewhere north of 600 working parts. I say "north of" on purpose - different registries inside the system count them slightly differently, and I would rather admit the discrepancy than round to a number that looks cleaner than it is.

The cost picture surprised me the most. Over 60 days and 326 sessions, the fresh wording of a prompt accounts for about 6% of what a session costs. Context ingestion and re-reads eat roughly 83%, the overwhelming majority. That reframed how I think about the mind-and-wiring combo: a good routing system is not a nice-to-have next to an expensive model. It is a substitute for one.

Memory is honest about its limits too. On LongMemEval-S, a 500-question benchmark built to test exactly this, my recall system scores 56.2%. Not perfect, not vague either - a real, measured number instead of "it remembers everything."

Then the failures, the part that actually earned this section its heading. My own instrumentation, not a user complaint, caught at least 8 subsystems silently doing nothing while every dashboard said they were healthy. One change, the one I now call the Four-Second Merge, landed on the trunk four seconds after its checks started running, sat red for about a week, and nobody, including me, noticed until self-healing surfaced it.

Worst of all: the memory relevance score, the number the whole recall system leans on to rank what matters, was silently hardcoded to a perfect 1.0 for months. Every node looked maximally relevant to every query. I only found it by working backward from a benchmark that refused to move.

The Best Feature Is Catching Itself Failing

None of those three failures are flattering. I am including them anyway, because they are the actual argument for building this way. A system that never admits a subsystem went quiet, or that a score got hardcoded, is not more reliable than mine. It is just less instrumented. The mind, the reflexes, the memory, the wiring, the self-healing layer - none of them matter on their own. What matters is that together they produced the evidence that caught their own failures, instead of me finding out from a user, or worse, never finding out at all.

That is the actual definition I would give for a self-improving Claude Code system now, months after I first tried to write one down: not a system that gets everything right, but one that cannot quietly stay wrong. The companion post on how the feedback loop itself closes goes deeper into the scoring mechanics behind that claim, if you want the mechanism instead of the anatomy.

Go Deeper: The Full Anatomy

Everything above is the altitude view. The actual field guide, The Anatomy of a Thinking System, runs 48 pages and walks all 600-plus parts organ by organ, including the ones I did not have room for here: the steward, the verifier spine, the synthesis loop that turns raw findings into rules.

Free reference PDF

The Anatomy of a Thinking System

The complete field guide behind this post: all five organs walked one at a time, every one of the 600-plus parts, and the failures the system caught itself making.

Download the PDF

48-page PDF · the full field guide · no signup

If you just want the fastest way into the three patterns most of this is built on, the free 3-pattern guide still covers delegation, memory, and the knowledge graph in a fraction of the length. Either way, every organ above links straight to its own deep dive, so start wherever your own system is thinnest.