Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders.
In Part 9, I promised the last article would be where the whole series pays off. Nine articles laying out a taxonomy — six components, three verbs, one architectural picture. This article points all of that at a real, working, publicly-known agent: Claude Code.
We're not going to speculate about how Claude Code works. We're going to walk through it the way you'll walk through any agent from here forward — component by component, asking six specific questions, and putting the answers in the six boxes we've been carrying around this whole series.
What's ahead:
- Part 1: The Raw Model Problem
- Part 2: Defining the Harness — The Six Components
- Part 3: The Control Loop
- Part 4: The Tool Layer
- Part 5: Context Engineering
- Part 6: The Filesystem & Environment
- Part 7: The Memory Layer
- Part 8: Observability
- Part 9: The Harness Architecture
- Decomposing Claude Code ← You are here
By the end of this article, you'll have seen the six-component framework applied to a real agent from start to finish — and you'll have a repeatable method you can use on any agent you encounter from now on.
Let's get started.
📚 Want to go deeper than the articles?
While you follow along with this series, I've put together two hands-on resources that go further than any single article can:
- Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code.
- Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers.
Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives.
The Setup
We've spent nine articles laying out a shared vocabulary and framework. Now we point that framework at something concrete.
The picture below is what a full decomposition looks like when you draw it out on a whiteboard.
Every component we've named has a box. Every arrow between them is a coupling we've discussed. And in the middle sits Claude Code — the agent we're pulling apart to see what fills each of those boxes when the theory meets a real, shipping product.
This is the exercise you can now do with any agent. What you're about to read is one worked example.
The Six-Component Decomposition
Here's Claude Code, broken down component by component using the framework from the rest of this series.
1. The Loop
Claude Code's Loop is a classic ReAct loop — the shape we identified in Part 3 as the default for most modern agents. It cycles through call the model → decide an action → execute the tool → inspect the result → back to the model, and it keeps going until either:
- The model indicates the task is done
- A step budget is hit
Two clear termination conditions, both explicit, both mechanical. Exactly the pattern Part 3 argued for.
2. The Tools
Claude Code has the small, sharp tool surface we made a big deal of in Part 4: read, edit, bash, glob, grep, plus a task-management tool and an MCP connector for extending the tool set.
That's it. No refactor_python_function. No run_pytest_and_summarize. No open_pr_with_generated_summary. Every specialized job a bloated toolset would have its own function for is composed instead from the general primitives.
This is the "compose, don't enumerate" principle from Part 4, made real. When Claude Code needs to do something novel, it doesn't need a new tool — it reaches for bash and grep and read and figures it out.
3. The Context
On every turn, Claude Code assembles the Context from four ingredients:
- The system prompt (built into the agent)
- CLAUDE.md files and other repo-level context
- The conversation history so far
- All prior tool results
And on top of those, any files the user explicitly references with @ get pulled in for that turn.
Notice how this maps directly to Part 5. The system prompt is the built-in control plane. CLAUDE.md is the user-layered instruction file we called out by name. Conversation history is the short-term memory feeding forward. Tool results are outputs of previous turns being made available to the next. And @ references are an explicit-attachment mechanism the user drives.
Different names on the whiteboard, but every ingredient came from the vocabulary in Part 5.
4. The Environment
Claude Code's Environment is your local machine — the actual thing sitting on your desk.
The read and edit tools touch your real filesystem. bash runs commands in your real shell. Network calls hit the real network. This is a bounded but not sandboxed environment: bounded because Claude Code doesn't reach outside the working directory casually, and gated by a permissioning system that prompts you before destructive operations — deleting files, running risky commands, and so on.
Compare that to Codex from Part 6, which runs in a fully sandboxed disposable container. Claude Code makes a different trade: less isolation, more directness, safety enforced through permissioning rather than through walls. Same component, different design choice. Both defensible for their respective use cases.
5. The Memory Layer
Claude Code has the exact two-flavor design from Part 7:
- Short-term memory is the running conversation — the messages exchanged so far, replayed on every turn.
-
Long-term memory lives in
CLAUDE.mdfiles at the repo and user level, plus the user's~/.claudedirectory.
Short-term is full-fidelity. Long-term is compressed and structured — files, not raw history. And critically, the long-term memory is user-managed: the user writes into CLAUDE.md; Claude Code reads from it. That's a very deliberate design choice — the write triggers for long-term memory are essentially "the user decided to write something down." No auto-summarization guessing what to remember. An explicit gate, controlled by a human.
6. Observability
Claude Code's Observability shows up as a visible tool-call log in the UI. Every read, every edit, every bash invocation is shown to the user as it happens, in real time.
That's not just a UI feature. That's the exact observability principle from Part 8 made visible: the user (and, by extension, an engineer debugging the agent) can see what the agent is doing as a stream of concrete events. Nothing important happens in the dark.
The user-visible tool log is essentially a real-time trace, presented as UX rather than as a debugging tool. That's a signal about how much Claude Code's designers trust the value of observability — enough to put it on the surface of the product, not hide it behind a --verbose flag.
What This Decomposition Shows Us
Three things stand out once the whole picture is on the wall.
First, every box has something in it. No component is missing. Every one of the six we've talked about has a concrete implementation in Claude Code. This is what a complete harness looks like — a real product where all six concerns have been thought through, not left to chance.
Second, the design choices are internally consistent. The small-sharp tool surface fits the general-purpose model bet. The direct-not-sandboxed environment fits the coding-in-your-real-repo use case. The user-managed long-term memory fits a product where the user is a technical operator, not a passive consumer. Nothing feels bolted on.
Third, none of this required insider knowledge to see. Every observation we just made is available to anyone who uses Claude Code and knows what to look for. That's the whole point of a taxonomy — it turns opaque products into readable systems.
Every real agent decomposes into these six components. That's the claim this series has been driving toward. Claude Code is one worked example of what it looks like when you actually do the decomposition.
Do This to Any Agent
The exercise we just did with Claude Code — six questions, six answers, one honest whiteboard — is now a tool you own. You can point it at anything.
Try it on Cursor. What's Cursor's Loop like when a completion fires? What's on its tool surface? What does it assemble into context on every keystroke? What's its environment? Where does memory live? What's its observability story?
Try it on a framework you're evaluating. If you can't quickly answer all six questions about it, that's a signal — either the framework is genuinely lightweight (and expects you to fill in the missing components), or its design isn't as thought-through as its marketing suggests.
Try it on your own work. If you're prototyping an agent, sketch out the six-component picture before you write any code. Which pieces are you designing deliberately? Which are you leaving to chance? Which ones already exist in libraries you're using, and which ones will you have to write yourself?
That kind of thinking — the ability to look at any agent, sketch its six components, and reason about the tradeoffs at each — is what a good taxonomy buys you.
That's a Wrap
And that brings us to the end.
Ten articles. Six components. Three verbs. One raw model problem, and the entire discipline of engineering that sits around it to make agentic systems actually work.
Thank you for reading through the whole series. If it made the fog around AI agents feel more like structure, then it did what it was meant to do. Whether you go on to build your own harness, evaluate someone else's, or just have sharper conversations about agents from here on out — the vocabulary you've picked up is yours to keep.
If you want to go deeper — actually build a harness end-to-end, or work through the material with peers and direct feedback — the course and the workshop linked at the top of every article in this series are where that happens.
Until then: use what you've learned. Point it at real systems. Notice what fits the framework and what doesn't. That's the whole game.
This was the final article in a 10-part series that walked through every component of an agentic harness.
Here's the full roadmap you just completed:
- Part 1: The Raw Model Problem
- Part 2: Defining the Harness — The Six Components
- Part 3: The Control Loop
- Part 4: The Tool Layer
- Part 5: Context Engineering
- Part 6: The Filesystem & Environment
- Part 7: The Memory Layer
- Part 8: Observability
- Part 9: The Harness Architecture
- Decomposing Claude Code ← You just finished this one — and the series.
That's the series. Thanks for coming along.
Happy coding :)
Top comments (0)