Optimize the Harness, Not Only the Model

An agent harness is the operating system around the model. It includes the prompts, instructions, available tools, reusable skills, context, execution environment, and the codebase in which the agent works. Model capability matters, but the harness determines how effectively that capability is converted into reliable work.

The practical mistake is to treat model selection as almost the entire problem. A more balanced view gives substantial attention to both the model and the harness. The model supplies reasoning and generation capacity. The harness supplies direction, constraints, access, feedback, and an environment that is easy to operate in.

The same model can perform very differently in two different environments. In a difficult codebase, the agent may spend large amounts of context and time locating relevant code, resolving unclear interfaces, retrying failed changes, and inferring undocumented expectations. In a well-designed codebase, the path from task to implementation is shorter.

Harness quality can be improved through:

• Clear prompts that state the goal and decision boundaries.
• Skills that provide a reusable procedure at the right moment.
• Tools that let the agent inspect, modify, test, and review the system.
• Sandboxed execution that contains the agent's actions.
• Documentation that points to the correct modules and conventions.
• Tests and guardrails that provide feedback.
• A codebase architecture that is easy to navigate and change.

This has a direct relationship to token use. If the codebase is easy to understand and modify, the agent needs fewer attempts and less exploratory reasoning. A less capable or cheaper model may then complete work that would otherwise require a more capable model to overcome environmental friction.

A harness can also be kept relatively agent-agnostic. Instead of building a workflow around the quirks of a single model release, the system can rely on software practices that remain useful across models: clear interfaces, small tasks, tests, documentation, isolation, and review.

Agent experience, or AX, is the experience an agent has while working in the codebase. It parallels developer experience, or DX. A codebase that is understandable and changeable for human developers often provides many of the same advantages to agents. Better skills, a stronger harness, and a better-structured codebase all improve AX.

The harness is more controllable than the model. A team cannot directly redesign the underlying model, but it can improve the codebase, instructions, tools, execution environment, and review process every day.

This makes harness work a durable source of advantage. Model improvements may raise the capability of every user at once. Harness improvements compound inside a particular workflow because they encode how that team plans, delegates, checks, and learns.

Harness-first thinking also reduces dependence on hype cycles. A newly released model may be better, but practical adoption still involves cost, latency, and availability. A team with a strong harness can evaluate the model as one replaceable component rather than reorganizing its entire practice around each release.

Use this sequence when an agent performs poorly:

1. Observe the failure precisely. Determine whether the agent misunderstood the goal, lacked access,

could not find the right code, encountered an unclear interface, missed a test, or made a weak judgment.

1. Classify the cause. Separate model limitations from harness limitations. Do not assume that every

failure requires a stronger model.

1. Improve the environment first when possible. Add a focused instruction, clarify the task

boundary, improve a test, simplify a module, or add a pointer to the correct location.

1. Re-run the same class of task. Check whether the change reduced retries, confusion, and token

use.

1. Evaluate model upgrades on operational criteria. Compare the quality gain with cost, latency, and

availability rather than adopting a new model only because it is new.

1. Avoid model-specific overfitting. Prefer improvements that would help any competent agent work in

the repository.

One conservative adoption policy is to let a new model settle before making it the default. This creates time to see how its capability, price, latency, and availability behave in practice. That is an operating preference, not a requirement; the important point is to evaluate the whole system rather than the model in isolation.

There is a strong counterargument to harness-first optimization. The "bitter lesson" framing is that increases in raw compute and model capability can outrun hand-built optimizations. A more powerful model can overcome weaknesses in the surrounding system, require less steering, notice deeper bugs, and produce useful behavior that was not explicitly engineered into the harness.

The correct response is not to ignore model improvements. It is to avoid treating them as a substitute for engineering. A stronger engine improves the system, but a poor chassis still wastes capability. The model and harness should be improved together, while recognizing that the harness is the component the team can shape most directly.

Future models may reduce the amount of handholding they require. That possibility does not justify waiting or neglecting fundamentals. Clear tasks, coherent codebases, tests, and observability remain useful under the current workflow and are designed to remain useful when the model changes.

Treat the model as one component of an agentic system. Improve the prompts, skills, tools, codebase, execution environment, and feedback mechanisms that determine how well the model can work.