Why Loop Engineering Is Dead and Graph Engineering Is the Future

Hello, I’m PaperAgent, not an Agent!

Recently Loop Engineering has lost its appeal while Graph Engineering is booming, even the father of OpenClaw, Peter Steinberger, jokes that we should stop discussing Loops and start discussing Graphs.

Below we explore what Graph Engineering is and how to get started.

Loop Engineering : research on how to keep a model running continuously over long periods to better complete tasks.

Graph Engineering : research on using directed graphs to organize multiple agents' writing and propagation, solving complex real‑world problems.

Initially, an Agent’s execution is understood as a simple while loop—Agent Loop. Loop Engineering adds a parent loop around child loops to reduce manual intervention, letting the Agent sense environment changes and run until the goal is reached.

In practice, multiple agents often need to run in parallel with dependencies, which corresponds to a directed graph in computing.

The graph is a directed graph because the output of one Agent may need to be passed to another for further processing.

Claude’s Graph Engineering practical guide:

01. Nodes are tasks, edges are the flowing things

A graph has only two elements; distinguishing them clears most confusion. Nodes are work units—an agent, a bounded task, one input and one output. Edges are dependencies: they declare that a node’s output feeds another node’s input, and that’s it.

Common mistake: treating "then" as an edge. "Summarize this file, then tell me the weather" has no edge because the weather step does not consume the summary. Those are two independent nodes unnecessarily chained by a linear script. An edge exists only when data truly flows.

Ask for each "then": does the next step read the previous step’s output? If not, there is no edge, and waiting is wasteful.

02. Your linear script is a degenerated graph

When you write an agent as "do A, then B, then C, then D", you have actually drawn a graph—a single‑branch chain where each node has one input and one output. It works but is slow and fragile: if C stalls, D never runs and A’s result is stuck upstream.

The first real skill of Graph Engineering is to redraw this chain. For each arrow, ask the step‑01 question. Most chains have two or three arrows that carry no data—just the order you typed. Cut them out, and the chain collapses into a wider shape: several independent nodes that can run simultaneously, feeding a node that needs all of them.

03. Give each node a contract

Un‑inferable nodes cannot run in parallel. The solution is a contract: bounded input, bounded output, exactly one task. Input is passed explicitly (never assumed from a shared window), and output has a defined shape (preferably validated) so the next node can consume it without guessing.

In a workflow, contracts are enforced with a schema applied to agent(). The spawned sub‑agent must return a validated structured JSON—validation happens at the tool‑call layer, and Claude automatically retries on mismatch instead of handing you free‑form text that must be parsed and prayed over. This is the difference between a node that Claude can ingest into a graph and a node that only produces human‑readable output.

04. Treat edges as data contracts

An edge is not just "B after A"; it is a promise about the content that crosses: A produces a shape, B is designed to consume that shape. Naming edges by data rather than sequence makes two things easier: you can instantly see whether an edge is real (data truly flows) and you can replace either endpoint while preserving the shape.

In practice, an edge is ordinary JavaScript; the reduce (flatten/dedupe/filter) between fan‑out and aggregation is just code that operates on the node’s returned shape.

No agent needed. Much of the work people burn tokens on is actually edge work, which is free.

05. Use parallel() for fan‑out

This is the key trick that pays for everything. When you have N independent nodes—N sources to query, N documents to review, N routes to audit—don’t chain them. Let Claude fan them out and run concurrently. In a workflow this is parallel(): Claude receives an array of thunks, each thunk spawns a sub‑agent that runs in parallel, and returns an array of results.

Two details make it robust. First, parallel() is a barrier—it waits for all thunks to finish before returning, so the next stage sees the complete collection. Second, a thunk that throws is parsed as null instead of crashing the whole batch, so a misbehaving agent doesn’t sink the entire run. Always filter with .filter(Boolean). Concurrency is capped by CPU cores and excess tasks are queued; even 100 thunks finish.

Fan‑out lives in Claude‑written code, not in the model dialogue—Claude’s context never holds nine sources at once; each sub‑agent carries its own context and only returns the final answer.

This is why Claude can scale a workflow to dozens or hundreds of sub‑agents without drowning the conversation. The orchestration layer adds zero tokens because it isn’t another round of Claude thinking.

06. Fan‑in at the barrier

Fan‑out is only useful when its results are aggregated. Fan‑in is the node that gathers edges—a single agent (or code block) that sees all upstream results at once to perform tasks that require the whole set: cross‑source deduplication, impact‑based sorting, early exit when the total is empty. This is the only place where the barrier’s wall‑clock cost is justified.

Rule for fast graphs: use a barrier only when a stage truly needs all prior results.

If you write parallel() → transform() → parallel() and the transform has no cross‑item dependency, replace it with a pipeline and skip the barrier.

07. Diamond: split → work → merge

Combine fan‑out and fan‑in to get the main topology of a serious agent graph: a diamond . One node splits, many nodes work in parallel, one node merges. Market scanning, dependency audit, code review, research reports—swap sources and prompts, the same skeleton adapts.

The canonical form is fan out → reduce → synthesize. Fan‑out expands breadth, pure code reduce compresses, and the final agent synthesize writes the answer. Seeing the diamond shifts the question from "how to make an agent take more steps" to "where to split and where to merge"—the real scalability challenge.

08. Route edges at runtime with conditions

Not every graph is static. Sometimes which edge to follow depends on what a node discovers. A router node checks the result and decides which downstream path to trigger—e.g., classify a ticket then branch to the appropriate processor, or choose fast review vs. full audit based on diff size. In a workflow this is just a JS if / switch because control flow lives in code.

Determinism becomes a feature, not a limitation. Routing decisions can be driven by Claude (sub‑agent classification), but the routing itself is Claude‑written code—each classification follows the same path each time. No emergent “Claude decides to skip audit” surprises, because skipping must be encoded in the graph.

09. Put a validator on an edge

The real lever of a graph isn’t more agents but the structure you wrap around them—to generate confidence. A validator node sits on an edge; before letting downstream consume a result, its sole job is to try to kill the discovery. Only survivors pass through; otherwise the answer never reaches the end.

Three validation patterns to master:

Adversarial validation: spawn N independent skeptics for each finding; keep the finding only if a majority survive.

Multi‑view validation: give each validator a different perspective—correctness, safety, reproducibility—to catch failure modes a single check misses.

Judging panel: generate N attempts from different angles, parallel‑judge them, and combine the winner with the best parts of the runners‑up.

The author claims this pattern let a team embed adversarial code review into the Bun runtime migration.

10. Isolate nodes so one failure doesn’t poison the whole graph

In a chain, failure cascades—C dies, D never runs, the whole run stalls. In a graph, failure should be confined to its own node. parallel() already isolates failures: a thunk that throws becomes null, so eight good agents return, one bad agent is dropped. .filter(Boolean) does the isolation. Design each fan‑in to tolerate missing inputs rather than assuming a full set.

A subtler failure is nodes stepping on each other—parallel agents writing files can collide. The fix is isolation: "worktree" —run each agent in its own Git worktree, sandboxed, and merge cleanly. Use this only when agents truly write in parallel; it’s a safety belt for that topology, not a default tax.

11. Add a loop—but make it converge

Sometimes you don’t know the scale of discoveries up front; you may need a loop—a controlled edge that points back to an earlier node. The danger is a non‑converging loop that spawns agents forever until the budget runs out.

Convergent pattern is "loop‑until‑dry": keep spawning a finder until K consecutive rounds produce no new discoveries, then stop. The crucial detail most get wrong is what to deduplicate against—compare against all seen items, not just confirmed ones. Otherwise rejected findings keep reappearing and the loop never dries.

12. Cross‑node tiered models

Not every node needs your best model. A graph makes this explicit: some nodes are bounded and repetitive (field extraction, task splitting) and can use cheap models; others carry real judgment (synthesis, adjudication) and deserve expensive models.

In a workflow each sub‑agent inherits your session model unless the script overrides it—so a large run costs the session model for the whole run. A single

agent()

model

option lets Claude route that node elsewhere.

Before a big run, check /model : let Claude downgrade repeated nodes and keep high‑end models for merge nodes—this turns a token‑hungry graph into a cost‑effective one without changing its shape.

13. Topology is your cost and latency

The shape of the graph is not decoration—it is the biggest lever on wall‑clock time.

Choice between parallel() and pipeline(): parallel() barrier makes everything wait for the slowest node. pipeline() lets each item flow through all stages independently, so fast items finish early without waiting for slower ones.

Default to pipeline(). Use a barrier only when a stage truly needs all prior results—cross‑collection deduplication, total‑early‑exit, or prompts that must reference "other discoveries". Barrier latency is real, measurable, and wasted time; splitting ≠ synchronizing.

14. Let Claude draw the graph—self‑routing

Final trick: for tasks you can’t pre‑plan, stop hand‑drawing graphs. Use dynamic workflows: describe the goal, Claude writes the orchestration script—splits the task, selects fan‑out, spawns a fleet, aggregates results. You get a graph tailored to that run instead of praying a fixed graph will work.

Graph Engineering with Claude:  https://x.com/svpino/status/2078516761318584774
https://x.com/0xCodez/status/2079165300625330317