Loading…
Loading…
An agent harness is everything around a language model that lets it act: the tools it can call, the format for calling them, the code that runs those calls and hands the results back, the instructions and memory it reads, and the checks that decide when it is done. On its own a model only produces text. A model plus a harness is an agent, and the same model can be unreliable in one harness and dependable in another.
Agent = model + harness
Definition
A model can only write text. To let it act, something has to turn that text into actions and bring the results back. That something is the harness, and at minimum it needs five pieces.
Five-piece breakdown after Theo Browne's What is a “harness”? Each pass through these pieces is one turn of the agentic loop.
Three layers
Most confusion about harnesses comes from products that ship two layers as one. Think of a kitchen: the model is the chef, the harness is the kitchen and its tools, and the app is the restaurant you walk into.
What a person sees and types into: a terminal app, a desktop app, a chat window, a team tool.
Examples: The Claude Code terminal and desktop app; the ChatGPT and Codex apps; T3 Code.
Runs the loop: exposes the tools, runs tool calls, manages context, memory and permissions.
Examples: The Claude Agent SDK under Claude Code; the Codex App Server under the Codex apps; Pi under OpenClaw.
Reads the context and writes the next message, including tool calls.
Examples: Claude, GPT, Gemini, open-weight models.
The same harness can sit under different apps, and one app can carry several harnesses. Different “agents” are often the same model in differently configured harnesses: other tools, other instructions, other connections. Source: Theo Browne (t3.gg) (2026) ↗
Anatomy
Every serious harness, from a coding agent to a business automation, has these parts. Each one prevents a specific failure, and each links to the guides on this site that go deeper.
Evidence
The strongest argument for harness work comes from the model makers themselves. In each case below the model stayed the same; only what surrounded it changed.
The harness run cost over 20 times more, and the difference in quality was obvious: the solo run opened but the game did not respond to input. Spending more on the harness bought a working core, not a finished product.
Early progress was slow because the environment was under-specified, not because the model was weak. The team’s job became adding what the agent was missing: docs it could read, linters with fix-it messages, logs and UI it could inspect.
Compaction alone did not keep a long job coherent. An initializer agent wrote the plan down; each later session read the log, built one feature, tested it and left notes. JSON held up better than Markdown because the model was less likely to overwrite it.
Harness engineering
Swapping to a bigger model is the most expensive fix and often the wrong one. Trace each failure to one of five layers, fix that layer, and run again. Keep a one-line log per task: done or not, and which layer broke.
The habit, as HumanLayer quotes Mitchell Hashimoto: whenever the agent makes a mistake, engineer a fix so it never makes that mistake again. Source: HumanLayer (2026) ↗
Layers from Learn Harness Engineering, lecture 1, which also ships starter templates (AGENTS.md, a feature list, a progress file).
In the wild
The parts are the same everywhere; the choices differ. These four take the clearest positions.
Layered memory, staged compaction, permissions, hooks and subagents, all built in.
A short AGENTS.md points into a docs folder; worktrees isolate each task; linters feed fixes back.
A small system prompt and programmable extensions; context is loaded on demand.
Even the agent loop is a replaceable part, independent of the model.
Summarised from WalkingLabs' frontier harness design breakdowns.
Open-source presets package a whole configuration. ECC, the best known, lists 71 agents, 311 skills and 97 command shims for Claude Code, Codex and other harnesses (MIT licence, October 2026). Switching everything on at once usually makes things worse.
Many harness decisions are yes-or-no or pick-one: is this urgent, which model should take this request, is this command risky. Small classifier models answer those with a probability instead of text, so they can run on every step.
LangChain's write-up of Jev, a classifier model from TypeSafe AI, uses one for model routing (cheap model for lookups, strong model for hard calls) and for an “auto mode” that blocks risky tool calls before they run. The speed and cost gains quoted there are the vendor's own figures.
Without code
You don't need to write code to build one. Desktop agents such as Claude Cowork read a folder of plain files, so the same parts become documents you keep up to date.
Setup after AI Edge's guide: have the agent interview you one question at a time and write the context file itself. Source: AI Edge (2026) ↗
For a business
When an agent runs part of a business process (matching invoices, routing leads, answering tickets), the model is the easy part. What makes it safe to leave running is the harness around it. This is how our managed automations map to the same parts.
Where harnesses matter most
Context-aware suggestions, reviews, and refactoring in your IDE—no setup scripts.
View full guide →operationsAutomate internal IT tickets, employee onboarding, and system monitoring.
View full guide →supportDeflect tickets, answer from your knowledge base, and escalate when needed—no code required.
View full guide →Sources & further reading
Every definition, number and pattern on this page traces back to one of these.
FAQ
An agent harness is the software around a language model that lets it take actions: it lists the tools the model can use, reads the tool calls in the model’s reply, runs them, and feeds the results back. Most harnesses also manage instructions, memory, permissions and context limits. A model plus a harness is what people call an agent.
Partly. Claude Code is an interface (the terminal app and the desktop app) built on a harness (the Claude Agent SDK). The same is true of the Codex apps and the Codex App Server. Products often bundle the two, which is why the words get mixed up, but the harness can run under other interfaces too.
Harness engineering is the practice of improving an agent by changing what surrounds the model rather than the model itself: clearer instructions, better tools, written-down state, checks that prove the work, and permissions. The habit behind it is simple: every time the agent makes a mistake, change the harness so it cannot make that mistake again.
A framework such as LangGraph or the OpenAI Agents SDK is a library you use to build a harness. A harness is the running result: a specific set of tools, rules, memory and checks wrapped around a model. Claude Code’s harness is shipped ready-made; a framework hands you the pieces.
Usually the harness is the cheaper fix. Anthropic and OpenAI have both published cases where the same model went from unreliable to dependable once the environment around it changed. Check the task, the context, the setup, the verification and the saved state before paying for a bigger model.
A tool is code the harness runs itself, such as reading a file. An MCP server is a separate service the harness calls over the Model Context Protocol, so the code lives elsewhere and can be shared across harnesses. Both look the same to the model: a named action with a description.
Only in pieces. Presets bundle dozens of agents and hundreds of skills, and turning them all on can leave you with a worse setup than you started with. Start with a planning agent and the rules for your main language, add a code reviewer and a security check next, try it on a small project, and remove anything you cannot explain.
Next
Tell us the work that repeats. We'll set up the agent with the rules, connections, approval steps and reporting it needs to keep running without you watching it.