Coffee & Cake: Models, Agents and Harnesses

Models, Agents, and the Harness Around Them

Two products can advertise exactly the same language model and behave like entirely different machines. One waits for a question and writes an answer. The other searches through files, opens an error log, changes a line of code, runs a test, notices that the test failed, and tries something else. If the model underneath is the same, where did all that extra ability come from?

The answer sits in three related ideas that are often squeezed into the single word artificial intelligence: the model, the agent, and the agent harness. The borders are not perfectly standardized. Companies and researchers sometimes use agent for different slices of the system. But there is a practical distinction that makes the whole subject much easier to understand.

Start with the model. A model is the trained computational machinery. During use, it receives an input and produces an output. For a language model, the input might include your request, instructions, earlier messages, and descriptions of available tools. The output might be ordinary prose. It might also be a structured request that effectively says: read this file, search for this phrase, or run this test.

That last point matters. Asking for a tool is not the same as using it. If the model produces a request to read an error log, no log has yet been opened. The model has generated an output, just as it might generate a sentence. Something outside the model still has to recognize the request, decide where it should go, carry it out, and return the result.

Now consider the agent. An agent is easiest to recognize across a sequence of steps, not in one isolated answer. It receives a goal, chooses an action, sees what happened, and adjusts. The same model may be called again and again during that sequence. Each result changes what it sees next. The useful new ingredient is not a tiny digital person living inside the computer. It is a feedback loop in which the model can help decide the next move.

Imagine that a company's contact form has stopped working. A user asks an agent to find the cause and fix it. On its first turn, the model may decide that it needs the error log. After reading the result, it may choose one file to inspect. Then it may propose an edit and request a test. If the test fails, that failure becomes new evidence. The model can revise its guess, inspect another file, and try again.

That adaptive sequence is the agentic part. The path was not fully written in advance. Nobody had to predict which file would be broken, which error would appear, or how many attempts would be needed. The model selected its next step from what the environment revealed.

This gives us a useful contrast. Suppose a program always searches a database, summarizes the first three results, and sends an email, in that order. Models may write the search query and the summary, but the route itself is fixed. That is better described as a workflow. If the model can decide that the first results are poor, search somewhere else, ask a clarifying question, or stop before sending, the system is more agent-like. Agency is a sliding scale, not an on-off switch.

We still have a missing piece. Who gave the model a description of the log-reading tool? Who noticed its request, ran the tool, collected the output, and placed that output into the next call? Who kept the task alive from one turn to the next? That surrounding orchestration is the harness.

A harness is software that connects the model to the rest of the working system. At minimum, it runs the loop: assemble the current context, call the model, interpret the result, route any tool request, return the observation, and repeat. It may also choose which instructions and tools are visible, carry forward the session, handle an error, pause for approval, or stop after too many turns.

The harness is not necessarily the place where every action happens. A separate tool reads the log. A separate execution environment may run the test. A session store may keep the record of what happened. Products package these pieces differently, which is one reason the vocabulary becomes slippery. The clean mental picture is that the harness conducts the exchange between the model and those external parts.

Return to the broken contact form. The model requests the error log. The harness routes that request to a tool. The tool opens the log and returns its contents. The harness places those contents into the next model call. The model requests a file. The harness routes that request too. Later, the model proposes an edit and asks for a test. The edit and test occur outside the model, while their results travel back through the harness. Model, agent, and harness are not three competing products. They are three views of the same work at different layers.

This is why changing the harness can alter what seems to be the intelligence of an agent. Give the same model vague tool descriptions and a noisy wall of irrelevant history, and it may stumble. Give it clear tools, well-selected context, and useful feedback from the environment, and it may complete the task. The learned model has not changed, but the system has become easier for it to operate.

The reverse can happen too. A harness may contain elaborate workarounds for a weakness in one model. Replace that model with a newer one, and those workarounds can become useless or even distracting. Models are sometimes trained to use particular tool formats, while harnesses are tuned around particular model behaviour. The layers can be distinguished, but they are not independent pieces that always swap cleanly.

Several common claims now become easier to untangle. An agent is not necessarily a special model. It is usually a model operating with a goal, tools, observations, and some freedom to choose the next step. A harness is not merely a long instruction at the start. The instruction is one ingredient; the harness also manages repeated calls and connections to the environment. And an agent does not need a team of other agents. One model in one simple loop is enough.

Nor does the model name tell you the capability of the finished agent. A model with no access to files cannot repair a repository. A system that discards crucial test output may repeatedly make the same mistake. Two agents built on the same model can differ because one has better tools, more useful context, a larger working budget, or a clearer way to recover from failure. When someone reports what an agent accomplished, the model matters, but so does the harness in which it worked.

More agency is not automatically an improvement. If a task is stable and its steps are known, a fixed workflow is often faster, cheaper, and easier to predict. Letting a model choose every turn adds flexibility, but it also adds more model calls and more chances for an early mistake to lead to another. The sensible design is not the most autonomous one. It is the least open-ended system that can still handle the uncertainty of the job.

So the next time a product is called an AI agent, ask three questions. Which model is generating the decisions? Who chooses the next step: fixed code, a person, or the model responding to evidence? And what does the harness place around that model: which tools, which context, which feedback, and which stopping conditions?

Those questions reveal far more than the label. The model supplies learned capability. The agent is that capability pursuing a goal through an adaptive sequence. The harness turns the sequence into a working connection with the world. Once those layers come apart, it becomes much easier to see what the system can actually do, and where its apparent intelligence is really coming from.