Harness Engineering: The Architecture Around the Model

Whenever I build a software system, architectural patterns help me organize my thinking. They rarely give me the complete answer, but they give me a useful mental model; they help me decide where responsibilities should live, how components should communicate, and where I need to introduce controls.

Over the past year, I have seen a significant architectural shift in the way AI agents are being built. In 2025, most agent architectures I encountered were represented as graphs. Using frameworks such as LangGraph, you would define nodes, states, transitions, and the tools available at each stage. The model was given some freedom to decide how to move between those states, but you still designed most of the possible routes in advance.

The technique that is now becoming increasingly important is Harness Engineering. And while it does not necessarily replace graphs, something fundamental does change and that is the main architectural question.

Instead of asking only:

You begin asking:

I like to think about a harness-based system as a playground, or perhaps a theme park. Not a childish one, you get the idea. It should be designed as a controlled environment in which the model can move in circles, interact with tools, examine information, try different approaches, receive feedback, and continue until it completes the task.

In your hands, the AI Engineer, you get to choose which tools are available, what the model is allowed to do, what information it can access, and essentially a good AI engineer is an expert in defining what conditions prove that the task is complete. The agent decides then how to move between those elements.

In this article, I want to explain how I think about Harness Engineering, how it relates to Prompt Engineering and Context Engineering, and why I believe it is becoming an important architectural discipline for autonomous AI systems.

Where Harness Engineering Sits in the AI Engineering Stack

You probably remember what working with the first widely adopted language models felt like in 2022 and 2023. They were mostly disconnected from external systems, isolated chat interfaces. The main technique available to you was Prompt Engineering in which you explained what role the model should play, what action it should perform, which rules it should follow, and what kind of output you expected. At its core, Prompt Engineering was about defining the model's identity, objective, behavior, and expected output format.

Then the next problem became obvious. Even if the model understood the task perfectly, it did not necessarily have the information or tools required to complete it. A model trained up to a particular knowledge cutoff does not automatically know today's date, the latest version of a software library, the current state of a customer account, or what happened inside your company yesterday.

This is where Context Engineering entered the picture. Context Engineering is about giving the model the right information at the right time. RAG, MCP, tool calling, search, databases, APIs, and memory became part of the communication layer between the model and the world around it.

The distinction I like to use is simple:

This transition turned models from isolated chat systems into much more capable work interfaces. But it also raised to bar and exposed another limitation towards full autonomy of AI systems: a model could understand the task and have access to the relevant information, yet still be unable to execute a long process reliably.

That is where agents entered the picture. I expect an agent to run a process on my behalf, for as long as necessary to complete the task: to investigate, interact with systems, update its understanding, produce artifacts, inspect the results of its own actions, and decide what to do next.

That is where Harness Engineering becomes relevant. The harness is what allows this process to continue reliably beyond one or two model calls.

Of course, the first agents were not particularly reliable. They tended to hallucinate, lose track of the objective, stop too early, repeat failed actions, or confidently continue in the wrong direction. You probably experienced this yourself.

As a result, two common supervision mechanisms emerged. The first was human in the loop, the approval requests you may recognize from tools such as Claude Code, where the agent asks you before running a destructive command, modifying production data, or performing an action it considers risky.

The second was human guidance around more subjective decisions: the model might understand the technical task but remain uncertain about product intent, style, architecture, or priorities.

Human supervision made agents safer, but it also created a bottleneck. If the agent asks you a question every few minutes, it is not really autonomous, it is simply a faster interface through which you are still operating the system yourself. Harness Engineering is intended to push that boundary further.

What Is Harness Engineering?

The way I define it, a harness is the system around the model that allows the model's intelligence to become operational. One useful formula is:

The model provides reasoning and generation capabilities, and the harness provides the environment in which those capabilities can be used reliably. More specifically, the harness is the operational layer surrounding the model. It gives the model instructions, access to systems, execution capabilities, state, constraints, feedback, and a way to determine whether the work has succeeded.

A raw model can generate text. It cannot independently maintain durable state, execute code safely, access current information, observe the consequences of its actions, or prove that a task has been completed. Those are harness capabilities, and they are why I treat Harness Engineering as a systems discipline — closer to platform engineering than to prompting. Its role is to create an environment in which the model can repeatedly move through a loop:

The goal is straightforward: you want to increase the amount of useful work the agent can complete before it needs to ask you for help.

From a Graph to a Loop

The most important architectural change, in my opinion, is the transition from a predefined graph to a controlled loop. In a graph-oriented architecture, you attempt to predict the possible states of the process in advance. A typical graph might move from request analysis to information retrieval, tool selection, execution, result review, and finally response generation. This works well when the workflow is known and relatively stable: you know the possible steps, you understand the transitions, and you want tight control over the process.

But many advanced tasks cannot be modeled completely in advance. Imagine that you ask an agent to investigate and fix a production issue. The agent may begin with an alert, inspect the logs, form a hypothesis, examine the code, and attempt to reproduce the problem. Then it discovers that its original hypothesis was wrong. It collects more evidence, inspects another service, changes the implementation, runs the tests, encounters a new failure, repairs the solution, launches the application, verifies the behavior, and finally prepares a pull request. You get the deal — you cannot always know in advance how many steps will be required, which tools will be used, or how many times the agent will need to return to a previous stage.

A graph tries to define the journey. A harness defines the playground, the rules, the available instruments, and the conditions that determine whether the task is complete. Inside the harness, the model moves through the problem in rounds: during each round, it examines the current state, selects an action, observes the result, and decides whether to continue.

I design the agent's freedom within the edges of the environment I create for it, and I define those edges with specific tools, permissions, controls, and completion criteria. This is exactly why the word harness works so well. With harnesses, instead of trying to remove the model's freedom completely, you actually try to channel that freedom toward a useful and verifiable outcome.

Verifiability Determines Autonomy

Another idea that I think is essential is verifiability. Whether an agent can solve a problem autonomously often depends less on whether it can generate an answer and more on whether you can determine that the answer is correct. As models become reasonably capable at coding, document analysis, research, financial modeling, and operational planning, the main barrier to autonomy begins to move.

The question is no longer only:

The more important question becomes:

Let me give you a simple example. Suppose you ask an agent to change a button from blue to green. This task is highly verifiable: the agent can modify the code, launch the application, inspect the page, and compare the rendered result with the original requirement. Now suppose you ask it to redesign the application so that it “feels more premium.” The model can certainly generate something — but how does the harness determine whether the result is correct?

The first task gives the agent a clear gradient. It can observe whether it is moving closer to or further away from the desired result. The second task depends heavily on subjective human judgment.

I still put agents on subjective problems — I simply accept that their autonomy scales with how much of that subjectivity I convert into observable criteria. For example, I would translate “make it feel more premium” into approved design-system rules, spacing requirements, accessibility checks, visual references, automated evaluations, and a final designer approval. The more clearly I can define success, the longer the agent can continue without asking me what to do.

This leads to one of the most useful architectural principles I have found:

I therefore expect a harness to do two jobs: produce the output, and prove that the output is acceptable. The second job is the one that buys autonomy.

Additional Components of a Harness

The loop and the verification signal are the core of Harness Engineering. Around them I build everything that keeps the loop honest: the task specification, navigable context, durable state, tools and execution environments, permissions, observability, and architectural controls.

Where a graph enumerates steps, my task specification defines success: the target, constraints, expected artifacts, and stopping conditions. The agent finds the route.

Long-running tasks also require durable state. I keep plans, decisions, failed attempts, completed work, test results, and unresolved questions in files, task objects, databases, commits, or another persistent layer that the agent can reload when required — the context window is working memory, not storage.

Tools and execution environments determine what the agent can actually do. A useful harness gives the model access to the systems required for the task, while isolating execution through sandboxes, containers, permissions, credentials, and approval boundaries. In other words, my job is to give the intelligence somewhere safe and useful to operate.

Keeping Agents on Track

For a long time, one of the main challenges I saw with agents was simply keeping them on track. They understood the task, started correctly, and then slowly drifted into another problem. A harness should therefore guide the agent before it acts and evaluate the result after it acts.

Instructions, skills, templates, examples, and architectural principles reduce the probability of mistakes before execution begins. Tests, linters, security checks, runtime signals, and model-based reviewers allow the agent to detect and repair mistakes after they happen.

I find it useful to think about these as two separate types of control. The first type tells the agent what good work should look like, and the second type tells the agent whether the work it produced is actually good. Together, these controls turn the model from a one-shot generator into a system capable of self-correction.

Understanding and Communicating Agent Actions

At TensorOps, I previously wrote about why logging every request between the LLM and the agent is not the same as agent observability. I think this distinction is becoming even more important. Effective observability needs to connect all the components of the harness: when a run fails, you should be able to determine whether the cause was the model, missing context, an unreliable tool, an unclear instruction, an incorrect permission, or a weak verification mechanism.

Without this visibility, every failure looks like a model failure. Then the natural reaction is to rewrite the prompt or move to a stronger model, even when the actual problem is somewhere else. A larger model will not fix a missing database permission. A better prompt will not fix an unreliable tool. A larger context window will not help if the system has no meaningful completion test.

You need to observe the entire execution process, not only the requests sent to the model. That includes what context was retrieved, which tools were selected, how state changed, which permissions were applied, which tests ran, why the agent continued, and why it eventually stopped.

Finally, I believe that a good harness must improve over time. Repeated failures should become new instructions, tools, tests, policies, or architectural controls. If I find myself correcting the same mistake ten times, that correction belongs in the environment, where every future run inherits it.

Perhaps the model needs a better instruction. Perhaps it needs a new tool. Perhaps the tool already exists but is badly described. Perhaps a rule currently lives in documentation but should become a linter. Perhaps the system lacks the test required to identify the failure.

This is where Harness Engineering becomes an actual engineering discipline rather than another prompting technique. The goal is compounding: I design the environment so that every run, successful or not, improves the next one.