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 1, we landed on a definition of a harness that was true but a little too broad to work with: everything that is not the model is the harness. Fine. But if a harness is everything that isn't the model, then the word "harness" covers a lot of ground — from the loop that calls the model to the logging library that writes what happened to disk.
You can't reason about "everything." You need parts.
So here's the promise for this article: I'll give you the six parts. Six components, each with a name, each with a job, each corresponding to a specific class of agent failure when it's missing or broken. Once these six names are in your head, every conversation you have about agents — debugging, design reviews, comparing frameworks, reading papers — gets sharper.
What's ahead:
- Part 1: The Raw Model Problem
- Defining the Harness — The Six Components ← You are here
- 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
- Part 10: Decomposing Claude Code
By the end of this article, you'll have a formal definition of a harness, a three-verb specification of what it has to do, and a six-component vocabulary you can carry into every conversation about agents from here on out.
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 Harness Isn't One Thing
In Part 1, we saw that a raw language model can't act on the world — it can only produce text that describes acting. We called the wrapper that closes this gap a harness, and we defined it as everything that is not the model.
That definition is true. It's also too broad to reason about.
Because a harness isn't one thing. It's a stack of six concerns, each of which can be designed well or badly, and each of which corresponds to a specific class of agent failure when it's missing or broken. Part 1 named the gap. This article names the parts that close it.
Why bother naming them? Because once you have this vocabulary, every conversation you have about agents changes. When someone shows you a failing agent, you can point at the specific component that's broken. When a framework claims to be "an agentic runtime," you can ask which of the six? When you read a paper about a new technique, you can slot it into the layer it belongs to. Without the vocabulary, "agent stuff" is a fog. With it, you can navigate.
A Formal Definition
Let's tighten the working definition from Part 1 into something more precise.
A harness is the engineered system surrounding a language model that turns its single output channel (text) into **action, **persistence, and **measurable behavior.
Three verbs are doing the load-bearing work in that sentence. Let's unpack each one.
Action
The harness gives the model surface area beyond text — a filesystem, a code sandbox, web access, an API. It doesn't just let the model describe things happening. It executes the things the model describes.
This is the direct answer to the surface area problem from Part 1. A model that can only produce text is stuck in the pure-description layer of reality. A harness reaches into the execution layer, the data layer, and the network layer, and closes the loop between "the model said to do X" and "X actually happened."
Persistence
The harness retains state the model itself cannot. Within a single task, that means holding onto tool results, intermediate reasoning, and running notes. Across sessions, it means remembering who you are, what you've been working on, and what worked before.
Persistence is a harness feature, not a model feature. Every "memory" you've ever experienced from an LLM was built by something outside the model — quietly holding state and replaying it back into the prompt when the model needs to "recall" something.
Measurable Behavior
The harness exposes what the agent is doing so engineers can debug it, evaluate it, and improve it. This is easy to skip when you're prototyping and painful to add later when you're not. And without it, you can't tell a working agent from a lucky one.
The Six Components
Every component in the taxonomy below serves at least one of the three verbs above. Most serve more than one.
| # | Component | One-line definition |
|---|---|---|
| 1 | The Loop | The control structure that calls the model, dispatches tool calls, and decides when to stop |
| 2 | The Tools | The functions the model can invoke to have side effects in the world |
| 3 | The Context | Everything fed into the model on a given call — system prompt, history, retrieved knowledge, tool results |
| 4 | The Environment | The runtime the tools operate inside — filesystem, shell, network, sandbox boundaries |
| 5 | The Memory | State that persists across loop iterations and across sessions — short-term and long-term |
| 6 | The Observability | How the harness exposes what it's doing — logs, traces, evals, debuggability |
Each of these six components gets its own dedicated article in the rest of this series — the Loop in Part 3, the Tools in Part 4, the Context in Part 5, the Environment in Part 6, the Memory in Part 7, and Observability in Part 8.
Where This Leaves Us
Six components. Three verbs. One insight worth carrying forward: the harness is not a thing — it's a stack of concerns, and getting each one right is its own discipline.
From Part 3 onward, we take each of these six components in turn and ask the same set of questions of it: What is it? What does it do? What does it look like when it's designed well? What breaks when it's missing? Different articles, same underlying method — because the harness itself has that shape.
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
- Defining the Harness — The Six Components ← You just finished this one.
- Part 3: The Control Loop ← Move to this one.
- 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
- Part 10: Decomposing Claude Code
See you in the next one.
Happy coding :)
Top comments (0)