30 sec6 min coredeep dive optional
Loop engineering, graph engineering, and harness engineering name the three layers you can actually tune when an agent misbehaves: the loop the model drives turn by turn, the graph that constrains which paths exist, and the harness that keeps the whole thing fed, budgeted, and observable.
- Anthropic’s own split: workflows orchestrate LLMs through predefined code paths, agents let the LLM dynamically direct its own process and tool usage.
- Loop engineering tunes what happens inside one iteration: context gathering, action, verification, retry. It is where most debugging actually happens.
- Graph engineering moves control flow out of the model’s hands and into explicit nodes and edges, which buys auditability and parallelism at the cost of flexibility.
- Harness engineering is everything around the loop: context assembly, memory, permissions, budgets, observability. Production agents are mostly harness.
- Diagnose in order: read one failed trace and ask whether the model saw the context (harness), verified the step (loop), or lacked a valid path (graph), before rewriting anything.
Loop engineering is the newest of three names the agent community keeps reaching for when a build stops working, and the confusion between them is expensive: teams rewrite prompts when the control flow is the problem, or bolt on a graph framework when the loop simply lacks a verification step. Each layer has its own tools, its own failure modes, and its own fix order.
The names come from practitioner writing rather than from a standards body, which is exactly why a plain mapping is useful: once you can point at which layer a failure belongs to, the vendor vocabulary stops mattering and the fix order starts writing itself.
Three layers, one agent
Start from the definition Anthropic published in its Building Effective Agents essay. Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents are systems where LLMs dynamically direct their own processes and tool usage. Both are true at once in every serious deployment, and the three engineering layers map onto the boundary between them.
The loop is the smallest unit: the model takes context, chooses an action, observes the result, and repeats until done. The graph is the shape you impose on many loops: which steps exist, what can follow what, where a human signs off. The harness is everything that lets the loop survive contact with production: context assembly, memory, credentials, budgets, logging, and the gates that refuse bad outcomes. It is also where loop engineering hands off to operations, and the handoff deserves a decision, not an accident.
| Layer | You tune | Tell-tale failure |
|---|---|---|
| Loop | Prompts, tool choices, verification steps, retry rules | The model repeats the same failed action or stops one step short |
| Graph | Nodes, edges, branching, approval and checkpoint placement | Runs are unreproducible, or no one can say which path produced a result |
| Harness | Context assembly, memory, permissions, budgets, observability | Works in demos, dies in week one of production on cost, drift, or access |
Loop engineering: tune the iteration
Loop engineering is the discipline of making one iteration of the agent cycle trustworthy. The canonical cycle is gather context, take one action, verify the result, and either finish or feed the observation back. Every famous agent pattern lives inside it: ReAct interleaves reasoning traces with actions, Reflexion adds the model critiquing its own attempt before the retry, and plan-and-execute splits the loop into a planner turn and worker turns.
The craft of loop engineering is in the verification step, not the action step. An agent that checks its own output against a test, a schema, or a rendered page can recover from most of its own mistakes, and the recovery costs one more iteration instead of one more incident. This is also where the cost lives: every loop turn re-reads context, so verification that runs locally in a script is cheaper than verification that asks the model to look again.
Practical loop engineering starts with reading the trace. When an agent fails, the honest questions are: did it see the relevant context, did it pick a reasonable action, did anything verify the result, and what did it do with the failure. Four yes-or-no questions, one trace, and the offending layer usually names itself within minutes. Most “the model is dumb” reports dissolve into a loop with no verification step at all.
Two loop upgrades pay for themselves almost immediately. The first is a context budget per iteration: cap what the model re-reads each turn so the loop stays affordable at depth ten, not just depth two. The second is an explicit stop condition the model can evaluate, such as “all checks green” or “every source cited,” so finishing is a testable claim rather than a mood. Agents that lack both run either too long or too short, and the traces look identical from the outside, which is what makes them so hard to debug after the fact.
Where did the loop pattern come from, and why does it dominate?
The loop descends from the ReAct pattern (reason and act interleaved, 2022) and earlier agent architectures, and it dominates because it matches how tool use actually behaves: each action produces an observation the model could not have predicted, so the next step genuinely depends on the last result. Pre-scripting those steps as a workflow throws away exactly that adaptivity, which is why Anthropic’s essay frames agents as the choice for open-ended problems and workflows as the choice for predictability.
The loop’s weakness is the mirror of its strength. Because each turn depends on the last, one bad observation can compound: the model misreads a stack trace, “fixes” the wrong file, and now verifies against its own error. That failure mode is the reason verification belongs inside the loop rather than after it, and why Anthropic’s guidance for agentic systems leans on grounding: give the model ways to check reality that do not depend on its own narrative.
A ten-line example shows the shape. A coding agent is asked to add an endpoint. Loop one: it writes the handler. Verification: run the test suite, which fails because the route was never registered. Observation: the failure text goes back into the model’s context. Loop two: it registers the route, the suite passes, and the loop exits with a machine-checked claim instead of a confident one. The verification cost one pytest run, a fraction of a cent. Without it, the same session ends with the bug live and the summary saying done.
Verification comes in three grades, and mature loops mix them. A script check (tests, types, lint) is cheap, deterministic, and blind to intent. A schema check is nearly free and catches malformed output before it propagates. A model check, where a second pass judges whether the output satisfies the request, is the only grade that catches wrong-but-well-formed work, and it costs a turn. The design rule: use the cheapest grade that can catch the failures you actually see in traces, and keep the expensive grade for the finish line rather than every step.
Graph engineering: constrain the paths
Graph engineering moves control flow out of the model and into an explicit structure: nodes are steps, edges are allowed transitions, and the model is consulted inside nodes rather than asked to navigate the whole map. LangGraph made the pattern mainstream with a state machine you can inspect, checkpoint, and resume, and every serious agent platform since has grown an equivalent.
What graph engineering buys is boring in the good way. A run has a path you can print, so “which branch produced this answer” has an answer. Independent nodes run in parallel, which loops cannot offer safely. Checkpoints turn a crash into a resume instead of a restart. Approval gates become nodes a human owns, not a prompt asking the model to please wait. Regulated teams buy graph engineering for the audit trail as much as for the behavior.
What you pay is flexibility. A graph encodes today’s understanding of the task, and the model cannot route around an edge that is missing even when the situation obviously calls for it. Long-horizon open-ended work chafes in graphs; bounded, multi-step, must-be-defensible work is exactly where graph engineering earns its keep. One warning from practice: teams often reach for a graph when the real defect is loop engineering, an iteration with no verification step, and encoding that defect into nodes just makes it permanent. Read the trace before you pick the framework.
There is also a team-size argument. A loop is legible to the person who wrote it and opaque to everyone else. A graph is legible to a reviewer who has never touched the code, because the structure is the documentation. When the second and third engineer join, the graph stops being a framework choice and becomes a communication medium, which is why agencies and platform teams adopt it earlier than solo builders do.
When does a graph beat a loop, concretely?
Three signals say the graph will pay for itself. First, the steps are known in advance and recur, so encoding them once is amortized. Second, steps are independently retryable or parallelizable, like fetching ten sources then merging. Third, someone outside engineering needs to reason about the flow: an auditor, a reviewer, an on-call engineer at 3am.
The hybrid is the industry’s steady state: a graph whose nodes contain loops. One node might be “research: loop until three corroborating sources,” another “implement: loop until tests pass.” Frameworks converged here because pure graphs ossify and pure loops drift. Anthropic’s own workflow patterns, from prompt chaining to the orchestrator-workers pattern, read as named nodes with the loop hidden inside each.
Checkpoints deserve one concrete note because they change incident behavior more than any other graph feature. A checkpointed graph persists its state at every node boundary, so a failure at step seven resumes at step seven with the same state, including the observations the earlier nodes gathered. Uncheckpointed, the rerun re-spends every token from step one and may take a different path, which turns a five-minute recovery into a fifteen-minute investigation. Human approval slots into the same machinery: the graph pauses at the approval node, state persists for as long as the reviewer takes, and the resume is exact rather than reconstructed.
Harness engineering: keep the agent alive
The harness is the layer that decides whether loop engineering and graph engineering survive production. It assembles the context the loop sees each turn, carries memory across turns, holds the credentials with the least privilege that works, enforces budgets, and records what happened. Agent products advertise their models; their harnesses are what users actually experience.
The strongest current argument for taking the harness seriously is empirical. Our own breakdown of Claude Code session traffic put model output at under 2 percent of the total bytes shipped; the rest is harness, the scaffolding that feeds it context and keeps it on target. Whatever your exact number, every team that has moved an agent from demo to production reports the same skew. The harness is where the engineering hours go.
Harness work is unglamorous and specific: deduplicating context so the budget survives a long session, sandboxing tool calls so one bad command cannot take out the host, retry and backoff around flaky tools, and observability that can answer “what did the agent see” after the fact. Teams that skip it rediscover each item as an incident.
Memory deserves its own paragraph because it is where harness engineering and loop engineering touch. A harness that replays the full transcript every turn is running loop engineering with a budget leak; a harness that compresses the transcript is making an editorial decision about what the model believes happened. Summarization, retrieval from a vector store, and structured scratchpads are all harness choices with loop consequences, and they should be owned by one design, not accumulated from three tutorials. When an agent contradicts something it did an hour ago, the bug is almost never the model. It is this boundary, drawn badly.
What belongs in a minimum viable harness?
Five pieces, in the order teams usually feel their absence. Context assembly: a deterministic function that builds each turn’s prompt, so you can improve it without prompt archaeology. Permissioning: an allowlist of tools and paths, checked before execution, not after. Budget: a token and wall-clock ceiling enforced outside the model, because the model cannot be trusted to stop. Verification hooks: the script gates that refuse a finish on failing checks. Logging: full traces with inputs, not just outputs, because debugging a loop without the observations is guesswork.
Everything else, memory systems, planner models, multi-agent crews, is optional. The minimum harness is what turns a demo loop into something a colleague can run unattended, which is the actual production bar.
How do the three layers show up in a tool like Claude Code?
Claude Code is a useful worked example because all three layers are visible in one product. The loop is the turn cycle: the model reads context, edits files, runs commands, and checks results until the task ends, with effort settings and compaction tuning how hard and how long each iteration works. The graph appears in constrained modes: plan mode that must present a plan before touching files, and permission modes that fence which actions are even available, both of which replace open navigation with a fixed set of transitions.
The harness is the part users configure without naming it. CLAUDE.md and rules files are context assembly. Hooks are the verification and gating layer, from PostToolUse formatters to Stop gates that refuse an unfinished finish. Sandboxing, permission prompts, and usage limits are the budget and access controls. When a Claude Code session goes sideways, the same diagnostic order applies: did it see the right context, did anything verify the step, and what was allowed to run.
The mapping is also a shortcut for choosing what to learn next. If you can operate a harness through configuration files and hooks, you can adopt any loop-level pattern, because verification gates accept any check you can script. If you can read a graph definition, you can evaluate agent platforms on their own terms instead of their demos. Vocabulary first, tools second, is the cheaper order.
Which layer do you fix first?
The layers mislead when you fix them out of order: rewriting graphs while loop engineering goes unverified, or tuning prompts while the harness starves the model. Rewriting a graph when the loop lacks verification produces a rigid system that fails the same way, and tuning prompts when the harness starves the model of context produces prompts that blame the model for what it never saw. The diagnostic that holds up in practice: read one failed trace end to end before touching anything. What you find there picks the layer for you, and the fix is usually cheaper than the rewrite you were about to attempt.
The checklist reads harness, loop, graph, harness on purpose. Most first failures are context or verification, and control flow is the rarest culprit, so resist reorganizing the architecture until the cheaper two are clean.
One caution on vocabulary: these three names are community shorthand, not an industry standard, and vendors stretch them toward whatever they sell. The layers themselves are real, whatever you call them. Any agent system has an iteration policy, a control-flow policy, and an operations policy, and confusion between the three is what the vocabulary is for. Use the names as pointers to those policies, and the disagreement about labels stops mattering the moment your next trace names its own layer.
Loop engineering makes each iteration trustworthy, graph engineering makes the path inspectable, and harness engineering makes the whole thing survivable. When a build fails, diagnose in that order: context, iteration, control flow, operations. Most stuck agents need a better verification step, not a new framework. Budget one trace read before any rewrite, and let the trace, not the framework marketing, name the layer at fault.