Every coding agent already has a harness

People keep asking whether harness engineering is worth doing. I think that question starts one layer too late.

If you use Claude Code, Codex, Cursor, Kodus or another coding agent, you already depend on a harness. The model does not talk directly to your repository. A system around it decides how to load context, call tools, edit files, manage permissions, recover from errors, and keep working until the task is done.

The useful question is which part of that system your team needs to own.

That is where the distinction between inner and outer harnesses helps. It also explains why adding more context sometimes improves an agent and sometimes makes it worse.

The inner harness turns a model into an agent

Claude Code and Codex are inner harnesses. Their vendors decide how the execution loop works, how tools are exposed, how the context window is managed, when the agent asks for permission, and how subagents or parallel work behave.

The model provides the underlying capability. The inner harness gives that capability a job and a way to operate.

This layer has a large effect on the result. The same model can behave very differently across two coding agents because they gather context and expose tools differently. Their failure handling also changes the outcome.

Most teams will not build this layer for general coding. They will choose a coding agent and accept many of its decisions. They may replace Claude Code with Codex or OpenCode, but they are still selecting an inner harness that someone else built.

Inner and outer depend on where you draw the boundary

The terms become confusing when we treat them as fixed product categories.

Take code review. A review agent performs validation, but validation does not make it an outer harness.

At Kodus, we build an inner harness specialized for code review. It decides how a review runs, which context reaches the model, how company rules are applied, and how findings are returned to the pull request. The models inside that system can change. The review job remains because the harness carries the task-specific behavior.

A company using Kodus can add its own layer around that reviewer. Repository rules, path-specific instructions, review policies, and delivery workflows belong to that company’s outer harness.

Now widen the boundary again. If a coding agent wrote the change, the Kodus reviewer may act as one feedback control in the outer harness around that coding agent.

The same system can be an inner harness at one boundary and a component of an outer harness at another. The label only makes sense after we say which agent or workflow sits at the center.

The outer harness connects a generic agent to your company

An inner harness knows how to work with code. It does not arrive knowing which architectural rule matters in your repository, which service owns a business decision, which commands are safe to run, or what evidence your team requires before a change can ship.

The outer harness carries that knowledge. It can include AGENTS.md, skills, specs, internal tools, linters, tests, hooks, review agents, and CI policies.

Some of those controls guide the agent before it acts. They provide relevant instructions, limit the available tools, or describe how a task should be done.

Others return evidence after the agent acts. A compiler error, a failed test, a structural rule, or an independent review gives the agent something concrete to respond to.

A useful outer harness has both directions. Guidance reduces avoidable mistakes. Feedback lets the agent detect mistakes and try again without sending every failure to a person.

More context is a weak goal

I have seen teams treat context as the main measure of harness quality. They keep adding documentation, rules, examples, memories, and tool output to the prompt.

More context can help when the missing information changes the decision. It can also bury the relevant detail, introduce conflicting instructions, increase cost, and make failures harder to explain.

The inner harness owns the mechanics of context. It decides how information is retrieved, compacted, ordered, and presented to the model.

The outer harness owns much of the company-specific content. It determines which rules, documents, tools, and feedback signals should be available for a particular task.

Both layers can fail. A good retrieval system still returns bad results if the organization has stored vague or outdated instructions. Great documentation still performs poorly when the inner harness loads the wrong sections at the wrong time.

The amount of context tells us very little. What matters is whether the agent received the information needed for this decision and whether it can get evidence that its decision worked.

Where harness engineering becomes theater

The skepticism around harness engineering is understandable. Every week brings a new term, and ordinary configuration work quickly gets presented as a new discipline.

A folder full of prompt files is easy to sell and hard to evaluate. The same is true for a complicated graph of agents that nobody can connect to a recurring failure.

I would be skeptical when a harness project starts with configuration artifacts or architecture diagrams. Those are possible outputs of the work. They do not explain why the work exists.

The work becomes concrete when it starts with a failure the team has actually observed:

• Which mistake keeps happening?
• Did it come from the inner harness or from missing company knowledge?
• Would guidance have prevented it?
• Which test or signal could catch it next time?
• How will we know the change improved the result?

Sometimes the answer belongs inside the product. The agent may need a better tool, a different execution loop, or better context retrieval. That is inner harness work.

Sometimes the answer belongs to the company using it. The agent may need a repository rule, access to an internal system, or a check tied to the delivery process. That is outer harness work.

Sometimes the harness is fine and the codebase gives every agent poor feedback. No prompt can compensate for a system that cannot be tested or observed.

The decision is about ownership

Teams do not need to choose whether harnesses should exist. They already use them whenever they use an agent.

They need to decide which behavior should come from a general tool, which behavior is specific to their organization, and where repeated failures should be fixed.

For general coding, buying the inner harness usually makes sense. For a specialized task such as code review, testing, migrations, or incident response, there may be enough task-specific behavior to justify a dedicated inner harness.

The outer harness is unavoidable once generic agent behavior stops being enough. The sensible version grows from real failures and keeps only the context and controls that change outcomes.

That is also the line I would use to judge the current harness engineering debate. If the work improves how an agent performs a defined task or helps it operate inside a real engineering system, there is something to evaluate. If the work only produces more prompts and agents without a result we can inspect, the skeptics are probably right.