Most discussions about AI agents start with the model. Which model is better? Which model can reason longer? Which model writes better code?
\nI think this is the wrong place to focus first.
\nA model can produce many possible outputs. It does not know by itself which output is correct for my system. It also does not know when the work is complete. I need a system around the model that gives it the right information, limits what it can do, checks its work, and sends it back when it goes in the wrong direction.
\nThis system is called the harness.
\nThe 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.
\nThis 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.
\nThere 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.”
\nAutonomy does not mean fewer checks. It means moving the checks, feedback, and correction into the harness.
\nI 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.
\nContext 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.
\nFor 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.
\nAnthropic 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.
\nGood 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.
\nSmart context is therefore not only retrieval. It is selection, compression, and clear structure.
\nContext tells the model what matters now. Memory tells the harness what must not be rediscovered every time.
\nI do not treat memory as a transcript of old conversations. A transcript becomes large and noisy. I want selected memory.
\nThe useful memory is usually in three groups:
\nThe third group is the most important for harness improvement.
\nIf 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.
\nSometimes 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.
\nGuardrails decide whether the current output is acceptable.
\nI use two types.
\nThese 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.
\nJoin Medium for free to get updates from this writer.
\nIf a deterministic check can detect the error, I do not need another model to make that decision.
\nSome 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.
\nFor 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.
\nI prefer a separate agent or a fresh context for this review. The builder should not be the only judge of its own work.
\nI 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.
\nThe goal is not to make one model perfect. The goal is to build a review loop that makes the final result better.
\nA guardrail is not useful if it only reports a failure to a human.
\nThe harness should use the failure as input for the next attempt.
\nImplement → check → collect evidence → return failure to the agent → fix → check again.
\nThis 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.
\nThis 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.
\nPassing tests is not enough. I also run the actual system end to end.
\nIn 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.
\nThe 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.
\nThis 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.
\nThe browser validation checks the actual running product.
\nIf 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.
\nFor me, this is an important part of the harness. The agent does not decide that the work is done. The harness verifies it.
\nOnly after deterministic checks, agentic review, and runtime validation pass should the system move to the next state.
\nI still want human review. I just do not want humans to repeat checks that the harness can perform better and more consistently.
\nThe 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.
\nIn other words, the harness should remove mechanical review work so that humans can spend time on judgment.
\nThis 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.
\nThen measure whether the failure happens less often.
\nThis 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.
\nThat 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.
\nBetter models will help. Better harnesses will compound.
\nPS: Written with AI assistance. If you liked the article, please support it with claps 👏. Cheers
","headings":[{"level":1,"text":"The Model Is the Engine. The Harness Makes It Reliable.","id":"the-model-is-the-engine-the-harness-makes-it-reliable"},{"level":2,"text":"Models will keep changing. The harness is what makes an agent reliable: smart context, memory, guardrails, correction loops, and validation against the real system.","id":"models-will-keep-changing-the-harness-is-what-makes-an-agent-rel"},{"level":2,"text":"The harness is a layered system","id":"the-harness-is-a-layered-system"},{"level":2,"text":"1. Smart context: give the model what it needs","id":"1-smart-context-give-the-model-what-it-needs"},{"level":2,"text":"2. Memory: make the system learn from previous work","id":"2-memory-make-the-system-learn-from-previous-work"},{"level":2,"text":"3. Guardrails: deterministic first, agentic second","id":"3-guardrails-deterministic-first-agentic-second"},{"level":2,"text":"Deterministic guardrails","id":"deterministic-guardrails"},{"level":2,"text":"Get Mitesh’s stories in your inbox","id":"get-mitesh-s-stories-in-your-inbox"},{"level":2,"text":"Non-deterministic, agentic guardrails","id":"non-deterministic-agentic-guardrails"},{"level":2,"text":"The important part is the correction loop","id":"the-important-part-is-the-correction-loop"},{"level":2,"text":"4. Validation: run the real system","id":"4-validation-run-the-real-system"},{"level":2,"text":"Human review moves up a level","id":"human-review-moves-up-a-level"},{"level":2,"text":"When the agent fails, improve the harness","id":"when-the-agent-fails-improve-the-harness"}]}}