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 Parts 3 through 8, I walked through the six components of an agentic harness one at a time — the Loop, the Tools, the Context, the Environment, the Memory Layer, and Observability. But naming the parts isn't the same as understanding how they fit together.
In this article, we zoom out. We look at the whole architecture at once, trace the flow of a single agent turn through it, and see what shape a real harness has when you draw it as a system.
This shape isn't unique to any one framework. It's the canonical shape — the picture every real agent, from Claude Code to Cursor to whatever custom harness a company is building for its own internal use — is some variation of. Once you can see it clearly, you can look at any agent and spot which pieces are present, which are missing, and where the interesting design decisions were made.
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
- The Harness Architecture ← You are here
- Part 10: Decomposing Claude Code
By the end of this article, you'll have a mental picture of the whole harness as a system — how the six components connect, why the shape looks the way it does, and where the tightest coupling and cleanest seams are. That picture is the tool you'll use to look at any real-world agent and see through it.
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 Architecture at a Glance
Before we go further, take a moment to look at the diagram below.
That's the whole picture. Six components, arranged as a system: Observability wraps the outside; the Loop drives everything inside it; Context sits at the assembly point between memory and the model; the Model emits either an answer or a tool call; Tools dispatch through the loop into the Environment; and results flow back into Memory, which feeds the next Context.
The rest of this article walks through what that picture is telling us.
How a Single Turn Flows Through It
Follow the arrows in the diagram, and here's the flow of one agent turn:
- The Loop starts a turn. It's the outermost control structure — the piece that decides "keep going" or "stop." Every step below happens inside one iteration of the Loop.
- The Loop assembles a Context. It pulls from short-term memory (the conversation so far), from long-term memory (things the agent should remember across sessions), from the environment (files being worked on, tool results from prior turns), and from anywhere else that might be relevant. That assembled payload becomes the input for this turn.
- The Context goes to the Model. The model reads it and produces a response. That response is either a final answer (in which case the Loop terminates) or a request to call a Tool.
- The Loop dispatches the Tool. Not the model — the Loop. The model emits a structured request; the Loop is the piece of code that reads that request, looks up the actual tool implementation, and runs it.
- The Tool executes in the Environment. Whatever side effect the tool has — reading a file, hitting an API, running a shell command — lands inside the harness's Environment, with its bounded filesystem, shell, and network.
- The result flows into Memory and back into Context. The tool result gets recorded in short-term memory (always) and may get promoted into long-term memory (if a write trigger fires). Then the Loop starts a new turn, which begins with assembling the next Context — now including the fresh result.
- Observability watches all of it. Every model call is logged. Every tool invocation is traced. Every state transition is recorded. Observability wraps the whole cycle without participating in it.
That's one turn. Every capable agent you've ever seen is doing some version of this, over and over, until either the task is done, the budget runs out, or an error threshold is hit.
What This Architecture Tells Us
Once you can see the shape clearly, a few structural facts about the design become obvious.
The Loop Is Outermost Because It's the Only Thing That Runs Continuously
Everything else in the diagram fires in response to a Loop step. The Model doesn't drive anything on its own. Neither do the Tools. Neither does Memory or the Environment. They all wait to be invoked. The Loop is the piece that keeps the cycle moving, and it's why it sits on the outside of everything else.
If you removed the Loop, every other component would still exist — but nothing would ever happen. There'd be a filesystem no one is touching, tool functions no one is calling, a model no one is sending payloads to. The Loop is what turns a collection of parts into a running system.
The Context Is Where Everything Converges
Look at where the arrows meet in the diagram. Memory feeds Context. Tool results feed Context. Retrieval feeds Context. Environmental state feeds Context. Then Context feeds the Model.
The Context isn't a component that does things — it's the surface where everything else's decisions get packaged and handed to the model, freshly, on every turn. That's why Part 5 argued context engineering is "the deepest engineering discipline in the whole harness." It's not that context is more important than the other components. It's that context is the point where every other component's contribution has to actually get expressed in something the model can read.
Get context assembly wrong, and even a beautifully-designed set of tools and a spotless environment don't help — the model never sees the right things at the right time.
Observability Is Intentionally Decoupled
Notice that Observability wraps the outside of the diagram, not the inside. It doesn't participate in the cycle. It doesn't decide anything. It just watches and records.
That decoupling is a design choice. An observability system that's tangled up with the components it observes ends up being unreliable when those components fail — exactly when you need it most. If Observability lives outside the cycle, it can keep working when the cycle breaks. And that's what makes it usable as the tool you reach for when something goes wrong.
The Canonical Shape
The picture in the diagram isn't a specific framework's architecture. It's not opinionated toward LangChain or LangGraph or any particular library. It's the underlying shape that any agent capable of multi-step work has to have — because each component solves a real problem, and none of them are optional in a real production system.
Different agents put their engineering effort into different parts of the same shape:
- Cursor puts most of its differentiation in Context. Its architecture has the same shape as this diagram, but Cursor's innovation lives inside the Context box — what it assembles, how it retrieves, what it prioritizes on every keystroke.
- Codex puts most of its differentiation in Environment. Same shape as everyone else, but Codex's innovation lives in that sandboxed container per task, and everything else is designed to defer to what the environment enables.
- Claude Code distributes its differentiation across Tools and Observability. A small, sharp tool surface; visible live tool logging that doubles as a real-time trace.
Once you can look at an agent and spot which box it's investing engineering effort in, you understand what makes it different. And, more importantly, you know where to look when it fails, or when you want to reason about the tradeoffs in your own design.
Where This Leaves Us
We've now named the six components, walked through each one, and seen how they fit together into a coherent architecture. That's the theoretical spine of the series done.
The last article is where it all pays off. In Part 10, we take a real, working, publicly-known agent — Claude Code — and decompose it component by component using the exact framework we've built up here. What's Claude Code's Loop shape? What's on its tool surface? How does it engineer context? What does its environment look like? How does it handle memory? Where's its observability?
By the end of that decomposition, you'll be able to look at any agent — any framework, any product, any research demo — and slice it up the same way. That's the payoff of a good taxonomy: you don't just understand the parts, you can take apart any real system into them.
Remember that this article is part of a longer 10-part series that walks you through every component of an agentic harness.
Here's the roadmap:
- 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
- The Harness Architecture ← You just finished this one.
- Part 10: Decomposing Claude Code ← Move to this one.
See you in the next one.
Happy coding :)
Top comments (0)