A 5-part series — Part 4/5 – Harness engineering

When the Claude Code source leaked in late March 2026, people could finally measure something practitioners had suspected without proof: across roughly 512,000 lines of TypeScript, the model interaction itself is a tiny fraction. Everything else, the vast majority, is the harness.

That sums up the outermost layer of our diagram. The model sits at the center, brilliant and expensive to train, and yet it’s the smallest part of the system around it. Vivek Trivedy at LangChain put it flatly: if you’re not the model, you’re the harness.

What a harness is

A harness is everything around the model that isn’t the model. Anthropic converged on a simple definition of the agent itself: an LLM that uses tools in a loop, autonomously. The harness is the infrastructure that makes that loop possible and reliable.

It breaks down into a few distinct roles.

The orchestration loop. The agent plans, acts, observes the result, decides the next step, starts again. This loop is the heart of the harness. It’s what turns a model that answers once into a system that pursues a goal over time.

Tool execution. The model does nothing itself. It asks. The harness executes: calling an API, reading a file, running a test, querying a database. The quality of this interface between the model and the world matters as much as the model. The Model Context Protocol has become a standard for connecting these tools.

Context management. On each turn, something decides what goes back into the window and what comes out. That’s the context engineering from Part 3, but handled automatically and continuously by the harness.

State persistence. An LLM has no memory. Each session starts from zero. The harness saves what’s needed so the next session picks up where the last one stopped.

Verification. A good harness doesn’t blindly trust the model’s output. It checks, it retries on failure, it sets guardrails. In software work this often takes the form of automated tests: the agent writes code, the tests run, and their result serves as ground truth for it to correct itself.

The shift in mindset

Harness engineering rests on a principle that, once adopted, permanently changes how you work. Every agent failure isn’t a prompt to retry. It’s a system problem to fix once.

Your agent lost the thread after ten steps? It’s not “let me rephrase my request.” It’s “my context management leaks information at turn eight, I’ll fix the compaction.” Your agent calls the wrong tool? That’s not bad luck, it’s an ambiguous tool description to rewrite. You don’t pray it works next time. You repair the mechanism, and the bug doesn’t come back.

The model becomes swappable

A direct and underrated consequence: because the harness is independent of the model, you can plug in a newer model without rewriting everything. The same harness takes a new model like a component you replace. That’s what lets a small team move very fast. At OpenAI, a team of three engineers produced a million-line codebase at a rate of several pull requests per person per day. It’s not the model alone that produces that throughput. It’s a good harness putting the model to work.

When you don’t need one

A warning, because the harness is seductive and it’s tempting to build one everywhere. Anthropic keeps repeating it: start with the simplest solution, add complexity only when it’s justified. For a single-turn task, one good call with a bit of retrieval is plenty. A harness earns its place once the task spreads across several steps, calls tools, runs long. Not before. Building an agent for a task a simple prompt solves means paying latency and tokens for nothing.

The real question

We now have all three layers. Prompt, context, harness. What remains is the question a team actually cares about: which one should I invest my energy in, right now, given where I am?

That’s the whole subject of Part 5, where I lay out a maturity model to place your team and decide what to strengthen first.

Practical resources

• Anthropic, Building Effective Agents: the founding text on workflows, agents, and when to use which. https://www.anthropic.com/research/building-effective-agents
• Anthropic Cookbook, agent patterns: the reference implementations, in code, of the patterns above. https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents
• Firecrawl, What is an agent harness: the best beginner-friendly introduction to the concept. https://www.firecrawl.dev/blog/what-is-an-agent-harness
• MongoDB, The Agent Harness: Why the LLM Is the Smallest Part of Your Agent System: the six components of a harness, in detail. https://www.mongodb.com/company/blog/technical/agent-harness-why-llm-is-smallest-part-of-your-agent-system
• Model Context Protocol: the open standard for connecting tools to an agent. https://modelcontextprotocol.io