Harness, Loop, and Graph Engineering:
the 3 layers of a real AI agent

SECTION 01

What changes when the agent leaves the demo

An agent demo is easy to impress with: you give it a prompt, the model responds well, everyone claps. The problem shows up later — when that same agent has to run without you watching, touch real data, and can't just "try again" until it happens to work.

A model, on its own, doesn't know how to keep state across sessions, call a tool safely, validate whether its own output is correct, decide when to stop, or tell a human "I need help here." All of that comes from what gets built around the model.

That "around" tends to turn into a mess of mixed-up concepts. A practical way to organize it is to split it into three layers, each solving a different problem:

Harness engineering
  → builds the environment around the model

Loop engineering
  → designs the repeated action-and-correction cycle

Graph engineering
  → makes the workflow explicit

They all sit around the same model, all affect the agent's reliability, and yes, all of them can contain some kind of repetition. But they solve different problems — and mixing the three up is the most common reason someone ends up debugging the wrong layer when the agent fails.

SECTION 02

Harness engineering: the model's environment

Harness is everything that gives the model the conditions to operate in the real world: tools, memory, execution control, safety, and a way for you to see what it's actually doing.

Without a harness, a model can't:

• keep project state across different sessions;
• safely call a tool (API, browser, shell, database);
• respect permissions and access boundaries;
• retry when something fails, within a time and cost budget;
• be audited afterward — what it saw, what it did, and why.

A solid harness usually covers six fronts:

Context
  instructions, memory, conversation state, policies

Tools
  APIs, browser, shell, databases, MCP

Persistence
  files, checkpoints, history, long-term memory

Execution control
  retries, timeouts, cost budget, approvals

Safety
  least-privilege permissions, isolation, allowlists

Observability
  traces, input/output logs, cost, latency

Two teams using the exact same model end up with very different results. One gives it clean tools, structured memory, clear permissions, and observable execution. The other gives it a vague prompt, messy tools, noisy context, and no way to check what happened. The model is the same — the working conditions aren't.

SECTION 03

Loop engineering: action and evidence cycles

Every tool-using agent already has a minimal built-in loop: call the model, observe the result, run the tool, feed the observation back, repeat until done.

Loop engineering starts when you intentionally design additional cycles around that behavior — not just "ask again," but a real system of work and correction.

Trigger
  what starts a new cycle?

Goal
  what specific condition are we trying to reach?

State
  what does the next cycle need to know?

Action policy
  what is the agent allowed to do?

Evidence
  how do we know it worked?

Stop rule
  when does the cycle end?

The single most important idea in loop engineering fits in one line: don't loop on confidence, loop on evidence. "The agent says it's done" is not a stop condition. A real stop condition looks like: the tests pass, the schema validates, the citations resolve, a reviewer approved it.

A prompt improves a response. A loop improves a process — and that's a very different engineering problem:

• how the system checks the result;
• how it reacts to a failure;
• how it keeps progress across attempts;
• how it decides to continue or stop.

SECTION 04

Graph engineering: the explicit flow

Graph engineering answers a different question than the other two: not "what should the agent do now," but "what is allowed to happen next."

Steps become nodes, transitions become edges, and everything that used to hide inside code full of if statements gets drawn out instead:

Node
  LLM call, deterministic function,
  specialist agent, human review

Edge
  transition, branching, parallelism, join, cycle

The graph defines
  routing, checkpoints, recovery, control

An example: a research-and-publishing agent that needs to scope a topic, gather sources, screen citations, write a draft, pass legal review, and only then publish.

topic scoping
   │
   ▼
research (sources)
   │
   ▼
citation screening
   │
   ▼
synthesis and draft
   │
   ▼
legal review ── rejected ──▶ back to draft
   │
 approved
   │
   ▼
human gate
   │
   ▼
publication

A graph pays off when the process has real branching, approvals, handoffs between specialists, parallel work, or recovery paths. When the job is just "give an agent a few tools and let it work," a solid harness plus a few loops is usually enough — formalizing that into a graph too early only makes the system more brittle.

SECTION 05

How the three layers relate

They aren't interchangeable, but they work together — each one covering a different stage of the same path:

Harness → makes the model operational
Loop    → makes the work iterative and verifiable
Graph   → makes the flow explicit and controllable

In the research-and-publishing example, all three layers show up together, each in a different role:

• Harness provides browser access, search, a file workspace, memory, citation tracking, and the required approvals;
• Loop retries the search when evidence is weak, fixes broken citations, and runs checks before moving forward;
• Graph controls the path — scope, research, screening, synthesis, draft, review, publication — with a human gate before anything goes live.

A perfect graph won't save a weak harness. A strong harness still wastes money without good loops. And clean loops become hard to manage when branching and approval logic stays hidden in ad hoc code instead of being explicit in a graph.

SECTION 06

Which layer the problem is in

Before touching anything, it's worth diagnosing which layer the failure actually lives in:

"The agent can't even operate"
  → fix the harness
  (missing tool access, stale state,
   weak memory, wrong permissions, no observability)

"It almost works, but it's inconsistent"
  → fix the loop
  (first draft is close but weak, success is
   inconsistent, uncontrolled retries, no proof of completion)

"The process itself is complex"
  → fix the graph
  (many specialists, approvals,
   branching logic, parallel paths)

This order also matters as a priority: a beautiful graph won't fix an agent that can't even call the right tool. Start by fixing the harness, then the loop, and only formalize the graph once the process genuinely calls for it.

SECTION 07

Common mistakes

• Drawing the graph too early. Teams often diagram a huge workflow before seeing how the work actually behaves. Better to start with a simpler harness, collect real traces, and only formalize into a graph what genuinely needs control.
• Letting the same model write and grade its own work with no safeguards. Self-review helps, but it shares the same blind spots. Prefer deterministic checks where possible, an external evaluator, or human approval for high-impact actions.
• Using "keep trying" as if it were a loop. That's not loop design, it's an uncontrolled cost leak. Every loop needs a measurable goal, real evidence, a retry limit, and an escalation rule.
• Treating the harness like a junk drawer. More tools doesn't mean a better agent — it means more room for selection mistakes, noisier context, and a wider risk surface. A good harness is lean, not crowded.
• Blaming the model for orchestration failures. A model can't compensate for a broken API, stale state, a missing stop condition, or a poorly described tool schema. The failure belongs to the layer that should have handled it — almost never to the model.

SECTION 08

Practical checklist

HARNESS

• are the tools narrow and well documented?
• is state durable across sessions?
• do permissions follow least privilege?
• can you pause, inspect, and resume execution?
• are traces visible to whoever operates it?

LOOP

• what evidence proves the result is correct?
• what feedback goes back to the agent on failure?
• how many retries are allowed?
• what's the stop rule?
• what happens when the budget runs out?

GRAPH

• which paths need to be deterministic?
• what can run in parallel?
• where are the human gates?
• what state is shared between nodes?
• where do the recovery paths begin?

SECTION 09

Conclusion

What usually gets called "the agent" is actually a three-layer system with very different responsibilities:

Harness engineering:
builds the model's operating conditions.

Loop engineering:
turns the work into iterative, verifiable cycles.

Graph engineering:
makes the decision flow explicit and controllable.

The model is rarely the differentiator in production. What separates a toy prototype from a reliable system is the engineering built around it — and diagnosing the failure in the right layer is what saves you months of debugging the wrong place.