Last month, I hit my Cursor limit and moved back to Claude Code Desktop.
The setup that worked best for me was Sonnet 5 with the Superpowers skills I regularly use for brainstorming, planning, and implementation. The output was easier to review. The diffs were smaller. The agent spent less time changing things I had not asked it to touch.
It was tempting to reach a simple conclusion:
Sonnet 5 is better.
But I had changed much more than the model.
I had changed the interface, project instructions, skills, available context, and the workflow around the model. This was not a controlled benchmark. I was comparing two complete systems while pretending that I was comparing two models.
That difference matters.
We still talk about coding agents as if the model explains the whole result. We compare benchmark scores, context-window sizes, pricing, and reasoning capability. Then, when an agent fails, the first response is often to switch the model.
I have done that too.
More recently, I have started asking a different question:
Was the model actually the problem, or was something missing from the system around it?
That surrounding system is now commonly called the agent harness.
The term is new. The engineering is not.
A harness is the layer that turns a model response into useful work.
It gives the model access to context, tools, state, permissions, tests, approval flows, and recovery mechanisms. It also decides how the model interacts with the user and with the systems around it.
A simplified version looks like this:
User intent
↓
Application and agent harness
├── project context
├── memory and state
├── tools and data
├── permissions
├── approval rules
├── tests and evaluations
├── retries and recovery
└── logs and progress
↓
Model
↓
Action
↓
Verification
In February 2026, OpenAI published an experiment in which a small engineering team built an internal software product without manually writing the code. Codex generated the application, tests, CI configuration, documentation, observability, and internal tools.
The interesting result was not only the amount of code Codex produced.
OpenAI said that early progress was slower than expected because the environment was underspecified. The agent lacked the tools, abstractions, and internal structure needed to complete higher-level work. The engineers had to spend their time making the environment more useful and more legible to the agent. (OpenAI)
That sounds familiar to anyone who has used a coding agent on a real repository.
You ask it to implement a feature.
It writes valid code, but places it in the wrong layer.
You ask it to fix a bug.
It changes a shared component because it cannot see the intended boundary.
You ask it to update an API.
It completes the code change but misses a migration, test, documentation file, or downstream consumer.
The model may understand the local task. It does not automatically understand the system in which that task lives.
On August 19, 2026, OpenAI described the Codex harness as the reusable layer that helps a model gather context, call tools, operate within configured boundaries, request approval, maintain state, and continue work across turns. (OpenAI Developers)
That is a much better description of what we are actually building.
An agent is not a prompt connected to a model.
It is a model operating inside an environment.
I have blamed the model for problems outside the model
I first noticed this while building MCP systems.
Sometimes an agent felt slow, so the obvious suspect was model latency. But part of the delay was often outside inference.
The system had to select a tool, prepare its arguments, make a network request, wait for another service, process the result, place that result into context, and sometimes retry the operation.
Changing the model could improve one part of that path. It would not fix a slow API, a large tool response, an unnecessary retry, or poor orchestration.
The same thing happens with context.
I built Context Hub because Claude on my phone, Claude in the browser, and Claude Code on my computer behaved like three separate brains.
I could discuss an architecture idea while travelling, then sit at my desk later and start from zero. The model was not failing to reason. The next interface simply did not have access to the earlier state.
So I built a shared context layer through MCP.
At one point, I discussed an authentication approach while travelling. Later, I asked Claude Code what I had been thinking about during that conversation. It could retrieve the earlier context without me copying it into the terminal again.
The model did not become more intelligent.
The system stopped making it forget everything each time I changed the interface. (LinkedIn)
I saw a related problem while building Highlyt.
I built the MCP server before building native AI features inside the product. That looked backwards. Most products first add a chat box and then think about integrations.
My reasoning was different.
Claude and ChatGPT were already the places where I worked through ideas. My reading context was trapped in another application. The missing capability was not another chat interface. It was a reliable way for the model to search my highlights, inspect source passages, and follow the relationships I had created between ideas.
Once that context became available through MCP, the same AI tools could do work that was not possible from a generic conversation. (LinkedIn)
These examples changed how I diagnose agent behaviour.
The agent failed
│
├── Did the model lack the required reasoning?
├── Was the context missing or stale?
├── Did retrieval return the wrong information?
├── Was the tool poorly designed?
├── Was state lost between turns?
├── Was a rule written but not enforced?
├── Was there no way to verify the result?
└── Was the approval boundary missing?
Sometimes the answer is still the model.
But “use a stronger model” should be the result of diagnosis, not the first reflex.
More instructions can make an agent worse
One common response to agent failure is to add more instructions.
The agent missed a convention, so we add another paragraph to AGENTS.md or CLAUDE.md.
It repeats the mistake, so we add a stronger warning.
A few months later, the instruction file contains architecture rules, coding style, deployment steps, product decisions, testing commands, security requirements, and a collection of corrections from old incidents.
It becomes a junk drawer.
OpenAI said that its team tried one large AGENTS.md file and found that it failed in predictable ways. The file consumed useful context, made every instruction look equally important, became stale, and was difficult to verify.
The team changed the file into a short map. Detailed information moved into structured documents that the agent could load when needed. OpenAI also added checks for documentation freshness and structure. (OpenAI)
This is a useful distinction:
Prompt stuffing
Load every rule
Load every document
Load every past decision
↓
Large context
Weak focus
High maintenance
Progressive context
Start with a small map
Find the relevant source
Load only what the task needs
↓
Smaller context
Clearer authority
Easier maintenance
Anthropic describes context as a finite resource. An agent must continuously choose which instructions, tools, external data, and message history belong in the next model call. More context does not always produce better behaviour. It can also reduce focus. (Anthropic)
Tool design has the same constraint.
A tool is not useful only because the model can call it. Its name, inputs, response shape, boundaries, and returned context all affect whether the agent can use it correctly. Anthropic recommends clear tool boundaries, meaningful tool responses, and token-efficient results. (Anthropic)
This is why harness engineering is still software engineering.
You are designing interfaces between a non-deterministic model and deterministic systems. You must decide what information crosses that boundary, how errors are represented, which actions can be retried, and what happens when the result is incomplete.
A better prompt cannot repair a bad contract.
The budget question also changes
Leadership teams often begin an AI project with this question:
Which model should we use?
That question matters, but it comes too early.
A better first question is:
What must the complete system do reliably?
For example:
Which company data must the agent access?
Which source is authoritative?
Which actions can happen automatically?
Which actions require approval?
Can the team replay a failed run?
Can engineers see the tool calls and intermediate state?
Can the system detect stale context?
How will the team measure task success?
What happens when the preferred model changes?
These are product and operating decisions, not only engineering details.
Buying access to a frontier model is easy to see. Harness work is less visible. It includes documentation, retrieval, permissions, evaluations, observability, retry rules, and human-review paths.
But that less visible layer contains much of the company-specific behaviour.
OpenAI’s latest Codex platform design makes this separation explicit. The host application owns the interface, business context, rules, tools, and consent. The harness manages the agent loop and execution. (OpenAI Developers)
That separation has an important business benefit.
A company does not have to place all of its workflow logic inside one model prompt or one vendor-specific interface. It can keep its product rules, permissions, context sources, and approval processes in systems it controls.
Changing the model will never be free. Different models use tools differently and respond differently to the same context.
But a well-separated harness makes the boundary visible.
Without that boundary, the model, prompt, tools, interface, and business logic become one large dependency that nobody fully understands.
Harness engineering can also become an excuse to overbuild
I like the harness-engineering framing, but I think it can be taken too far.
A strong harness cannot make a weak model complete a task that is outside its capability.
Model quality still matters. Reasoning quality matters. Tool-use ability matters. Long-context performance matters. For difficult work, a stronger model can be the correct solution.
The harness also adds its own problems.
Every tool creates another interface to maintain. Every context source can become stale. Every retry can increase cost and latency. Every added permission increases the possible blast radius. Every abstraction can hide useful details from the engineer trying to debug the system.
You can build an impressive agent platform that is much more complex than the task requires.
The rule I use now is simple:
Add a harness component when a repeated failure shows that the capability is missing.
Add persistent state when work must survive across sessions.
Add an approval step when an action is expensive or difficult to reverse.
Add an evaluation when the same type of failure keeps returning.
Add retrieval when the required context cannot fit cleanly into the working window.
Add orchestration when one agent loop can no longer manage the task without losing control.
Do not add all of them because an architecture diagram looks incomplete.
The simplest working loop is still valuable.
The model is important. It is not a complete explanation.
OpenAI reported one recent example where retained reasoning and context compaction increased GPT-5.6 Sol’s score on ARC-AGI-3 from 13.3 percent to 38.3 percent while reducing output tokens by a factor of six.
That is one benchmark from one system. It does not prove that every harness improvement will triple performance.
It does show that changes around the model can materially change what the model appears capable of doing. (OpenAI Developers)
We will probably continue comparing agents by model name because model names are easy to see.
The harder parts sit underneath:
What did the agent know?
Which tools could it use?
What state did it retain?
Which actions required approval?
How did it check its work?
What happened when something failed?
Those questions are less exciting than a new benchmark chart. They are also the questions that decide whether an agent remains a demo or becomes a reliable system.
I will keep comparing models.
But the next time an agent fails, I will not ask only, “Which model should I try instead?”
I will first ask what capability was missing from the environment around it.
Sometimes the correct answer will still be: use a better model.
I just want that to be a diagnosis, not a ritual.
Great insights