Agent = Model + Harness
The introduction. This book engineers the two layers around the model — the environment an agent acts in and the context it reasons over — and this chapter grounds that thesis in the frame the book stands on — an agent is a model plus the deterministic harness that wraps it. The three layers, the components, the nested loop, the book's map, and what it leaves to companion volumes.
On this page
What turns a model into an agent is not the model — it is the engineering of the two layers around it: the environment it acts in, and the context it reasons over. That is the subject of this book. This opening chapter states the thesis and grounds it in the frame the book stands on — Agent = Model + Harness — then maps the chapters and marks the scope. It defines vocabulary and direction; the next chapter argues the case, and the rest build it.
The frame: an agent is a model plus a harness
Start with the distinction that organizes everything else. An agent, in Anthropic’s framing, is a system where models “dynamically direct their own processes and tool usage.” [Official] Building effective agents · Erik Schluntz and Barry Zhang (2024)T1-official original The working shorthand is tighter still: agents are “LLMs autonomously using tools in a loop.” Effective context engineering for AI agents · Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield (2025)T1-official original That is the model side — the source of the agent’s autonomy.
The harness is everything else: the deterministic code wrapped around the model. Claude Code, for instance, “provides the tools, context management, and execution environment that turn a language model into a capable coding agent.” [Official] How Claude Code works · AnthropicT1-official original A general-purpose harness such as the Claude Agent SDK is one concrete instance of that wrapper. Effective harnesses for long-running agents · Justin Young (2025)T1-official original
The boundary that makes the frame sharp is the contrast with a workflow, where models and tools are instead “orchestrated through predefined code paths.” Building effective agents · Erik Schluntz and Barry Zhang (2024)T1-official original A workflow’s control flow is fixed in code; an agent’s control flow is driven by the model. So the same three ingredients — a model, some tools, some glue — give you a workflow or an agent depending on who decides what happens next.
This is why this book is scoped the way it is: the model is a given (you choose a capable one and prompt it well — prompting is its own discipline, out of scope here), and of the harness around it, this book develops the two layers where most of the leverage lives — the environment and the context.
The harness owns three layers
A harness decomposes into three layers, and its defining job is owning the boundary between them.
- Context — the assembled window the model reasons over. It is “a critical but finite resource for AI agents” [Official] Effective context engineering for AI agents · Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield (2025)T1-official original — a budget, not free memory.
- Environment — the substrate the agent acts in: the repository, the filesystem, scripts, a running process. A long-running harness “asks the model to set up the initial environment” before work begins. Effective harnesses for long-running agents · Justin Young (2025)T1-official original
- Context-assembly — the boundary between them. Rather than dumping the environment into the window, agents keep lightweight references and “use these references to dynamically load data into context at runtime using tools.” Effective context engineering for AI agents · Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield (2025)T1-official original
Owning that boundary is what makes a harness a harness. The mechanics of assembly — caching, compaction, just-in-time loading — are deep enough to be their own chapter (the context-assembly chapter, later in this book); here we only name the three layers and locate the boundary the harness controls.
The components a harness wires together
Zoom into the harness and it is a parts list. Shipping harnesses name the same parts. The Claude Agent SDK gives you “the same tools, agent loop, and context management that power Claude Code” [Official] Agent SDK overview · AnthropicT1-official original ; tools are “the primary building blocks of execution for your agent” Building agents with the Claude Agent SDK · Thariq Shihipar et al. (2025)T1-official original ; and the harness can “spawn specialized agents to handle focused subtasks” Agent SDK overview · AnthropicT1-official original that “use their own isolated context windows.” Building agents with the Claude Agent SDK · Thariq Shihipar et al. (2025)T1-official original
That this is a real taxonomy, and not one vendor’s idiosyncrasy, shows up cross-vendor:
So a harness wires together, at least: a tool interface, context/memory management, a control loop with stop conditions, and sub-agent orchestration — and, by extension, guardrails/permissions and observability. Each part is deep-diveable on its own; this chapter is the parts diagram, not the parts.
The nested loop: an inner cycle inside an outer one
The harness runs a nested loop, and knowing which loop you are designing is half of harness engineering.
The inner loop is the model’s own cycle. Claude Code’s “agentic loop is powered by two components” How Claude Code works · AnthropicT1-official original — the model reasoning and the tools acting — repeating until the task is done. The internals of that cycle (how a turn is structured, how tool results return) are a companion-volume concern; here it is enough that an inner loop exists and the model drives it.
The outer loop is the harness wrapping that cycle. A long-running harness exists to “bridge the gap between coding sessions” Effective harnesses for long-running agents · Justin Young (2025)T1-official original so the model can make incremental progress across many context windows.
How the vocabulary settled
The frame above is recent. The words arrived on a short, dated arc, and it is worth seeing the shape because the vocabulary is still moving.
- 2025-06-17 — Andrej Karpathy popularizes the “agents” framing in a widely-cited keynote: “This is the Decade of Agents.” [Practitioner] Andrej Karpathy: Software in the Age of AI · Andrej Karpathy (Latent Space transcript-mirror) (2025)T3-practitioner original
- 2025-11-26 — Anthropic adopts “harness” in an official engineering venue, describing a “long-running agent harness” working “across many context windows.” Effective harnesses for long-running agents · Justin Young (2025)T1-official original
- 2026-02-05 — Mitchell Hashimoto names the discipline: “I’ve grown to calling this ‘harness engineering.’” [Practitioner] My AI Adoption Journey · Mitchell Hashimoto (2026)T3-practitioner original
- 2026-03-10 — LangChain gives the formula its cleanest published form: “Agent = Model + Harness.” The Anatomy of an Agent Harness · Vivek Trivedy (2026)T2-release-notes original
The shape is the story: the concept (autonomous agents) predates a word for its wrapper (harness) by months, and the compact formula arrives last, once the wrapper has a name.
The shape of this book
This book takes two of the harness’s layers — the environment and the context — and develops them as one discipline. The chapters move from the substrate outward to the window, and inside the window from the problem to the response:
Environment — the substrate the agent acts in.
- Repo & doc design — making the repository high-signal to read and self-correcting to act in.
- The instruction layer — the always-loaded config file as a context budget, not documentation.
- Skills & progressive disclosure — procedural knowledge that loads only when relevant.
- Guardrails, permissions & reversibility — expressing intent in policy and containing failure in mechanism.
- Environments at scale — bounding what the agent must load when the repo is too big to hold.
Context — the window the model reasons over.
- Context rot — the evidence that long windows degrade, and why that is the problem the rest answers.
- Context assembly — the engineering response: caching, compaction, just-in-time loading, budgeting the window.
- Memory — persisting context across sessions, and the anti-patterns that reintroduce the rot.
A closing chapter composes all of it into one design workflow.
What this book leaves to companion volumes
The frame names more of the harness than one book should carry. The rest is deliberately out of scope here — each is planned as a companion volume in the series, and this book points outward to it rather than pretending to deliver it:
- The inner loop’s internals — how a turn and its tool results are structured.
- The Agent SDK’s surface — the concrete harness instance whose API we cited above.
- Sub-agent orchestration — the isolation primitive, orchestrator–worker topologies, and when not to use them.
- Tools & MCP — designing the tool interface and the protocol that serves it.
- Build vs. buy — whether to configure an existing harness or build your own.
- Evaluation & operations — measuring and running agents in production.
These are companion concerns, not missing chapters: this book stands on its own for the environment and the context.
What is still settling
This chapter captures a frame mid-crystallization, so a few honest limits travel with it.
- The vocabulary is young. “Harness” entered Anthropic’s official vocabulary only in late 2025; “harness engineering” and “Agent = Model + Harness” are 2026 coinages. Expect the terms to keep shifting, and re-check the landscape rather than treating today’s words as settled.
- The definitional spine is single-vendor-dense. The definitions of “agent” and “harness” rest largely on Anthropic’s framing. The one independent corroboration here (LangGraph) agrees on the components list, not on the definitions — so do not over-claim convergence beyond the parts list.
- One provenance anchor is a transcript, not a primary. Karpathy’s line is quoted from a published transcript of a spoken keynote, faithful to that mirror and the talk date, but it is “Karpathy said X in a talk,” not “Karpathy wrote X.”
Quick reference
- Agent = Model + Harness. The model supplies autonomy; the harness supplies everything around it.
- Agent vs. workflow: an agent’s control flow is model-driven; a workflow’s is fixed in code.
- Three layers: environment (substrate) → context-assembly (the boundary) → context (the finite window). The harness owns the boundary.
- Components: tool interface, context/memory, control loop, sub-agent orchestration (+ guardrails, observability).
- Nested loop: the model’s inner reason→act→observe sits inside the harness’s outer cross-session orchestration, where control lives.
- This book’s scope: the environment and the context — the two highest-leverage layers; the rest is named here and left to companion volumes.
Practice
Exercise solutions
For most coding agents the control loop is the richest component (stop conditions, retries, compaction, dispatch) and the sub-agent orchestration is often the most primitive — frequently absent entirely (a single-threaded agent). An agent with no orchestration and a thin, fixed control loop is sliding toward the workflow end of the spectrum; the more the model (not predefined code) decides what happens next across a rich outer loop, the more it is an agent in the sense this chapter defines.