Harness, Loop and Graph: Three Nested Layers of a Coding-Agent System

A coding agent can look as if it's running on its own, when in practice a person sits beside it like a supervisor of a pricey intern: one prompt, one reply, then a manual review of whatever just happened.

Teams trying to leave that mode keep tripping over the same three obstacles. Retry loops burn through the budget without ever checking that the code compiles. Fifty-node graphs get drawn before anyone understands how a single sub-agent behaves. And the usual reaction to both failures is to rewrite the prompt while ignoring the environment the model runs in. All three share one root cause, and it isn't the model.

What follows describes three nested layers of one agent system, shows how a failure symptom points to the layer that needs attention, and outlines the smallest version of each layer worth building before any scaling.

The core of the architecture

Harness, loop and graph aren't rival schools of thought. They're three nested layers of a single system, ordered from the outside in: harness, then graph, then loop, then model.

Every layer owns one task. The harness governs what the agent may touch, retains and sees. The loop governs the moment the agent is permitted to claim completion. The graph governs who works when, serially or concurrently, and how the outputs get merged.

The order pays off immediately, because a production failure points straight at the responsible layer. "Done, but it doesn't work" is a loop problem. "Fine alone, falls apart as a team" is a graph problem. "Forgot yesterday's decision" is a harness problem. Nobody has to guess which file to open first, and nobody tries to solve an architecture issue by swapping the model.

One caveat before any figure appears. Every claim here of the form "a structured stack is N times faster" is an illustrative device, not a measured result. Independent measurement of that kind doesn't exist yet, and an honest gap is more useful than an invented number.

Three layers, one architecture

A company makes a handy comparison. Think of the building and its security rules as the harness, the org chart as the graph, and one employee's daily checklist as the loop, with the model as the employee, limited by all three.

The nesting isn't a matter of taste. The harness is the outer boundary, so no graph node will do what the surrounding environment forbids. The graph coordinates several loops, while each loop is the engine closest to the model, wrapped right around it. The graph is simply a map of who works when and where results meet.

Why does the industry argue over which layer matters most? The reason is plain and structural: vendors each build their brand around one layer. Some publish about environments, some about graphs, and independent practitioners turned loop engineering into a movement of its own. A reader meets one noun per channel and concludes there's a contest.

The more interesting fact is that the same symptom can come from two different layers. An agent that "isn't doing anything sensible" might be stuck in a loop with no stop condition, or might sit in an environment where the tests can't even run. That's why each layer gets its own section, starting with the outermost.

The harness layer: what the model is given

On its own, a model has no memory, no tools and no boundaries. Everything that supplies them is the harness. Harness engineering, the discipline of designing that environment, can shift the same model's output more than any prompt tweak, and a figure for that appears a few paragraphs down.

The formula is short: agent equals model plus harness. If the model is the engine, the harness is the whole car, with chassis, fuel system and sensors. A fine engine without a car goes nowhere. It's easy to treat this layer as plumbing instead of architecture, and that has been one of the costliest mistakes in how people think about agents.

Seven files, not a framework

Seven files make up a minimal production harness: instructions for the repository, a permissions file, a pair of lifecycle hooks, and three bits of persistent state, namely a progress log, a cache of tool results and a log of git checkpoints. No orchestration library is involved.

Teams often confuse two things that should be kept apart. Permissions ask before a tool runs, which is an application-layer control. A sandbox blocks at the kernel level, so the process can't cross the boundary whatever the model requests. The difference between being asked and being unable is the difference between a request and a contract.

State hashing completes the set. Instead of relying on what the agent remembers, you keep receipts: results of tool calls and commit checksums get appended to a durable log, which lets a new context window pick up from facts rather than from a summary that lost detail. This is one author's way of making state persistent and not an established industry pattern, since other teams get there with commits and progress files.

A single figure deserves a warning about where it came from. The comparison put several agents on one model and ran them over part of SWE-bench Verified, and it was published by the creator of one of the compared tools rather than a neutral lab. It found cost differing by about three times at similar or better success, caused only by the context and environment layer. Read it as a vendor claim, not independent evidence.

The environment alone doesn't determine when an agent stops working. That's the next layer's responsibility.

The loop layer: proof, not confidence

Loop engineering is the design of the stop condition itself, and its first rule is brief: an agent's declaration that it's finished isn't proof. The loop may not end before an outside, deterministic check has passed, for example a test, a linter or a schema validator.

Cruise control is the right image, not a pledge. Cars adjust speed against the speedometer, never against the driver's say-so. So the agent can't pronounce itself done; a machine check has to.

One study makes the rule non-negotiable. Researchers from a lab and a university showed that models struggle to correct themselves without external feedback, and that performance after such self-correction can end up worse than before. How sure a model sounds and whether it is right are separate signals, and they line up less often than builders expect.

Binding proof to a commit

What follows is a deliberately simplified sketch, not production code. Evidence that the tests passed is linked to the precise commit checksum it came from, and evidence left over from an earlier revision is automatically refused.

A proof gate alone isn't enough. A hard cap on iterations and budget, together with a no-progress detector, are its inseparable partners. Without them an evidence-gated loop can still run up a huge bill. One reported incident involved four unbudgeted LangChain agents looping for eleven days, with a bill in the region of forty-seven thousand dollars, and nobody noticing for over a week. That story is known only from secondary accounts and the company hasn't confirmed it, though every independently found source agrees. A kill switch works like a fuse, cutting the loop whatever the model insists.

Loops have another failure mode. Agents get caught gaming tests instead of solving the underlying problem. One vendor's system card reported a drop of about two-thirds in this behaviour between model generations. A drop, not zero, a distinction that returns twice more below.

The loop settles when the work ends. Deciding who does the work in the first place, once there's more than one task, belongs to the third layer.

The graph layer: when multiple agents are warranted

Graph engineering shapes control flow and concurrency among several agents. It is not a philosophical stance: whether it helps or hurts depends on a single factor, namely whether the work divides into independent parts.

In 2025 two strong positions collided on this. A large lab described a lead-plus-sub-agents pattern that beat a lone agent by about 90 percent on the lab's own tests of wide-ranging research tasks, paid for with extra tokens. The vendor estimated that a single agent uses about four times the tokens of a normal chat, and the multi-agent setup about fifteen times that baseline, so the real multiplier of multi-agent over single-agent is closer to three or four than to fifteen. Walden Yan of Cognition argued the opposite for tightly coupled coding work: splitting it across agents without shared context produces brittle systems and conflicting assumptions, in his June 2025 post "Don't Build Multi-Agents".

These weren't identical conditions producing opposite outcomes. They were two different kinds of task, and each side generalised from the one that favoured its conclusion.

The divisibility threshold

The resolution can be quantified. A December 2025 paper, "Towards a Science of Scaling Agent Systems" (Kim et al., from Google Research, Google DeepMind and MIT), measured what it calls a divisibility threshold. Centralised coordination improved parallelisable tasks by roughly 81 percent and degraded tasks needing sequential reasoning by 39 to 70 percent, and the benefit faded once a single agent's success rate on a task passed about 45 percent. That's a measurement on that study's set of tasks, not a universal law.

Put simply, parallel fan-out has an orchestrator start several sub-agents together, each with its own isolated context, while a sync join gate is a reducer node that waits for all branches and combines them by a fixed rule instead of bargaining. Ten months later even the doubters of graphs agreed on a single principle: only one writer at a time, with extra agents adding thinking power rather than separate actions.

You now know when a graph helps and when it hurts. What remains is assembling all three layers into a pipeline.

The integrated five-stage pipeline

The layers combine into one concrete pipeline, which might be called a unified five-stage architecture. It works like an assembly line for everything above: set the boundaries, split off independent work, check each piece against hard evidence, record a receipt, and at the end invite someone to attack the result.

Each stage fits in a sentence and belongs to a layer:

1. Harness sandbox initialisation sets the boundaries before work starts.
2. Parallel graph fan-out and scoping peels off only the work that truly stands alone.
3. Local evidence-gated retry loops force every piece to prove itself before reporting back.
4. Harness state hashing and token deduplication record hard receipts instead of lossy summaries.
5. An adversarial red-team gate, covered in the next section.

The most helpful finding runs against intuition. Value comes from having all five stages present in a minimal form, not from a polished version of just two. A thin adversarial gate that gets run is better than an elaborate one that is never built.

The smallest workable setup is brief: repository instructions under three hundred lines, one verification command that can be run, a sandbox or at least an isolated worktree, a stop condition that isn't model-written text, state kept in commits and a progress log, and a ceiling on turns and spending. Those six come before any graph with multiple writing agents.

The pipeline is complete, but its last stage deserves its own section, because it addresses the zero-defect myth.

Stage five: adversarial verification, reduction and never zero

An adversarial red-team verifier is a second pair of eyes that never saw the code being written. It probes the patch for edge cases and vulnerabilities with no view of the implementer's reasoning trace, so it carries none of that agent's confirmation bias.

This layer catches a different class of defect from the evidence-gated loop, but not all of them, and no documented system reaches zero. Studies of models that critique code report clearly fewer errors, yet those same models also hallucinate some of the flaws they report. The test-gaming rate fell by about two-thirds between generations and didn't vanish.

The most revealing account is one pre-merge red-team exercise from a developer named Dotzlaw. Round one saw attacks succeed about 65 percent of the time. Patching known vectors in round two cut that to 20 percent, but a new wave using fresh filter-bypass techniques lifted it to 85.7 percent inside the same round, leaving a blended round-two figure of roughly 47 percent. Treat it as a single reported exercise, not a verified industry norm.

Reduction, never zero

The phrase "zero-defect production PR" belongs in marketing, not engineering. What can be honestly claimed is a lower escape rate for defects, never zero. Believing zero is reachable is riskier than admitting a ceiling, since it invites teams to drop the human gate that catches what tools cannot see by design.

The case cited most often as a warning is Replit in July 2025, when a production database was erased during an explicit change freeze. Nothing along the execution path enforced the freeze, which lived solely as an instruction in the prompt. Whatever the maturity of the other layers, keep a human or policy gate over the highest-stakes actions.

Given that even the full pipeline doesn't produce zero, what does it deliver? That's where caveated numbers come in.

Intern mode against architecture: numbers with a caveat

Begin with the gap instead of a figure. Four independent research passes behind this piece turned up no transparent, independent, per-pull-request study that compared the whole harness, loop and graph stack against an unsupervised single prompt. That absence tells its own story.

That's why the comparison of "intern mode" and "master architecture" shows up purely as an illustration and is described only by direction: quicker, cheaper, steadier. No made-up percentage, and no table pretending to be a measurement. These arrows should be read like a back-of-the-envelope estimate in planning, useful for intuition and useless in a document.

The one anchor available is narrower than the thesis and weaker on sourcing than ideal, so it's presented that way. It's the vendor-published comparison mentioned earlier, on a selected subset of SWE-bench Verified, showing a threefold cost spread at comparable or better success, and what it isolates is the environment layer by itself, not the combined three layers.

This matters for reader trust. A critical reader can check a cited number in seconds, so the "illustrative" label is a credibility asset, not a hedge. When the claim "a structured architecture is N times faster" shows up elsewhere, ask for the per-pull-request methodology before believing it.

The numbers are honestly labelled as illustrative. The failure patterns seen in production are not.

Four anti-patterns and their symptoms

Many complaints that the model just isn't good enough are really one of four named architectural gaps that can be fixed. Giving them names takes away the pull of swapping the model to solve an architecture problem.

• Confidence-driven looping. The agent claims success with tests still failing. The remedy is to bind the stop condition to a check that is deterministic.
• Noisy harness context. The agent loses yesterday's decision, reads the same files again and wastes tokens repeating work. The remedy is persistent state outside the context window along with a cache of tool results.
• Graph cycles without limits. One agent behaves, yet the multi-agent version returns results that contradict each other. The remedy is one writer at a time, with parallel reads only and each in its own context.
• Forcing deterministic work into the model. Symptom: a model call is doing parsing, deduplication or filtering that a plain function should handle. It's costlier, slower and less reliable than code that needn't reason at all.

Misdiagnosis can carry real cost. A 2025 independent study reported that experienced developers worked about 19 percent slower with the AI tools of that period on real issues. The caveat must stay attached: 16 participants, mature codebases above a million lines, and tooling from early 2025. It is a narrow but sound signal rather than a judgment on AI-assisted programming overall.

The diagnosis is in place. One question is left: does your stack even meet the minimum for this approach to make sense?

A production-readiness checklist

This is a pre-flight list, not a full operating manual. It has five short groups, with every item answerable yes or no.

• Harness: repository instructions of under three hundred lines, a sandbox or at minimum a worktree boundary, state persisted via commits and a progress log, and a tool-result cache that works.
• Loop: a stop condition built on an actual exit code instead of model prose, firm limits on iterations and turns, and a detector for no progress that notices the same failure repeating.
• Graph: a default of one writer, parallel fan-out only for independent read-only tasks, and a reducer with deterministic rules where branches merge.
• Evaluation: at least one deterministic check that runs in CI, plus a short written claim, kept narrow, about what a pass means and what it doesn't promise.
• Monitoring: logs that show each loop iteration and each graph branch, and an alert when spending reaches a threshold rather than only on outright failure.

Teams stall on this pipeline for a reason other than difficulty: they polish one layer before a minimal version of all five exists. Consider this a formal go-ahead to ship something thin at each layer before deepening any of them.

Three layers, one sentence

The harness provides the environment, the loop provides the feedback, and the graph provides the flow. None of the three replaces the other two, and the nested-box picture from the start is the only map really needed.

The largest shift this framework brings is not technical. The opening question at a failure changes, from whether to swap the model to which layer failed. Teams that adopt that reframing often find it shortens diagnosis more than any one code fix.

Five points to carry away:

• The layers are nested, not competing. The harness, graph, loop and model stack is a single production system rather than three competing philosophies.
• A symptom names its own layer: "done but broken" is the loop, "falls apart as a team" is the graph, and "forgot yesterday's decision" is the harness.
• Multi-agent orchestration is neither good nor bad; whether the task divides decides it, not taste in architecture.
• Adversarial verification lowers the number of defects that escape but never takes it to zero, so a person or policy check remains load-bearing on the riskiest actions.
• A bare-bones version of the full pipeline takes days to assemble, not months, so put up a thin version of every stage before deepening any.

Send the next production incident through the anti-pattern list before any code changes, and send the next architecture proposal through the readiness checklist before another agent joins the graph. A practical exercise for today: take the last three incidents with your agent and assign each a layer, harness, loop or graph. Most teams find one repeat offender, and that's the right place to spend next week.