This system is called the harness.

The vehicle analogy is useful. The model is the engine. The harness is the rest of the vehicle: steering, brakes, sensors, navigation, and the control loop. A stronger engine does not make the vehicle autonomous. The vehicle becomes autonomous when the complete control system can move from one state to another, detect errors, correct them, and verify that it reached the destination.

This is why I now spend more time on the harness than on model selection. Models will improve and models will change. A good harness should make those changes easier to absorb.

There is also public evidence for this. LangChain kept GPT-5.2-Codex fixed and changed only the harness. Its Terminal-Bench 2.0 score moved from 52.8 to 66.5. Cline reported that a new harness reduced tasks that reached its mistake limit from 6.34% to 0.62%. OpenAI describes the same operating model in four words: “Humans steer. Agents execute.”

Autonomy does not mean fewer checks. It means moving the checks, feedback, and correction into the harness.

The harness is a layered system

I think about the harness as a stack. Each layer solves a different failure mode. When the agent makes a mistake, I ask which layer should become stronger.

1. Smart context: give the model what it needs

Context is the first control surface. The goal is not to give the model more context. The goal is to give it better context in less space. I want the smallest set of high-signal information that is enough for the current task.

For a coding task, this can include the current goal, the acceptance criteria, the relevant files, the important interfaces, the recent decisions, and the latest failure. It should not include the complete repository just because the repository is available.

Anthropic describes context engineering in a similar way: find the smallest set of high-signal tokens that improves the result. That matches how I want the harness to work.

Good context also needs structure. The agent should know what is fact, what is a requirement, what is a previous decision, and what is only a suggestion. If everything enters the context as unstructured text, the model must first determine what matters before it can solve the task.

Smart context is therefore not only retrieval. It is selection, compression, and clear structure.

2. Memory: make the system learn from previous work

Context tells the model what matters now. Memory tells the harness what must not be rediscovered every time.

I do not treat memory as a transcript of old conversations. A transcript becomes large and noisy. I want selected memory.

The useful memory is usually in three groups:

1. System knowledge: how the codebase or product works.
2. Decisions: choices that should stay stable unless we change them deliberately.
3. Lessons from mistakes: failures that should not happen again.

The third group is the most important for harness improvement.

If an agent makes the same mistake twice, I do not want to keep adding prompt text and hope the model remembers it. I want to ask what permanent control can prevent that mistake.

Sometimes the answer is a short rule. Often the better answer is a type, a test, a lint rule, a hook, or a sandbox restriction. The memory gives me the lesson. The harness turns the lesson into enforcement.

3. Guardrails: deterministic first, agentic second

Guardrails decide whether the current output is acceptable.

I use two types.

Deterministic guardrails

These should run first because the result is clear. In a TypeScript project, examples include type checking, linting, unit tests, integration tests, build checks, dependency rules, and policy checks.

Get Mitesh’s stories in your inbox

Join Medium for free to get updates from this writer.

If a deterministic check can detect the error, I do not need another model to make that decision.

Non-deterministic, agentic guardrails

Some checks require judgment. A common failure is that an agent says the task is done even when the implementation is incomplete. The code can compile and the tests can pass, but the result can still miss part of the plan.

For this case, I use an independent review step. The reviewer gets the plan, the acceptance criteria, and the implementation. It checks whether the work matches the intended result. This can include code review, missing cases, incorrect assumptions, and incomplete functionality.

I prefer a separate agent or a fresh context for this review. The builder should not be the only judge of its own work.

I have also tried a multi-model setup. For example, Claude writes the code and Codex reviews it. I saw a significant improvement with this approach. The second model often finds issues, missing cases, and design problems that the first model did not catch. The feedback then goes back to the builder. The builder fixes the issues, and the review runs again.

The goal is not to make one model perfect. The goal is to build a review loop that makes the final result better.

The important part is the correction loop

A guardrail is not useful if it only reports a failure to a human.

The harness should use the failure as input for the next attempt.

Implement → check → collect evidence → return failure to the agent → fix → check again.

This is the steering system. If the agent moves in the wrong direction, the harness should detect the deviation and provide enough evidence for the agent to correct it.

This is also where memory and guardrails connect. A single failure should be fixed in the current task. A repeated failure should improve the harness for future tasks.

4. Validation: run the real system

Passing tests is not enough. I also run the actual system end to end.

In my setup, the web application and backend services run inside Docker containers. I start the complete system, seed it with data and then open it in a real browser.

The validation flow uses the application like a user would. It logs in, opens pages, clicks features, performs actions, and checks the result. I also take screenshots at important steps.

This gives me a different level of confidence. A type check tells me that the code is valid. A unit test tells me that one part behaves correctly. But neither proves that the complete system works when all parts run together.

The browser validation checks the actual running product.

If something is wrong, the result goes back to the agent. The agent fixes the issue, and I run the validation again. Only after the system passes these checks do I consider the implementation complete.

For me, this is an important part of the harness. The agent does not decide that the work is done. The harness verifies it.

Only after deterministic checks, agentic review, and runtime validation pass should the system move to the next state.

Human review moves up a level

I still want human review. I just do not want humans to repeat checks that the harness can perform better and more consistently.

The human review should focus on functionality, product judgment, architecture, and long-term trade-offs. I do not want the main human task to be finding a missing type check or discovering that a button does not work.

In other words, the harness should remove mechanical review work so that humans can spend time on judgment.

When the agent fails, improve the harness

This is the operating principle I use now. If the model lacks information, improve context. If the system forgets a decision or repeats a known mistake, improve memory. If bad output can be detected mechanically, add a deterministic guardrail. If the output needs judgment, add an independent agentic review. If local checks pass but the product is still wrong, improve runtime validation.

Then measure whether the failure happens less often.

This creates a layered improvement loop. Each failure can make the harness better. The model can change, but the system keeps its knowledge, controls, and validation.

That is why I do not see the model as the complete product. The model is a powerful engine. The harness is what turns that engine into a reliable autonomous system.

Better models will help. Better harnesses will compound.

PS: Written with AI assistance. If you liked the article, please support it with claps 👏. Cheers