Harness, loop, graph: three agent problems that need three different fixes

Three phrases have been doing the rounds: harness engineering, loop engineering, graph engineering. They turn up in the same sentences, usually as synonyms, usually by people who are each describing something real and slightly different. A framing posted by beamnxw on X finally pulled them apart for me, and the separation is worth having, because the three terms name three different fixes for three different failures.

Shortest version I can give you: the harness is the environment, the loop is the feedback cycle, the graph is the flow. All three sit around the same model. All three can contain something that looks like a loop. All three decide whether the thing works on a Tuesday. They are still not the same decision, and the whole value of the vocabulary is being able to say which one you are currently getting wrong.

Harness: what the model can touch

A model on its own cannot read your repo, run your test suite, look at a browser, remember yesterday, or ask a human for approval. Every one of those is a capability the environment lends it. The harness is that environment: the system prompt and the house rules, the tool definitions, the memory and the filesystem, the sandbox, the permission model, the hooks that fire whether or not the model remembers them, and the traces that let you work out afterwards what actually happened.

I have written a whole post on building one, so I will not relitigate it here. The one-line test is this: if the agent failed because it could not see something or could not do something, that is a harness problem. No amount of prompt wrangling conjures a missing tool.

The classic harness mistake is the junk drawer — forty tools bolted on because each looked useful in isolation. Selection errors go up, reliability goes down, and the model burns its attention choosing rather than working. A harness is a set of deliberate affordances, not an inventory.

Loop: what happens after the call

A prompt tells the model what to do during a call. A loop decides what the system does after it.

That is the distinction most people skate past. Prompting is a single-turn concern. Looping is about the cycle: the agent acts, the world answers back, and something has to decide whether to continue, change approach, roll back to an earlier state, call for help or stop. In practice that decision is where most of an agent's apparent intelligence lives, and it is yours to design, not the model's.

A loop that survives contact with production has a small number of named parts: a trigger, a goal specific enough to be checked by something other than the model, the state the next pass needs, a policy for what the agent is allowed to do, evidence that the goal was met, compact feedback when it was not, and a stop rule. The stop rule is the part everyone skips, and it is the part that turns up on the invoice.

const result = await runUntil({
  // Checkable by something that is not the agent.
  goal: () => suite.passing && contract.validates(output),
  act: (feedback) => agent.run(task, feedback),
  // Every exit is real. "The agent said it was done" is not one of them.
  limits: { attempts: 4, seconds: 600, usd: 2 },
  onExhausted: (trace) => escalateToHuman(trace),
});

Graph: what is allowed to happen next

A harness and a loop still leave the agent free to pick its own route. Sometimes that freedom is the entire point. Sometimes it is a liability, and you want the route written down: these steps, in this order, with this branch, and a human signs here. That is graph engineering — modelling the workflow as an explicit directed graph or state machine, where nodes are steps and edges are the transitions you are prepared to permit.

A node does not have to be a model call. The good graphs mix them: a deterministic function here, a specialist agent there, a human review gate before anything leaves the building, a retry policy per node, and checkpoints so a failure at step six does not mean redoing steps one through five. LangGraph is the best known tool for this, but the discipline matters more than the library — a state machine and a switch statement get you most of the way.

They all contain loops. That is why they get confused.

Here is the knot. A harness has retries. A loop is a cycle by definition. A graph can have a cycle edge. Three different things, all drawn with an arrow that points backwards.

The way out is to ask what the arrow is made of. A harness retry is infrastructure: the call timed out, try it again, nothing about the task has changed. A loop iteration is learning: the attempt produced evidence, and the evidence changes the next attempt. A graph cycle is topology: this node is permitted to hand control back to that one, and the edge exists in the diagram whether or not anybody travels it today.

Diagnose first, build second

This is the practical payoff of keeping the three apart. When an agent misbehaves, the symptom usually tells you which layer is at fault — and working on the wrong layer is exactly how a week disappears.

The order to build them in

1. 1Harness first, always. Until the agent can see the truth and act on it, nothing downstream matters.
2. 2Then the loop, the moment the first attempt stops being reliable. One goal, one evidence check, one stop rule. That is an afternoon's work.
3. 3Graph last, and only once the shape of the work has stopped moving. Branches, specialists, approvals and genuinely parallel paths are the signal. One agent with four tools is not.
4. 4Keep evaluation outside all three. Trace replay, version comparison and a success rate you can plot. Otherwise you are tuning three layers by vibes and calling it architecture.

The punchline

None of this is about the model, which is the uncomfortable bit if you were hoping the next release would sort it out. The differentiator in a production agent is the system around the model, and that system has three distinct parts with three distinct failure modes.

Harness, loop, graph. Environment, feedback, flow. Get into the habit of naming which one you are fixing before you open the editor, and you will stop losing Tuesdays to rewriting a prompt that was never the problem.