Harness, loop and graph: three layers of an AI agent

Three words are everywhere in talk about AI agents: harness, loop and graph. People treat them as rival ideas. They are not. They are three questions about the same system. Many stalled agent projects answered the wrong question.

Key points in 30 seconds

• Harness: everything around the model. Its tools, memory, context and limits.
• Loop: the cycle the agent repeats. It acts, checks, adjusts, and stops when a check passes.
• Graph: the named steps and the allowed paths between them.
• Use a loop when you cannot know the steps in advance. Use a graph when you can.
• Most real systems are graphs where each step runs a small loop.
• When an agent fails, the model is rarely the cause. Find the broken layer first.

Google Cloud's explainer, Graph Engineering 101, says it simply. The harness is everything around the model. The loop is the cycle the agent runs inside it. The graph is the organisation chart: the named steps and the allowed paths between them.

What are the three layers?

Every agent already answers all three questions. The only choice is whether someone decided the answers on purpose or by accident. Tap each layer to see what it covers.

The figure below shows how they fit. Each layer wraps the one inside it.

What is the harness?

A language model only produces text. It cannot open a file, run your tests, call your billing system or remember last Tuesday. The harness sits between the model and the real world. It turns the model's text into actions, and turns the results back into text.

A simple test: delete the model from your architecture diagram. What is left is the harness.

Give two teams the same model. One team has clean tools, a stable setup and real logs. The other has a flaky API wrapper and vague instructions. The results will not be close. The model was never the difference.

Anthropic's research on long-running agents shows this well. An agent that works across many sessions starts each one with no memory of the last. It is like shift workers who never hand over. A summary of the old conversation was not enough. What worked was harness design:

• A first-run agent writes an init.sh script, a feature list with a pass/fail flag on each item, and a progress file.
• Every later session reads the git log and those files first.
• It does exactly one feature, verifies it, and commits.

This is not clever prompting. It is filing. When a long-running agent keeps forgetting, the fix is rarely a bigger context window. It is more files, and a habit of reading them.

What is the loop?

Every tool-using agent runs a loop. It calls a tool, sees the result, and decides again. Loop engineering means you design this cycle on purpose, instead of accepting the framework default.

The most important choice is the stopping condition. Teams often get it wrong. "Keep refining until it looks right" is not a stopping condition. It just burns budget. A real loop ends on evidence: the tests pass, the format is valid, or a check outside the model's own opinion says yes.

Loops differ in how much a human watches (see the loop types in the first visual). The less a human watches, the more the harness controls matter. A goal-based loop with no step limit is the most common way we see teams find their AI budget by running out of it. We cover the limits that work in what a sane agent spend cap actually looks like. In short: a dollar cap only trips after the money is gone. A step limit stops the loop while it is still running.

What is the graph?

The graph question is about permission, not action. What is allowed to happen next?

• Nodes are steps. A node can be an agent or plain code, such as a database query or a check.
• Edges are the allowed moves: in sequence, branching, in parallel, joining, repeating, or pausing for a human.

Google's example is a pull request review (a team member's code change waiting for approval). Most teams know this shape already:

1. Fan-out: several checks run at the same time.
2. Join: wait for the slowest check, then combine the results.
3. Router: if checks fail, go to a fixer agent. If they pass, go to human approval.

Writing it down tells you which steps can run together, which step waits for which, where the human sits, and where it broke when it breaks. That is the case for graphs: predictability, easy debugging and control, for work whose shape you can define in advance.

A warning about the word. Graph engineering is not a knowledge graph. A knowledge graph is about data: what you know and how things relate. Graph engineering is about behaviour: what runs, in what order, and what happens next.

Loop or graph: who decides the path?

The real difference is not complexity. It is who has authority.

• Loop: you set the goal and the agent picks the route. Use it when the route cannot be known, such as investigating an incident or exploring unfamiliar code.
• Graph: you pick the route and the agent works inside it. Use it when the process is known, steps can run in parallel, steps need different permissions, or someone must sign off.

In practice it is rarely either-or. A loop is a graph with one node that points back at itself. Real systems are graphs whose nodes each run a small loop. The graph gives the guarantees. The loops give the flexibility. Try your own case below.

A fourth pattern is the agent swarm. Several agents get their own roles, and you give them the problem without a defined path. It handles unclear problems well, but it gives up most of your predictability. If you already know the workflow, you pay that price for nothing.

Which layer is broken?

When an agent misbehaves, most teams change the model or the prompt. These are the two knobs everyone knows. Usually neither is the problem. The symptom points to the layer.

• Harness problem: it cannot do an action at all; it cannot resume after a crash or new session; it repeats finished work; it does not know the state of things; or you cannot see afterwards what it did. The cause is missing tools, memory or logs.
• Loop problem: it repeats the same failure; it stops early and claims success; it never stops; or its cost swings widely between runs of the same task. The cause is a missing or dishonest stopping condition.
• Graph problem: one agent holds a long multi-step process in its head; independent work waits behind unrelated work; you cannot say where a failure happened; or human approval happens by habit, not by design. The cause is a control flow nobody wrote down.

Fix them in the order of the layers: environment, then feedback, then flow. Do not tune a loop that runs in a harness with no memory. Do not draw a forty-node graph before you know one node can finish one task reliably.

That is the order for debugging an agent you already have. When you design a business that runs on agents, the order flips: map the work first, then the loops, then the harness, then the context and instructions. We explain this five-layer order in graph, loop, harness, context, prompt: the order that makes AI stick. Design from the top. Debug from the bottom.

Why does this matter for review and control?

We have argued that the bottleneck moved to review. AI made writing code cheap. It did not make reading code cheap. These three layers are where that idea becomes something you can build:

• The loop's stopping condition is a test that really runs.
• The harness's controls are the step limit, the scoped credential and the audit log.
• The graph's router is where a named person approves work before production, by design.

Said the other way: no explicit harness means no audit trail. No explicit loop condition means no cost ceiling. No explicit graph means no place for a human. These are the three most common reasons an agent pilot never reaches production.

What should you do in the first two weeks?

If you have an agent that half works, go in this order. It is deliberately plain.

None of this needs a new framework or a bigger model. All five steps are decisions about the system around the model. That is where reliability lives.

Working with us

The words are new. The engineering is not: it is control flow, state and permissions, applied to a part that is not predictable. This is good news for a small team, because your engineers already have most of the skills.

What is new is judgment: which decisions go to a loop, which to a graph, and what the harness must guarantee before either touches your production data. That is a large part of a Forward Deployed CTO engagement. It fits inside the wider lifecycle in the AI-native SDLC playbook.

To see where your agents sit across the three layers, start with the AI Readiness Scorecard, or talk to us directly.