Same model, different result
The article opens with a number that breaks the most common intuition. LangChain's coding agent went from 52.8% to 66.5% on Terminal Bench 2.0, a benchmark of real tasks in the terminal. It climbed from 30th place to the top 5 of the leaderboard. And it did it without changing a single model parameter: the only thing that changed was what surrounded the model.
The author pairs it with two figures that show why the topic matters. Gartner predicts that over 40% of agentic AI projects will be canceled by 2027, and seven independent studies agree that agents fail 70 to 95% of the time on complex enterprise tasks.
Faced with those failures, the usual move is to blame the model. The article argues the opposite: models have become a commodity. Claude, GPT and Gemini converge in capability every quarter, and the teams shipping agents to production aren't the ones with access to the best model, but the ones that built the best system around it. The question that matters is no longer which model you pick, but which system wraps it.
What a harness is
A harness is the infrastructure that wraps the model and manages how it works. It isn't the model, which does the reasoning, and it isn't the prompt, which is what you ask for at each moment. It's everything else: what information reaches the model, which tools it has, which checks its results go through and what gets saved for next time.
The author's example comes from OpenAI: they built a production application with over a million lines of code, none of them written by a person. The engineers didn't write the application; they designed the harness. They added constraints, feedback loops, documentation, linters (programs that review code automatically) and lifecycle management, so the model could write code reliably.
According to the article, the harness has three jobs:
Deciding what information the model sees at each step, no more and no less.
Enforcing what the model can do and what it cannot do.
Letting the model learn from its own history instead of starting from scratch.
Without a harness, a model reasons well in isolation but fails in production. With one, you have a system that gets better over time.
Why the giant instructions file fails
The first mistake the article points out is very common among people working with coding agents. You start with a CLAUDE.md or an AGENTS.md, the instructions file the agent reads at the start, and little by little it turns into an encyclopedia. Every edge case adds a rule and every failure adds an instruction, until the file hits 2,000 lines and the model starts ignoring half of it.
The reason is that context is a scarce resource. Everything the model reads takes up room in its context window, and a giant instructions file crowds out what really matters: the task, the code and the relevant documentation. When everything is «important», nothing is.
OpenAI's Codex team solved it by treating the instructions file as a table of contents. The knowledge lives in a docs/ folder organized by topic, and the model gets the right context at the right time instead of drowning in all the context all the time.
docs/.The pattern it proposes has four rules:
- Short root file: under 200 lines.
- Knowledge by topic: organized in a structured directory.
- Dynamic context: load the relevant documentation for each task, not everything every session.
- Aggressive pruning: if a rule hasn't prevented a failure in 30 days, remove it.
It's what I do in the project I use to make these videos: the CLAUDE.md is a short index, and everything worth remembering between sessions lives in a docs/ folder, one document per topic.
The four pillars
Harness engineering, according to the author, rests on four pillars. Typical setups build one or two; production requires all four.
1. Layered context architecture
The model doesn't see everything at once: information is disclosed progressively. First the project, then the module and finally the file.
- Layer 1, project: architecture, conventions and invariants. Always loaded.
- Layer 2, module: the module's docs, schemas and constraints. Loaded per task.
- Layer 3, file: file history, recent changes and related test results. Loaded per file.
It also proposes a context budget: track how many tokens each layer uses and alert when any of them goes over 40% of the window.
2. Specialized agents
A single generalist agent doesn't scale. Production systems use specialized agents, with narrow responsibilities and scoped tools.
- One agent per domain: code generation, testing, review and deployment.
- Only the tools it needs: no universal access.
- Structured handoffs: agents communicate through defined deliveries, not by sharing the same context window.
- One system prompt per role: an agent that writes tests doesn't need deployment instructions.
3. Persistent memory
Conversation history vanishes when the window closes, and that isn't memory. Real memory lives in the file system:
decisions.md: architectural decisions, with their rationale and date.failure-catalog.md: an indexed catalog of failures and how they were resolved.session-state.md: what changed last session, which tests broke and what the agent learned.
The agent reads memory at the start of each session and writes it at the end. Memory is append-only, to keep an audit trail, and it's pruned in a separate review process.
4. Structured execution
The model should never jump from the prompt to the code in one step. Structured execution enforces a workflow: research, plan, execute and verify. The article spells it out in six steps:
- Read: the agent reads the relevant context and its memory.
- Plan: it produces a plan with the files it will change, the tests it will write and the risks.
- Review the plan: a person or an automated process reviews it before execution.
- Execute with guardrails: with a maximum number of files per session, protected file lists and simulation before deploying.
- Verify: tests, linting and security scanning.
- Remember: the agent writes the session results to memory.
Non-negotiable guardrails
Above the four pillars sit the guardrails. The author insists on treating them as hard policy enforcement the agent cannot override, and arranges them in a hierarchy:
- Hard limits: the agent can't relax them.
- Safety nets: they catch failures before they reach production.
- Golden paths: they guide the agent toward the right patterns.
- Audit: it lets you reconstruct what happened.
In practice, they translate into a cost ceiling per session, a time limit with auto-pause, protected file lists, simulation before every deployment, mandatory tests before every commit and an audit log of every agent action.
The compounding effect: the real moat
An agent without a harness starts from zero every session: it rediscovers patterns, repeats mistakes and carries no knowledge forward. An agent with a harness compounds. Every session adds entries to the failure catalog, every decision is recorded with its rationale and every interaction pattern is indexed for reuse.
According to the article, OpenAI's Codex team saw their agents become more reliable over time. Not because the model improved, but because the harness accumulated context that made the model's job easier.
That's the real moat, the advantage competitors can't copy. The model is interchangeable; the harness isn't. Six months of accumulated context, failure patterns and architectural decisions can't be replicated by switching to a new model or a new framework.
The model is the engine
For anyone building agents, the takeaway is clear. The model layer is commoditizing fast, and the gap between the best models narrows with every release. The author cites Carnegie Mellon: agents complete only 24% of standard office tasks, and the failure is infrastructure, not intelligence.
The teams that win build harnesses instead of shopping for models. LangChain proved it: same model, better harness, top 5.
And there's a twist I find the most interesting idea in the article: harness engineering matters more as models get better. A better model lets you give the agent more autonomy, and more autonomy demands better guardrails.
The harness is the product. The model is the engine. And nobody buys a car just for the engine.
The production checklist
The article ends with a checklist that sums up everything above. I'm including it because it's the most useful part for reviewing the harness of your own agents:
- Root instructions file under 200 lines.
- Knowledge organized by topic in a directory.
- Documentation loaded per task.
- Context budget per layer, with alerts.
- Stale rules pruned every month.
- Separate agents to generate code, test and review.
- Scoped tools for each agent.
- Documented handoffs between agents.
- System prompt per role.
- Decisions, failures and session state stored in files.
- The agent reads memory at the start.
- The agent writes results at the end.
- Append-only memory, with separate pruning.
- Research → plan → execute → verify workflow.
- Plans reviewed before execution on critical paths.
- Maximum number of files per session.
- Protected files against unauthorized changes.
- Verification after every step.
- Cost ceiling per session.
- Time limit with auto-pause.
- Simulation before every deployment.
- Tests passing before every commit.
- Audit log of every action.
In short: the model brings the power, and the harness brings everything else. What does the harness of your agents look like?
Sources
The figures in this post are the ones cited in the original article; I didn't measure them myself.
- «The Harness Is The Product. The Model Never Was», by nyk (@nykdotdev), March 10, 2026.
- The video, on my three channels: English, Spanish and Portuguese.
