Agent = Model + Harness: A Framework That Changed How I See My Role

I recently read an article from the LangChain team titled “The Anatomy of an Agent Harness.” It had 550,000 views and more than 1,500 likes. My strongest reaction was not that I had learned one new technique. It was that ideas I had picked up separately over the previous few months were suddenly connected by a single thread.

This post records my reading process and the thoughts it prompted.

The Definition That Immediately Resonated

Agent = Model + Harness. If you’re not the model, you’re the harness.

The harness is everything outside the model: code, configuration, and execution logic. A bare model is not an agent. It only accepts text and produces text. It becomes an agent when a harness adds state, tool execution, feedback loops, and enforceable constraints.

AI application engineering can also be called harness engineering. The job is not to train models or conduct algorithm research. It is to build systems around a model’s intelligence so that the intelligence becomes useful, reliable, and controllable.

The Most Elegant Idea: Derive the Design from Desired Behavior

The article does not begin with a checklist of features that a harness ought to contain. Its method runs in the opposite direction:

What behavior do we want from the agent → What must the harness provide to make that behavior possible?

The reasoning looks like this:

• To let an agent operate on real data and persist changes → provide a filesystem and Git
• To let an agent solve problems without every tool being predefined → provide Bash and code execution
• To let an agent act safely and verify itself → provide a sandbox and verification tools
• To let an agent remember experience and access new knowledge → provide memory files, web search, and MCP
• To preserve quality across long conversations → provide compaction, tool offloading, and skills
• To complete work spanning multiple context windows → provide a Ralph Loop, planning, and self-verification

Each component exists not because other products have it, but because the model cannot natively perform the corresponding behavior. This method of derivation is worth learning in its own right. It is a way of thinking about system design.

Harness Engineering Connects Existing Agent Technologies

Context Engineering — The article contains a particularly precise sentence: “Harnesses today are largely delivery mechanisms for good context engineering.” I had spent a great deal of time learning Anthropic’s Contextual Retrieval work, compaction strategies, and structured note-taking. I now see all of them as part of the harness’s context-management layer. Compaction addresses context rot, tool-call offloading prevents large outputs from consuming the context window, and progressive disclosure in skills controls how much is loaded initially. Every one of these techniques protects context as a scarce resource.

ReAct and the Agent Loop — The article describes the ReAct loop as the mainstream execution model for agents, then points out its limitation: a harness can execute only predefined tools. Bash and code execution therefore serve as general-purpose tools that let the model create tools for itself. This maps directly to the ReAct and Mem0 design I explored while studying the architecture of hey!stalker.

AGENTS.md and Memory — A global AGENTS.md file guiding Codex behavior is one example. The article explicitly names AGENTS.md as a memory-file standard: the harness injects it when the agent starts, and the agent can write discoveries back to it for continuous learning across sessions. Context Hub’s annotation mechanism follows the same idea. When an agent finds a problem in documentation, it records the lesson and receives it automatically the next time.

MCP Server Development — The article lists tools, skills, and MCPs as core parts of a harness. MCP is essentially a standardized interface through which the harness extends its capabilities beyond its own boundary.

The Most Thought-Provoking Part: Model-Harness Coevolution

The final section describes something I had not considered before: products such as Claude Code and Codex now post-train their models together with the harness.

That creates a loop: discover a useful harness primitive → standardize it in the product → train the next model with the new harness → make the model stronger inside that harness.

The side effect is that a model may overfit to a particular harness. The article cites Terminal Bench 2.0: the same Opus 4.6 scores much lower inside the Claude Code harness than it does in some other harnesses.

That led me to a question I kept returning to: as models become stronger, will harness engineering become unnecessary?

My conclusion is no. It will not disappear, but its center of gravity will keep moving upward.

Consider the last two years. At the beginning of 2024, wrapping a model in a while loop that preserved chat history was valuable harness engineering. Today every product includes that behavior. Harness engineering did not shrink; it moved to a higher layer. The current frontier includes compaction, multi-agent orchestration, and the Ralph Loop. Later it may involve coordinating hundreds of agents, having agents analyze their own traces to repair harness-level failures, and assembling tools and context dynamically for each task.

The evolution resembles Java web development. Fifteen years ago, developers wrote servlets and configured thread pools by hand; Spring absorbed those concerns. Then developers configured Spring XML and managed deployments manually; Spring Boot absorbed those concerns. Later, container orchestration became manual work; Kubernetes absorbed it. Infrastructure engineering did not disappear. Today’s infrastructure engineers work on service meshes, GitOps, and platform engineering. The abstraction level rose, but the need to build systems around a core capability remained.

There is another counterintuitive point: the stronger the model, the greater the marginal benefit of harness optimization. No harness can make a weak model complete a sufficiently complex task. With a strong model, however, the gap between a good harness and a poor one can be enormous. It is like giving the same development environment to a junior and a senior programmer: the senior programmer gains a much larger productivity multiplier from the better environment. Moving the same model from the top 30 to the top 5 by changing only the harness says everything.

Takeaways

Designing system prompts, learning context engineering, developing MCP servers, building AGENTS.md files, and studying RAG pipelines all fit inside the harness-engineering framework.

The important thing to master is the way of thinking behind harness engineering: derive system design from desired behavior instead of memorizing today’s implementations. A particular compaction algorithm may change, but the recognition that context is scarce and must be managed will not. A specific Ralph Loop implementation may eventually be absorbed into the model, but long-running work will still need a way to continue across context windows for a long time to come.

If someone asks, “How do you understand AI agent architecture?” the clearest answer I can give is the formula Agent = Model + Harness, together with the behavior-first reasoning behind its six major components.

Original article: The Anatomy of an Agent Harness, from the LangChain team.