Graph Engineering: Run a Fleet of 1,000+ AI Agents From One Prompt

Most people who build a multi-step AI agent end up with a straight line: step one, step two, step three — each waiting for the last to finish. Here's what almost nobody checks: half those steps never needed to wait. They queue one job at a time until the context window fills and the agent forgets what it was doing. It wasn't slow because the model was weak; it was slow because you drew a line where the work was a graph. This guide — adapted from codila's (@0xCodila) Graph Engineering thread — takes you from that line to a graph that fans out across a fleet and checks its own work.

Difficulty: Intermediate–Advanced · Required tools: Claude Code v2.1.154+ on a paid plan (on Max / Team / Enterprise, Dynamic workflows are on by default; on Pro, switch them on in /config), and a real repo · Updated: July 2026

Overview

Graph engineering is the successor to loop engineering. A loop is one cycle of getting better — try something → check the result → adjust → go again — a single agent improving one thing on repeat. (If you haven't met it yet, start with our Loop Engineering guide; this builds directly on it.) The single loop has a known failure: it can only see its own metric. Tie a support bot's loop to "ticket resolution rate" and the number climbs for months while satisfaction drops — the bot learned to close tickets, not solve them. That's Goodhart's law, and a lone loop can't escape it.

The answer isn't a better loop — it's a graph of loops: a network where cycles watch and correct each other. For agents that means one shift: stop writing one agent that does everything in a line, and instead design the shape of the work — what runs before what, what runs at the same time, what waits. In graph terms, nodes do the thinking (one agent, one job, one input, one output) and edges carry results (one node's output feeds another's input). And Claude Code shipped the tooling to build these directly: dynamic workflows, which spin up a fleet of agents from a single prompt and pass their results through code instead of your chat.

Why this matters is scale. One workflow run can fan out to 1,000 agents, up to 16 working at once — a job no single context could ever hold: a whole codebase audited in one pass, a migration touching every file, a search run a thousand angles at a time. But scale cuts both ways, and this guide is as much about the traps (agents that agree with themselves, agents that overwrite each other, graphs built where a line would do) as about the fan-out.

The honest goal: by the end you'll be able to spot where your linear agent is secretly a graph, build a real one with Claude Code's dynamic workflows, defend it against the two failures that break real graphs, anchor it in things that can't be argued with — and, just as important, know when not to reach for a graph at all.

Who This Is Useful For

What You Will Learn

What You Need

The 5 Steps

Step 1: See the edges that aren't there

A graph has two parts: a node (one unit of work — one agent, one input, one output) and an edge (a dependency — this node's output feeds that node's input). The mistake everyone makes is treating "and then" as an edge. "Summarize this file and then tell me the weather" — the weather doesn't read the summary. Those are two independent jobs a linear script chains for no reason, each waiting on the last for nothing. So build one habit: for every "and then," ask — does the next step actually read the previous step's output? If yes, it's a real edge; keep the order. If no, there's no edge; the wait is wasted, so run them side by side.

Pro tip: Your plain "do A, then B, then C" agent is already a graph — just the saddest one, a single chain where if C stalls, D never happens. The whole method starts by finding two boxes with no arrow between them. If you can't find any, you don't have a graph — and that's fine (see the last section).

Step 2: Build your first graph, start to finish

Enough theory — build one and watch it run. In a repo you know, paste this prompt (straight from Anthropic's examples):

Create a workflow to audit every route file under src/routes/
for missing auth checks. Spawn one agent per file, then run an
independent verifier on each finding before reporting.
Analyze a maximum of 20 files to start.

Claude Code will light up "Dynamic workflow requested" — your signal a graph is building, not a normal chat. It writes a JavaScript orchestration script and shows you the phases first; read them and approve. Then the fleet runs: one agent per file, in parallel, while your session stays free. Type /workflows to watch it live — scope, fan-out, verify, synthesize — and at the end you get one report, not twenty separate chats, because the intermediate results lived in the script's variables, not your context. When a run is good, press s to save it to ~/.claude/workflows, re-runnable by name; then change the task and keep the shape ("missing auth checks" → "unhandled promises" → "functions over 100 lines").

Pro tip: Ignore the "zero tokens" hype. Coordination is code, so passing results between agents doesn't re-spend context the way a chat handoff does — but the agents still cost usage, and a workflow costs meaningfully more than a normal session. The saving is in coordination, not the work. Start at 20 files, watch the usage, then widen toward the ceiling (1,000 agents, 16 at a time, moving in waves).

Step 3: The part that actually breaks

You built a graph; here's where real ones fall over. Failure one — the graph agrees with itself. When an agent checks its own work it goes easy on itself; models prefer their own outputs. So you put a verifier on the edge — a separate node that confirms a finding before it flows downstream. The catch nobody names: the verifier needs clean context. Hand it the same conversation the executor had and it isn't verifying, it's agreeing with itself in a different font. A graph of agents sharing one context is a single loop in a costume — it fails the same way, later and more expensively. So the verifier is a fresh node, own context, checking a real signal (not "did the agent say it's done" but "does the test actually pass"). Failure two — agents stepping on each other. When Bun's team first fanned a large port across many agents, the run failed operationally: agents ran shared git commands in one workspace and overwrote each other. The fix was structural, not clever prompting — forbid the unsafe commands and give each group its own isolated git worktree.

Pro tip: Before you fan out, answer three questions in writing: where does each agent work, how do results merge, and what happens when two disagree? Two agents writing the same file race; a graph without that plan doesn't scale, it fails faster. Isolation (a worktree per worker) and a clean-context verifier are not optional polish — they're the difference between a fleet and a pile-up.

Step 4: Six graphs to build — and what the ceiling really costs

The method is always the same shape — find the real edges → fan out → verify on independent context → isolate the workers — aimed at a new job. Six to try this week: a security sweep (one agent per file, a verifier confirming each hit — the one you built); a cited report via /deep-research (splits a question into angles, searches in parallel, agents refute each other before writing); port a module (file by file, tests as the gate, failures looped back); an adversarial diff review routed by size (small change → one pass, big one → full parallel audit); a scheduled ecosystem scan (save once, re-run by name); and discovery of unknown size (finders run in parallel, each result checked against everything seen, looping until two rounds find nothing new). As for the ceiling: Bun's Zig-to-Rust port ran on this exact machinery — around 50 workflows, a peak of 64 agents in parallel, roughly 535,000 lines of Zig turned into over a million lines of Rust in 11 days. It also cost about $165,000 in usage, needed a human designing and monitoring the whole thing, and drew public criticism over whether that much AI-authored code can be safely reviewed. The scale is real; so is the price, and the supervision.

Pro tip: Reach for scale only where the work is genuinely wide. A thousand agents is right for "audit the whole codebase at once"; it's absurd for "fix this one bug." Match the fan-out to the width of the job, and keep a human in the loop — at Bun's scale, the supervision was the job.

Step 5: Anchor the graph in things that can't be argued with

Topology alone doesn't buy truth. A network of agents all confirming each other, none of them touching anything real, fails exactly like the single loop did — just with more moving parts and more green lights on the way down. So a graph needs anchors: nodes that can't be argued with. Tests that actually ran — not "should pass," did pass. A verifier on evidence, not vibes. And frozen rules the agents are never allowed to tune — because those are exactly the ones an optimizer would quietly weaken to make its numbers look good. The graph is only as honest as the things in it that refuse to move.

Pro tip: Identify your "frozen nodes" before you run — the test suite, the acceptance criteria, the safety rules — and put them where no agent can edit them. If everything in your graph is negotiable, you've built a very elaborate way to agree with yourself.

When a Graph Is the Wrong Choice

Most tasks are not graphs, and reaching for one when you don't need it just burns money and adds ways to fail. Skip the graph when: the task is small or isolated (adding a function, fixing one bug — a single agent is faster and cheaper); you need tight oversight (if you want to read and approve every step, a graph's whole point — running wide without you — works against you); you don't yet know what you're looking for (exploratory work wants one agent you can steer, not a fleet committed to a plan before you understand the problem); or the steps genuinely depend on each other (if every step reads the last one's output, it's a real chain and parallelism has nothing to grab). The tell is Step 1: if you can't find two boxes with no arrow between them, there's no graph to build — it's a loop, and a loop is fine.

3 Common Mistakes to Avoid

Going Further

Key Takeaways

Sources: Graph Engineering — codila (@0xCodila) on X · Rewriting Bun in Rust — Simon Willison · Loop Engineering (the prerequisite) — AfterWork Startup