An agent that asks for approval after every step has moved the work but not the supervision. The person still supplies the control flow: start this task, inspect that output, request a correction and decide what happens next. More agents can make that arrangement faster and more expensive without making it autonomous.
Hanako's X Article, “Loops and Graphs: how to stop babysitting agents and only approve the last step”, offers a useful distinction. A loop makes one bounded unit of work converge against a check. A graph decides which units exist, what depends on what, which work can run together and where failed or accepted results go next. In the article's cleanest formulation, loops live inside nodes and the graph lives between them.
That is a strong design lens, not a complete production specification. A check can be wrong, parallel branches can conflict, retries can repeat side effects, a learning edge can preserve a bad rule and a human can approve a polished but incomplete summary. This guide covers the full architecture and adds the controls needed to operate it safely.
Separate the layers before adding agents
Treat the system as five layers with different responsibilities. Adding another model call cannot repair a missing control in another layer.
| Layer | Decision it owns | Common failure |
|---|---|---|
| Unit | Produce one bounded result | Scope expands during correction |
| Evaluator loop | Accept, reject or escalate that result | The evaluator rewards plausible output instead of evidence |
| Workflow graph | Route dependencies and concurrency | False edges serialize work; missing edges create races |
| Execution runtime | Persist state, retry, cancel and deduplicate | A resumed run repeats work or commits a stale effect |
| Authority gate | Decide whether a consequence may occur | Model confidence substitutes for permission |
Anthropic's building effective agents guide makes a related distinction between workflows with predefined code paths and agents that dynamically direct their own process. It describes parallelisation, orchestrator-worker and evaluator-optimizer patterns as different tools. Do not start with a fleet. Start with the simplest shape that matches the task and introduce a model only where the decision genuinely requires interpretation.
A loop begins with a check that can fail
The basic loop is short:
- produce a candidate result;
- check it against an acceptance contract;
- return precise failure evidence to the producing unit;
- correct only the failed scope; and
- repeat until accepted, exhausted or escalated.
Write the acceptance contract before the generator. If success cannot be stated independently of the candidate output, the loop has no stable target. “No exception was raised” proves that code ran, not that it did the right thing. “The reviewer likes it” is not a release test.
Use the strongest available evidence first:
- schema validation, type checks and allow-lists;
- exact calculations, tests and policy rules;
- source presence, date, identity and version checks;
- comparisons with labelled examples or known invariants;
- calibrated model assessment for criteria that cannot be made deterministic; and
- human judgement for unresolved or consequential cases.
An evaluator model can be useful when quality is nuanced and iterative feedback demonstrably improves the result. Anthropic calls this the evaluator-optimizer workflow. It is a poor fit when the criteria are vague, first-pass quality is already adequate or a deterministic transformation has one correct result.
Avoid using a generator and evaluator with the same prompt, evidence and incentives. That creates two correlated opinions, not independent assurance. Hold out adversarial cases, measure false acceptance and false rejection, and calibrate any model judge as described in our LLM-as-a-judge guide. A loop should stop because evidence passed—not because two models sound confident together.
A graph models work, not an agent org chart
A node is one bounded operation with a declared input, output, timeout, authority and acceptance contract. It may contain ordinary code, a database query, a model call, a person or a complete local loop. An edge is a reason another node may or must run.
LangGraph's current Graph API uses the same broad model: nodes perform work and edges route state, including conditional branches and parallel fan-out. That is useful terminology, but the graph should remain a business design before it becomes a framework configuration.
The X Article proposes a sharp test for suspiciously linear pipelines: does the next step actually consume the previous step's output? If not, the wait may be unnecessary. Keep that test, then check three other dependency classes before deleting the edge:
| Dependency | Question to ask | Example |
|---|---|---|
| Data | Does the next unit consume an output or version from the prior unit? | A writer needs the research evidence pack |
| Control | Must one decision happen before another even without data transfer? | Approval must precede publication |
| Resource | Would concurrent execution contend for or corrupt shared state? | Two workers modify the same migration file |
| Policy | Does the later unit require authority established by the earlier one? | A payment draft must exist before release can be approved |
Two tasks can run in parallel only when their outputs have defined merge semantics and they do not violate a shared invariant. A graph that removes visible data edges but ignores rate limits, locks, approval order or common files will be fast until it fails.
Four node roles cover most useful graphs
The source article reduces the vocabulary to splitter, worker, code node and gate. That is a practical starting set.
Splitter
The splitter defines the units and therefore the coverage. A weak splitter divides by whatever boundary is easiest to name—folder, document or date—and sends several workers into overlapping contexts. A stronger splitter divides by the reason results may differ: blast radius, threat lens, customer segment, evidence class or independent hypothesis.
The output should name each unit, scope, required evidence, allowed tools, forbidden actions, dependencies and merge key. If two workers are expected to produce different findings, give them distinct lenses and only the context each needs. If they receive the same task and same context, their agreement is weak evidence because the errors are correlated.
This is not a reason to isolate every fact. Some tasks require shared state, and current multi-agent research still finds difficult coordination problems when agents depend heavily on one another. Anthropic's August 2026 analysis of patterns and problems in multi-agent systems reports both useful specialisation and conformity failures. Isolation should create intentional diversity, while hand-off contracts preserve the facts that genuinely must cross lanes.
Worker
A worker owns one unit, one lens and one output schema. Give it the minimum tools and authority needed for that unit. It may run its own produce-check-correct loop, but it must not silently enlarge the scope because it noticed adjacent work.
Return a durable artefact or structured result, not a long conversation transcript. Anthropic's account of its multi-agent research system describes separate context windows, focused subagents and persistent artefacts as ways to increase capacity without repeatedly copying every intermediate result through the lead agent.
The same account supplies an important cost warning: its agents used about four times the tokens of chat interactions, while multi-agent systems used about fifteen times as many. That is an observed result for Anthropic's research architecture, not a universal multiplier, but it makes the economic test clear. Parallel agents are justified by valuable coverage, latency or context isolation—not by agent count itself.
Code node
Use ordinary code for deterministic transformation: deduplication, sorting, schema conversion, checksums, exact comparison, aggregation and policy evaluation. A model adds latency and variance to work that already has one defined answer.
A helpful test is whether the operation can be fully specified without words such as judge, interpret, assess or summarise. If it can, implement and test it as code. Code nodes also make merge behaviour explicit: branch results should be keyed by stable unit identity, never by arrival position.
Gate
A gate converts evidence into one of a small set of routes: accept, return this unit, quarantine, request human approval or stop. It must change what happens next. A verdict that only appears in a report is observability, not control.
Build the gate before scaling the worker count. Our five action-validation gates separate structure, evidence, policy, authority and execution checks because a fluent answer can pass one and still fail another.
Loops live inside nodes; graphs route between them
This division is the article's most useful architectural rule.
| Inside one node | Between nodes |
|---|---|
| Produce a scoped candidate | Split a goal into units |
| Evaluate against the unit contract | Fan independent units out |
| Correct the rejected scope | Merge by stable identity |
| Stop at an attempt or cost limit | Route failed units to their owner |
| Return accepted evidence | Pause at a consequence gate |
A loop without a surrounding graph can make one step excellent while the overall job remains serial, incomplete or wrongly ordered. A graph whose nodes do not verify their work produces unverified output in parallel. The composition matters more than either abstraction alone.
Persist both layers. The runtime needs a stable run identity, graph version, node and unit identities, input versions, attempt count, accepted artefacts, pending edges and approval state. LangGraph's persistence and interrupt documentation illustrates why checkpoints are necessary for durable human pauses and resumption. Whatever runtime is used, resuming must not mean replaying every side effect before the pause.
Keep correction and learning on different return paths
The source distinguishes a short correction edge from a long learning edge.
- A correction edge returns one rejected unit to its producer with failure evidence. It improves the current run.
- A learning edge derives a candidate constraint from an accepted or investigated result and offers it to the splitter or policy layer. It may improve later runs.
Do not let every accepted output rewrite future instructions automatically. A result can be accepted under narrow conditions, pass by evaluator error or contain a workaround that should not become policy. Treat learning as change control:
- extract the proposed constraint and the evidence that supports it;
- define its scope, owner and expiry or review date;
- test it against held-out and counterexample cases;
- approve it at the authority appropriate to its blast radius;
- version the splitter or policy configuration; and
- monitor regression and retain a rollback path.
The durable object is the constraint and its provenance, not an unbounded accumulation of transcripts. Otherwise the graph does not learn; its context merely grows. Anthropic's context-engineering guidance makes the underlying resource problem explicit: an agent loop continually produces possible context, so the system must curate what enters the next inference.
Return the failed unit, not the whole batch
When one of four independent units fails, preserve the three accepted artefacts and retry only the failed unit. Re-running good units spends more, introduces new variance and can turn one known failure into several uncertain outputs.
The return envelope should include:
- stable run and unit identities;
- the exact acceptance criterion that failed;
- observed evidence and the expected condition;
- the permitted correction scope;
- the previous artefact or a durable reference to it;
- attempt count, deadline and remaining budget; and
- the route to escalate when correction is not appropriate.
Unit-level retry is not automatic in every orchestration product. AWS documents that a retry configured on a Distributed Map state applies to all child workflow executions and creates a new Map Run. If only failed children should repeat, design the retry boundary inside the child or preserve successful child results behind an idempotent merge.
Cap retries, but treat “three attempts” as a useful heuristic rather than a law. A transient network error, an evidence failure and a bad plan need different routes. Retry transient operations with bounded backoff; return correctable quality failures with specific evidence; re-plan when the unit definition is wrong; stop when authority, budget or deadline is exhausted. The AI agent cancellation guide covers the related requirement that stopping a graph must propagate to child work instead of merely closing the visible stream.
Every retried side effect also needs a durable operation identity, current state version and sink-side duplicate protection. The agent concurrency guide explains why workflow-level confidence cannot prevent duplicate or stale commits.
Put the human gate at consequence, not at every thought
The goal is not to remove people. It is to move their judgement to the smallest number of decisions where it changes risk.
| Consequence class | Default route | Required evidence |
|---|---|---|
| Reversible and contained | May auto-accept inside a bounded lane | Deterministic checks, scope proof and rollback identity |
| Reversible but wide | Pause before merge or release | Checks, affected dependencies, clean retry trajectory and rollback plan |
| Hard to reverse or high impact | Closed lane; explicit human decision | Fresh source state, exact proposed effect, authority, limits and recovery plan |
Blast radius and reversibility are stronger routing variables than a model's confidence because the model can influence its own confidence but not the external cost of being wrong. OpenAI's practical guide to building agents similarly recommends human intervention after failure thresholds and before sensitive, irreversible or high-stakes actions. OWASP's Excessive Agency guidance goes further: minimise tool functionality and permissions, require approval for high-impact actions and enforce authorisation in downstream systems rather than asking the model whether it is allowed.
Approval must be specific and fresh. Show the exact effect, target, evidence, changed state, residual uncertainty and recovery path. Bind approval to the operation and version reviewed; do not treat “ship the project” as permanent authority for later mutations. NIST's AI RMF Core calls for defined and documented human oversight, ongoing monitoring, safe failure and risk controls matched to impact.
A worked graph for a repository migration
Consider migrating an internal API client while keeping its existing public behaviour.
The splitter first maps blast radius rather than folders: authentication, pagination, error translation, rate limiting and downstream call sites. Each unit gets a baseline test, owned files, forbidden interfaces and a typed result contract. Workers receive isolated contexts so the authentication reviewer does not anchor the pagination review, while shared interface versions are passed explicitly.
Inside each worker node, the loop produces one bounded patch, runs the relevant compile and tests, checks the diff scope and returns only the failing evidence for correction. A code node collects results by unit ID, rejects overlapping writes, reruns the combined contract suite and builds a dependency report. A gate returns only the conflicting unit or pauses if a shared public interface changed.
The merge can be automatic when every patch is contained, deterministic checks pass and a revert is available. It remains human-gated when authentication semantics, a database migration or a wide shared type changes. After an accepted run, a proposed learning constraint—such as “pagination migrations must include the empty-page fixture”—is tested, reviewed and versioned into the next splitter template.
The person reviews one consequential merge with the evidence assembled. They do not supervise every model turn.
Measure the path as well as the answer
An accepted final artefact can hide waste, repeated failures and unsafe routes. Instrument the graph itself.
| Measure | What it reveals | Review trigger |
|---|---|---|
| First-pass acceptance by node and unit type | Splitter and worker fit | Persistent low rate in one lane |
| False-accept and false-reject rate | Gate quality | Any high-impact false acceptance |
| Correction attempts and scope growth | Loop convergence | Repeated attempts or widening diffs |
| Preserved work on partial failure | Unit-level recovery | Good units repeatedly rerun |
| Parallel efficiency and merge wait | Graph shape | More concurrency without lower task latency |
| Tokens, tool calls and cost per accepted unit | Economic value | Agent count rises faster than useful coverage |
| Human approvals by consequence class | Oversight placement | Routine low-risk work dominates the queue |
| Rollbacks and post-approval incidents | Gate sufficiency | Repeated source, node or policy pattern |
| New constraints and later regression | Learning quality | Rules accumulate without measurable gain |
Trace every decision using stable identities and evidence references, while avoiding unnecessary prompt or personal data. Our incident replay guide shows how to make runs reconstructable without logging everything.
When a graph is the wrong answer
Use a single call or a simple coded workflow when the task is small, the path is fixed, the output is cheap to verify or the parallel branches would share most of their context. Do not build a graph where no reliable acceptance condition exists; it will automate motion rather than correctness.
Avoid autonomous execution for hard-to-reverse actions until authority, idempotency, reconciliation and compensation exist independently of the model. Do not use ten workers to create diversity when they share the same evidence and instructions. And do not label a growing memory store “self-improvement” unless its changes are evaluated against future outcomes.
The practical verdict
The X Article's central distinction survives scrutiny: a loop improves one bounded unit; a graph shapes the job around those units. The important implementation consequences are to write the check first, split by meaningful coverage, keep independent workers in intentional contexts, use code for deterministic merges, retry only the failed unit, separate run correction from governed learning and place human approval where consequences become difficult to reverse.
The result is not a system with the most agents. It is a system that can show why each unit ran, what accepted it, what changed after failure, which work was preserved and why the one remaining human decision is the right one to make.
