Claude Code 2026 — What a mature setup actually looks like
Most Claude Code setups I see are running month-one. Huge CLAUDE.md, a pile of half-used slash commands, no memory, no routing, one assistant pretending to be a team. It works for a week and then quietly stops scaling.
Here's what year-twelve looks like. Nine layers and four organizing principles. This is the skeleton — not the only way to do it, but the one I've landed on after running 17 named agents, ~136 active skills, and six memory backends in production against real agency work.
No fake stats. No fabricated case studies. Just the shape of the thing.
L1 — CLAUDE.md files
Static context, layered. Global CLAUDE.md holds identity — who the assistant is, how it talks, the rules it never breaks. Project CLAUDE.md holds project state — what this repo is, what the stack looks like, where the important files live. Scope-level CLAUDE.md (inside subfolders) handles local context.
The rule: nothing gets duplicated. If you're pasting the same paragraph in two places, pick one and delete the other. CLAUDE.md is not documentation. It's context injection. Treat every line like you're paying for it — because you are, in tokens and attention.
Most people get this wrong by turning CLAUDE.md into a wiki. Wikis go in skills or reference files that load on demand.
L2 — Skills
Skills are routed behavioral patterns. They're the thing that turns "I know how to do SEO audits" into "when Mike says 'audit this,' load the audit SOP, follow these steps, return this format."
The key insight most people miss: the description field IS the wiring. That's how the skill router decides whether to load the skill. A skill with a vague description is an untriggered skill. A skill with a precise description gets pulled into the exact context it was built for.
Body of the skill is behavioral rules only. No lore, no backstory, no preamble. Steps, constraints, output format. Done.
Audit the skill pool regularly. Skills that nothing routes to are worse than useless — they bloat the index and confuse the router. Kill them. I ran 947 skills down to 526, then down to ~136 active, and everything got sharper.
L3 — Hooks
Hooks are the nervous system of the whole setup. Most people discover hooks when they want to block a dangerous command — that's the small use case. The big use case is plumbing.
Session-start hooks inject recent context and expertise files. Subagent-start hooks load the agent's soul and identity before the first token fires. Tool-event hooks log every read, write, and edit to a provenance trail. Post-task hooks push state to a dashboard or bridge it into another system.
Build the hook layer before you build the agents. When the plumbing works, the agents get smarter automatically — every new agent inherits the memory wiring, the provenance logging, the dashboard push, without you writing a line of per-agent code.
Hooks are not a safety net. They're a signal path.
L4 — Subagents
Subagents are single-task workers spawned via the Agent tool. One-way — they run the task, report back to the caller, and die. No persistent memory unless you explicitly wire it with memory: user in the frontmatter.
The right mental model: subagents are disposable. Give one a tight task, a clear output format, and a narrow skill set, and let it burn. Don't try to have a conversation with a subagent. Don't try to make it remember. That's not what it's for.
Named agents with continuity are a different pattern — those get workspaces and memory wiring. Workers are just workers.
L5 — Agent teams
This is the experimental layer most people confuse with subagents. Teammates are peer Claude sessions that can talk to each other two-way. Gated behind an experimental flag. Fundamentally different from subagents — a teammate is a full session, not a one-shot worker.
Important distinction: teammates can't spawn their own workers the same way a primary session can. The Carlos pattern (one conductor dispatching to subagent specialists) and the Teams pattern (peer sessions messaging each other) solve different problems. Don't mix them up.
Most setups don't need teams yet. Most setups need better subagent hygiene first.
L6 — Per-agent workspaces
When you want an agent to be the same agent across sessions — to remember last week's work, to know its own voice, to wake up as itself — you give it a workspace. The OpenClaw pattern is nine files: AGENTS.md (operating instructions), SOUL.md (persona), IDENTITY.md (name, role), USER.md (who it's working for), TOOLS.md (tool notes), MEMORY.md (curated long-term memory), HEARTBEAT.md (scheduled wake checklist), BOOT.md (session restart checklist), BOOTSTRAP.md (first-run ritual).
SOUL holds who the agent is. MEMORY holds what it knows. Never mix them. Identity is stable; memory is mutable. If an agent's soul changes every time it remembers something new, it's not an agent — it's a journal.
Memory as index, not encyclopedia. Depth lives in the vector stores. MEMORY.md holds pointers: → vector: "client brand voice", → /skill-name, → file: "path". Stays lean. Stays useful.
L7 — Memory backends
Multiple stores, each doing a specific job:
- Working memory — fast, session-scoped, the thing that catches recent context
- Source of truth — durable vector store with dense embeddings, the canonical record
- Graph store — relationships between entities, the connective tissue
- Doc store — full text, keyword search, the grep layer
- Cache/backup — local copies for resilience
The thing most people get wrong: running two memory systems that inject into the same recall path at the same time. That's how you get contradictory context and confused agents. Pick one source of truth. Everything else is a specialized index or a cache.
Six backends is not overkill if each one has a defined role. Six backends fighting over the same recall slot is chaos.
L8 — MCC / dashboards
Mission control. A dashboard that shows every agent, every active session, every recent memory write, every queued task. If you can't see what your agents are doing, you don't have a team — you have hope.
The dashboard doesn't have to be fancy. It has to exist. Kanban, activity feed, memory viewer, agent grid. Cross-system visibility is what turns "I have agents" into "I run agents."
I run mine on Convex + Vercel. Could be anything. The point is: there is one.
L9 — Provenance / audit
Every tool call, every memory write, every agent spawn — logged. Timestamped. Traceable back to the prompt that caused it.
You will need this. The first time an agent does something weird, you will want to know exactly which hook fired, which skill loaded, which memory got injected, and in what order. If you didn't log it, you're guessing. If you logged it, you're debugging.
Provenance is boring until it's the only thing that saves you.
The 4 Organizing Principles
1. CLAUDE.md is a lean index, never an encyclopedia
Global holds identity. Project holds project state. Nothing duplicates. The moment you're tempted to paste a how-to into CLAUDE.md, stop and put it in a skill or a reference file that loads on demand. Every line in CLAUDE.md is always in context — budget it like the expensive thing it is.
2. Skills are classified, audited, and trigger-word disciplined
Frontmatter is the wiring. The description field is how the router finds the skill — write it like a search query, because that's what it is. Body is behavioral rules only. Audit the pool on a schedule. A skill nothing triggers is worse than a skill that doesn't exist — it costs index space and confuses the router. Delete freely.
3. Hooks are the nervous system, not a safety net
Blocking commands is the small use case. The real job of hooks is plumbing — session lifecycle, memory injection, provenance logging, cross-system bridges. Build the hook layer first. Every agent you build after that inherits the nervous system for free.
4. Memory uses multiple backends — exactly one is source of truth
Multiple stores is fine. Each doing a defined job is good. Two stores injecting into the same recall path at the same time is how you get an agent that contradicts itself mid-sentence. Pick one source of truth. The rest are caches, backups, or specialized indexes. Never let two memory systems argue in front of the model.
What this isn't
This isn't a framework. I'm not selling a course. I'm not going to tell you which vector store is best or which model to route to. This is the shape of the thing — the layers you'll end up building whether you mean to or not, once you push past the "one big assistant" phase.
If your setup looks like this already, you're not month-one anymore. If it doesn't, now you know what you're building toward.
Follow along on X. More of this is coming.