The Model Is the Brain. The Harness Determines Whether the Agent Finishes the Job

TL;DR: On July 22, I gave an internal talk on Harness Engineering based on a week of studying the Codex codebase. The model provides reasoning, but reliable task completion also depends on context, tools, permissions, the execution environment, verification, and recovery. Backend engineers already know many of these problems. The new work is learning how those familiar systems change when the user of the system is a probabilistic model.

---

On July 22, I gave an internal talk about what I had learned from reading the Codex codebase.

I followed one task through its lifecycle: how the goal enters the system, how context is assembled, how the model selects tools, where commands run, when permissions are checked, how failures return to the model, and how the final result gets verified.

I also used two hands-on tasks. Concrete tasks made the architecture much easier to understand. They showed why the same coding agent can look excellent in one run and get stuck on a small detail in another.

The simplest description I found was this: the model is the brain.

The harness is the engineering system around that brain. It connects context, tools, memory, execution, permissions, monitoring, and feedback so the model has a chance to produce a result that someone can verify.

§Intelligence Does Not Guarantee Completion

Model comparisons often focus on leaderboards, parameters, and single answers.

Real work usually takes more than one answer.

When an agent changes a codebase, it has to understand the goal and constraints, locate the right files, choose an edit, call tools, and run tests. If a test fails, it needs to read the error, revise the plan, and verify the new result. Some actions only read data. Others change files, publish content, or affect an external system. Those actions need different permission boundaries.

Each individual choice may look reasonable. Across dozens of steps, a small error can compound.

I see this often when using Codex for long tasks. A vague goal can send the agent in the wrong direction with impressive thoroughness. Too much context can hide the important constraint. Without a definition of done, the agent may stop after editing code and never run the test. When a tool returns a vague error, the model may retry the same action without learning anything.

A stronger model may reduce some of those failures. The surrounding system still has to catch the rest.

§What the Harness Has to Handle

The codebase contains many layers. Five concerns have been the most useful in my own work.

The task needs a precise contract.

The goal, relevant background, constraints, and definition of done should travel together. If one is missing, the model may fill the gap with a plausible assumption. OpenAI's own Codex guidance makes the same practical point: clear goals, context, constraints, and completion criteria make the result more reliable.

Context has to stay useful.

An agent needs relevant files, prior decisions, and tool results. Loading everything at once can bury the task. Loading too little creates blind spots. Selective reading, summaries, and compression determine whether a long-running task keeps its direction.

Tools need legible behavior.

The model needs to know what a tool does, what input it expects, and what success or failure looks like. A vague error gives it little to work with. A structured result gives it a chance to diagnose the problem and continue.

Permissions and execution need boundaries.

Reading a file and deleting one carry different risks. Preparing a draft and publishing it are also different operations. A sandbox limits what the agent can touch. Approval gates return high-risk decisions to a person. Loose permissions create danger. Excessive approval prompts make every task stall.

Results need verification and recovery.

Code changes should run tests. A UI change should be opened and inspected. A migration should compare the state before and after. If a task stops halfway through, the system should know what already happened. Without those checks, an agent can produce a convincing completion message without a completed result.

Together, these concerns are what I mean by Harness Engineering.

§Why Backend Experience Transfers

The next day, I wrote down another connection. Traditional business systems were primarily built for people. A harness also has to serve a model.

Both systems deal with instability.

An e-commerce backend handles timeouts, duplicate requests, permissions, state changes, and retries. An agent system encounters tool timeouts, lost context, repeated actions, denied permissions, and interrupted tasks. Logging, monitoring, storage, state machines, idempotency, and recovery still matter.

Models add their own failure modes.

Their next action is generated probabilistically. Context windows are limited, so long tasks need compression and memory. Ambiguous tool descriptions can change behavior. System prompts, tool protocols, model evaluations, and task traces become part of the engineering surface.

This is the part that excites me.

Backend engineers do not have to discard years of experience. They can map familiar reliability problems onto agent systems, then learn the model-specific parts around context and evaluation. That path feels more durable than chasing every new agent term.

§How I Am Learning It

I did not begin by trying to build a complete theory.

For the internal talk, I traced a real Codex task through the code. I looked for where the user goal enters, how files become context, where tools are called, when approval is requested, how state is recorded, and how an error returns to the model. When a module felt abstract, I used one of the hands-on tasks to find the reason it existed.

The next step is customized evaluation. For a defined task, I want to record where the model drifts, what the harness does in response, and which failure still cannot recover. That is how source reading turns into reusable engineering knowledge.

If you want to explore this area, start with one task you already do every day. Write down the goal and definition of done, let Codex run the full path, keep the tool trace and failure points, and then study the parts of the system that shaped the result.

There is no need to rename your job first.

Make one real task fail less often, recover more cleanly, and produce evidence you can verify. The value of the harness becomes concrete from there.