GREG · The Operator

Claude Code Has 5 Layers. I Learned Each One by Breaking Something.

· 6 min

"Build an AI agent" is a useless instruction. I gave it to myself for four months. Open Claude Code. Type something vague. Hope a working system shows up. Spoiler: it didn't.

Here's what I eventually figured out — Claude Code isn't one tool. It's a stack of five layers. Each one solves what the layer above it leaves open.

That's the whole post. The rest is me showing you how I learned it the hard way.

1. CLAUDE.md — the memory layer

Always loaded. The agent's constitution.

Architecture rules. Naming conventions. Test expectations. Repo map. The "never touch this" lines.

Two locations matter:

  • ~/.claude/CLAUDE.md — global. Every project inherits it.
  • .claude/CLAUDE.md — project-local. Lives in the repo. Your team inherits it.

Subfolder CLAUDE.md loads when the agent enters that folder. Files are additive, not overrides. You can @import other files inline. That's the part everyone misses on day one.

What I broke first:

Claude Code rewriting the same boilerplate every session. Same imports. Same error handling. Same test patterns. Different file. Every time.

Then I read the docs properly. Encoded the conventions in CLAUDE.md once. Let the agent inherit them.

That first hour saved me forty hours of repetitive correction.

That's the unlock.

2. Skills — the knowledge layer

On-demand expertise. Not always-on.

Each skill ships with a frontmatter description. That description is the trigger. User request matches it semantically? The body loads. Reference docs, scripts, templates — none of it touches your context until something actually needs it.

Here's where it gets interesting.

You're not stuffing everything into context anymore. You're writing descriptions that tell the model when a piece of expertise is relevant. The model decides.

What I broke first:

12,000-token system prompt. Everything I knew about a domain crammed into it. Most queries didn't need any of it. I was paying for context that mattered maybe one in eight requests.

Pulled it into a skill. Trusted the description-matching to do its job.

Agent got faster. Cheaper. And weirdly better — because the noise was gone.

3. Hooks — the guardrail layer

Deterministic scripts. Not AI. They run regardless of what the model decided.

25 lifecycle events — PreToolUse, PostToolUse, SessionStart, Stop, SubagentStop, UserPromptSubmit, more. PreToolUse can reject a tool call before it runs. PostToolUse reacts after.

Git hooks for your agent. That's the mental model.

What I broke first:

Watched Claude Code, in pursuit of "cleaning up," delete a directory I'd been working on for two weeks.

Recoverable. Bad afternoon.

Next morning I wrote a PreToolUse hook. Block any rm -rf. Require explicit confirmation for destructive commands.

That hook has fired probably fifteen times since.

Here's the truth — the model is usually careful. Hooks make "usually" irrelevant. And that changes everything.

4. Subagents — the delegation layer

Defined in .claude/agents/ as markdown files. Each one gets its own system prompt, context window, model, tool list, permissions.

Code-reviewer. Test-runner. Explorer. Debugger. Purpose-built specialists.

Main agent delegates. Subagent works in isolation. Only the result comes back.

Subagents can't spawn subagents. No infinite recursion. No runaway costs.

What I broke first:

Main context filling up with file-exploration noise. 40k tokens of grep output and directory listings that mattered for two minutes and never again. Hitting context limits halfway through real work.

Not gonna lie — it killed momentum every time.

Pushed exploration to a subagent. Subagent burned through 50k tokens of searching and handed back a two-line answer. My main context stayed clean.

This is context engineering as architecture. It's the layer that made long sessions feel sustainable.

5. Plugins — the distribution layer

Honest framing first.

Plugins aren't really a fifth layer. They're a packaging format that wraps the other four. Skills, subagents, hooks, commands, MCP servers — bundle them into one installable unit. Plugin skills are namespaced, so install five plugins with overlapping names and nothing collides.

Install once. Reuse across every project and every teammate.

What I broke first:

Built something my team couldn't use. Skills, subagents, hooks I'd tuned for weeks. All of it living in my home directory. None of it portable.

Packaged it as a plugin.

That's the day my workflow stopped being a personal hack and started being team infrastructure.

The mental model

Here's where most people stop and where the compounding actually starts:

The drop-off is steep. Most people write a CLAUDE.md, maybe build a skill or two, and call it a day. The compounding starts at hooks. The leverage shows up at subagents. And the moment your work helps someone other than you? Ship the plugin.

> CLAUDE.md sets the rules. > Skills provide expertise. > Hooks enforce quality. > Subagents delegate work. > Plugins distribute the whole thing.

Each layer exists because the one above it leaves something open.

CLAUDE.md tells the agent what to do. Skills load how to do it. Hooks make sure it actually got done. Subagents handle the parts your main agent shouldn't be touching. Plugins ship the whole stack to anyone who clones the repo.

The tools matter less than the architecture.

This is the architecture.

Transmission timestamp: 2:34:17 PM