Contents9 sections
Harness, Loop, and Graph at a Glance
This practical guide separates three architecture layers that are often mixed together.
The confusion is understandable. All three ideas sit around the same model, all three influence reliability, and all three may contain loops. They are not synonyms: each one describes a different engineering decision, and the distinction matters once an agent starts touching files, APIs, customers, or production code.
THE 30-SECOND ANSWER
-
Harness engineering builds the machinery around the model.
-
Loop engineering designs the repeated work-and-feedback cycle.
-
Graph engineering makes the workflow topology explicit: nodes, branches, joins, state transitions, and controlled cycles.
The clean mental model is environment → feedback → flow.
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ H: HARNESS │--> │ L: LOOP │--> │ G: GRAPH │
└──────────────────┘ └──────────────────┘ └──────────────────┘
Environment Feedback Flow-
H — Builds the environment: tools, memory, permissions, runtime, APIs, and filesystem.
-
L — Improves the work through think, act, check, feedback, and repeat.
-
G — Controls the workflow with nodes, branches, joins, parallelism, and state.
Three different layers have three different jobs; confusing them hides the design decision.
Why These Terms Matter Now
A raw language model cannot create files, maintain project state, run a test suite, inspect a browser, enforce an approval rule, or restart a failed job by itself. Those capabilities come from its environment. As agentic software matures, a recognizable engineering stack is emerging: the harness runs the model, loops manage repeated execution and quality checks, and graphs define structured paths through the process.
The labels are not fully standardized. In the source's framing, agent harness has acquired a relatively specific meaning, loop engineering is newer practitioner terminology, and graph engineering is a practical name for expressing agent workflows as directed graphs or state machines. The distinction is useful because it keeps a fashionable label from hiding the architecture decision that actually needs attention.
| Question | Agent harness | Loop engineering | Graph engineering |
|---|---|---|---|
| Primary concern | Operational capability | Iterative progress and feedback | Explicit control flow |
| Core object | Model wrapper or runtime | A bounded, repeatable cycle | A directed graph of steps |
| Typical building blocks | Tools, memory, sandbox, middleware, permissions, traces | Trigger, goal, action, evidence, feedback, stop rule | Nodes, edges, shared state, branches, joins, interrupts, cycles |
| Failure it fixes | “The model cannot safely do the work.” | “The agent stops too early or repeats weak work.” | “The workflow is hard to reason about or control.” |
| Best fit | General agent platform or task-specific runtime | Open-ended work that improves through verification | Complex multi-step processes with known decision points |
| Main risk | A bloated, opaque runtime | Infinite retries, token burn, reward hacking | Over-engineered diagrams and brittle paths |
Agent Harness Engineering
-
LangChain describes an agent as the model plus the harness. The harness is the code, configuration, and execution logic outside the model: system prompts, tool definitions, memory, filesystems, sandboxes, model routing, handoffs, middleware hooks, compaction, permissions, logging, and verification interfaces.
-
OpenAI's Agents SDK describes the same operational core from a runtime perspective: a runner invokes the model, executes tool calls, handles handoffs, carries state, and stops when the run reaches a terminal condition.
┌─────────────────┐
│ O: ORCHESTRATOR │
└────────┬────────┘
┌────────────────┴────────────────┐
▼ ▼
┌────────────────┐ ┌────────────────┐
│ 1: PLANNING │ │ 2: BACKENDS │
└───────┬────────┘ └───────┬────────┘
▼ ▼
┌────────────────┐ ┌────────────────┐
│ 3: CONTEXT │ │ 4: SUBAGENTS │
└───────┬────────┘ └───────┬────────┘
▼ ▼
┌────────────────┐ ┌────────────────┐
│ 5: MEMORY │ │ 6: SKILLS │
└───────┬────────┘ └───────┬────────┘
▼ ▼
┌────────────────┐ ┌────────────────┐
│ 7: SANDBOXES │ │ 8: HUMAN GATE │
└───────┬────────┘ └───────┬────────┘
└────────────────┬────────────────┘
▼
┌────────────────┐
│ 9: TOOLS │
└───────┬────────┘
▼
┌────────────────┐
│ LLM │
└────────────────┘-
O — Orchestrator agent: plans, delegates, and validates.
-
1 — Planning: write_todos and task decomposition.
-
2 — Backends + filesystem: state, local, store, and composite.
-
3 — Context engineering: compression, isolation, and offloading.
-
4 — Subagents: isolated context, parallel execution, and async work.
-
5 — Memory: short-term task state plus long-term persistence.
-
6 — Skills: reusable workflows, including agentskills.io.
-
7 — Sandboxes: isolated execution such as Modal and Daytona.
-
8 — Human-in-the-loop: approve, edit, or reject per tool.
-
9 — Tools: custom functions, MCP servers, and built-in harness tools.
-
LLM — Any tool-calling model.
The word harness shifts attention away from model worship. Two teams can use the same foundation model and get very different outcomes because one gives the model clean tools, a stable workspace, constrained permissions, and observable state while the other provides a vague prompt and an unreliable API wrapper. The intelligence may be similar; the working conditions are not. A serious harness usually contains:
-
Context injection: instructions, retrieved facts, conversation state, skills, and task-specific policies.
-
Action surfaces: APIs, browsers, shells, code interpreters, databases, and MCP-compatible tools.
-
Persistence: files, checkpoints, sessions, progress logs, Git history, and long-term memory.
-
Execution control: timeouts, retries, budgets, model routing, subagent spawning, and approval gates.
-
Safety and governance: permissions, isolation, allowlists, secret handling, and human authorization.
-
Observability: traces, tool inputs and outputs, state transitions, cost, latency, and evaluation results.
┌──────────────────────────── HARNESS ────────────────────────────┐
│ ┌───────────┐ │
│ │ CONTEXT │ │
│ └─────┬─────┘ │
│ ▼ │
│ ┌──────────┐ ┌─────────────┐ ┌──────────┐ │
│ │ CONTROL │ ───────> │ MODEL │ ───────> │ ACTION │ │
│ └──────────┘ └──────┬──────┘ < - - - └──────────┘ │
│ ┌────┴─────┐ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ PERSIST │ │ OBSERVE │ │
│ └────┬─────┘ └────┬─────┘ │
│ └ - - - ▲ - - ┘ │
└──────────────────────────────────────────────────────────────────┘-
CONTEXT — Prompts, memory, skills, and conversation flow into the model.
-
CONTROL — Compaction, orchestration, and Ralph loops constrain the model.
-
ACTION — Bash calls, tools, and MCPs receive decisions and return results.
-
PERSIST — The model writes to and reads from the filesystem, Git, and progress files.
-
OBSERVE — Browser screenshots, test results, and logs return verification evidence.
The model sits inside a wider harness of context, control, action, persistence, and verification. Remove the model from an architecture diagram and most of what remains is probably part of the harness: tools, data access, state stores, sandboxes, middleware, evaluators, retry policy, and UI.
Where harness engineering earns its keep
Harness work is especially important for long-running tasks. The source points to Anthropic's multi-session coding work and argues that context compaction alone is insufficient. A more durable setup uses an initializer, a progress file, Git history, and incremental work practices so each new session can recover what happened and what remains. Apply harness engineering when an agent lacks a capability, cannot resume cleanly, loses state, has excessive access, cannot be audited, or behaves differently across environments.
Loop Engineering
Every tool-using agent contains a small loop:
-
Call the model.
-
Inspect the result.
-
Run the tools.
-
Feed observations back into the model.
-
Repeat until the system returns a final answer.
Loop engineering begins when builders deliberately design or stack additional cycles around that behavior. A verification loop lets the agent create an artifact, run a deterministic check or grader, receive explicit feedback, and retry only when the evidence fails. An event-driven loop wakes the agent on a schedule, webhook, or new document. An improvement loop analyzes traces and failures, changes instructions or tools, and tests whether the new version performs better. LangChain's 2026 framing describes a stack of loops, not one magical while statement.
The anatomy of a well-engineered loop
-
Trigger: what starts another cycle, such as a user request, schedule, failed test, new data, or evaluator feedback.
-
Goal: a specific state to reach, not a vague instruction to “keep improving.”
-
State and memory: what the next cycle needs without replaying everything.
-
Action policy: what the agent may change, call, delegate, or spend.
-
Evidence: tests, schema validation, citations, diffs, metrics, or human review.
-
Feedback: a compact, actionable account of why the evidence failed.
-
Stopping rule: success, budget limit, timeout, irrecoverable error, or human escalation.
┌────────────── AGENT LOOP ──────────────┐
[REQ] ─────────> │ [MODEL] ──── action ────> [TOOLS] │
│ ▲ <─── observation ──────┘ │
│ │ │
│ ▼ │
│ [PR] │
└────┬───────────────────────────────────┘
▼
[GRADER] ───── pass ─────> [DONE]
│
└──── feedback ──────> [MODEL]-
REQ — Documentation improvement request.
-
MODEL — Plans and drafts the changes.
-
TOOLS — Sandbox tools clone, read, and write; action goes out and observation returns.
-
PR — Pull request containing the diff and description.
-
GRADER — Checks that links resolve and CI passes.
-
DONE — Pass ends the job; failure sends feedback back to MODEL.
Why loop engineering is not just prompt engineering
A prompt tells the model what to do during one call. A loop specifies what the system does after the call.
It defines how the system observes results, chooses feedback, decides whether to continue, persists progress, and terminates.
Prompt quality still matters, but a loop converts a one-shot instruction into a managed process. The main tradeoff is cost and latency: every grader, reviewer, or retry adds another model call or tool run. Anthropic's broader guidance is to prefer the simplest architecture that works and add agentic complexity only when the performance gain justifies it. Add a loop where the cost of failure is higher than the cost of verification.
Graph Engineering
Graph engineering asks a different question: not only what the agent does, but which component may run next. Steps become nodes and permitted transitions become edges. Edges can represent sequence, conditional branches, parallel fan-out, joins, loops, and human interrupts. State moves through the graph, making the intended control flow inspectable. LangGraph presents low-level orchestration infrastructure for long-running, stateful agents, including durable execution and human-in-the-loop control. AutoGen's GraphFlow documentation uses an execution graph to control the order in which agents run. Graph engineers decide:
-
Node boundaries: which work belongs in a deterministic function, an LLM call, a specialist agent, or a human review step.
-
State schema: what each node may read or update and how parallel updates are merged.
-
Routing conditions: which evidence sends work forward, backward, sideways, or to escalation.
-
Concurrency: what can run in parallel, what must join, and which shared resources need coordination.
-
Cycles and exits: where retries are legal, how many are allowed, and what makes the cycle safe.
-
Durability: where checkpoints occur and how execution resumes after interruption.
A workflow canvas can make agents, skills, and relationships inspectable as a composed system. Graph engineering here means engineering graph-based execution, not knowledge-graph engineering. A knowledge graph represents entities and relationships in data; a workflow graph represents control and state transitions.
When a graph is worth the ceremony
Graphs are valuable when a process has meaningful branches, parallel work, approvals, recovery paths, or multiple specialist agents. They are less useful when the job is simply “give one agent three tools and let it work.” A graph can improve debugging, but it can also freeze assumptions too early. If the model must invent the plan dynamically, forcing every possible path into a diagram can make the system more brittle.
How the three layers work together in one real system
Consider a research-and-publishing agent responsible for producing a factual industry briefing.
| Layer | Responsibility in the research-and-publishing system |
|---|---|
| Harness | Provides the browser, search tools, document workspace, citation store, model routing, secrets, permissions, trace logging, and approval interface. |
| Graph | Routes the job through scoping → parallel research → source screening → synthesis → drafting → legal review → publication, with a human gate before release. |
| Loops | Repeats source retrieval when coverage is weak, returns the draft for correction when citations fail, and runs scheduled refreshes when the market changes. |
The graph runs inside the harness; one or more loops live inside the graph; and the harness supplies the state, tools, and evaluators those loops need. The categories overlap because software layers overlap, but each gives the team a different lever to pull when the system fails.
Choose the engineering layer by diagnosing the failure
| Symptom | Start with | Likely fix |
|---|---|---|
| The agent cannot access the right data or tool safely. | Harness | Tool contract, permissions, sandbox, context injection. |
| The agent forgets progress across sessions. | Harness | Durable state, checkpointing, progress artifacts, compaction. |
| The first attempt is often close but unreliable. | Loop | External grader, deterministic tests, feedback, bounded retry. |
| The agent keeps working after success or stops before proof. | Loop | Evidence-based terminal states and budget-aware stop rules. |
| Several specialists must run in a controlled order. | Graph | Explicit nodes, edges, routing conditions, and joins. |
| Failures are hard to locate in a multi-step process. | Graph + harness | Stateful traces aligned with graph nodes and transitions. |
| The workflow changes too often for a fixed diagram. | Simpler harness | Keep control model-driven and delay graph formalization. |
Costly Mistakes in Weak Agent Architectures
Building a graph before understanding the work
Teams sometimes translate a business process into dozens of nodes before observing how a capable agent actually solves it. Start with traces from a simpler harness, then formalize the stable paths.
Letting the same model write and grade without safeguards
Self-review can help, but it is vulnerable to shared blind spots. Prefer deterministic checks where possible, separate reviewer context, and require human approval for high-impact actions.
Using “keep trying” as a loop specification
An unbounded retry loop leaks cost. Every loop needs a measurable objective, fresh evidence, a maximum number of attempts, and a named escalation path.
Treating the harness as a dumping ground
More tools and memory are not automatically better. A crowded toolset raises selection errors, noisy context raises confusion, and broad permissions raise risk.
Blaming the model for orchestration failures
A model cannot reliably compensate for stale state, ambiguous tool schemas, broken APIs, or missing exit conditions. Improve the layer that owns the failure.
Production-Ready Design Checklist
-
Harness: Are tools narrow, documented, and observable? Is state durable? Are permissions least-privilege? Can operators pause, inspect, and resume a run?
-
Loop: What evidence proves success? What feedback is returned on failure? How many retries are allowed? What happens when the budget is exhausted?
-
Graph: Which paths must be deterministic? Where can work run in parallel? Which state is shared? Where are the human gates and recovery routes?
-
Evaluation: Can the team replay real traces, compare versions, and attribute improvement to a specific change rather than intuition?
-
Operations: Are cost, latency, failure rate, intervention rate, and task-level success monitored in production?
The Simplest Way to Remember the Difference
Harness engineering gives the model an environment in which it can operate. Loop engineering makes the work iterative, verifiable, and resumable. Graph engineering makes complex execution paths explicit and controllable. None of the three replaces the others. A well-drawn graph cannot recover state that the harness failed to preserve. A capable harness without evidence or stopping rules can waste time and money. Carefully designed loops remain hard to operate when branches, parallelism, and approvals are buried in ad hoc code. Reliable agent systems emerge when teams design all three layers together and know which failure each layer is meant to solve.
Sources and Further Reading
Five cross-check sources used in this guide
-
The Anatomy of an Agent Harness — Defines the harness around a model and surveys filesystems, sandboxes, memory, orchestration, and verification.
-
Agents SDK | OpenAI API — Documents the SDK's agents, runners, tools, handoffs, guardrails, sessions, tracing, and results.
-
GraphFlow (Workflows) — AutoGen — Documents structured multi-agent execution graphs, ordering, branching, and cycles.
-
The Art of Loop Engineering — Describes the core agent loop and the practice of stacking additional loops around it.
-
Building Effective AI Agents — Recommends starting with the simplest workable architecture and adding complexity only when it produces measurable value.
REFERENCES