--- title: "Agent Orchestration Is a Graph Problem, Not a Prompt Problem" description: "Why linear agent chains waste most of their wall-clock, how to find the parallelism hiding in your workflow, and what actually breaks when you fan out to a fleet." url: https://vikasmishra.ai/blog/agent-orchestration-is-a-graph-problem/ canonical: https://vikasmishra.ai/blog/agent-orchestration-is-a-graph-problem/ published: 2026-08-08 author: Vikas Mishra tags: ["AI Agents", "Claude Code", "Agent Orchestration", "Multi-Agent Systems", "Developer Productivity"] --- # Agent Orchestration Is a Graph Problem, Not a Prompt Problem > Why linear agent chains waste most of their wall-clock, how to find the parallelism hiding in your workflow, and what actually breaks when you fan out to a fleet. *Source: [https://vikasmishra.ai/blog/agent-orchestration-is-a-graph-problem/](https://vikasmishra.ai/blog/agent-orchestration-is-a-graph-problem/)* Most multi-step agents I see in the wild have the same shape: a straight line. Step one, then step two, then step three, each one waiting for the previous one to finish before it starts. Here is the question almost nobody asks about that line: how many of those steps actually needed to wait? In my experience, usually less than half. The rest just queue, one job at a time, while the context window fills up with intermediate output and the agent slowly forgets what it was doing. When people tell me their agent is slow or unreliable, the model is rarely the problem. The problem is that they drew a line where the work was a graph. ## The loop was the atom. It was never the whole molecule. A single agent loop is one cycle of getting better: try something, check the result, adjust, go again. That loop is genuinely powerful, and I've written before about why [agentic coding is a different skill](/blog/agentic-coding-is-a-different-skill/) built on exactly that cycle. But a single loop has a failure mode that every metrics-driven team will recognize. Tie a feedback loop to one number and the number improves while the thing you cared about degrades. A support bot optimized on ticket resolution rate learns to close tickets fast instead of solving them. That's Goodhart's law, and a loop is structurally defenseless against it: it can only see its own metric. It cannot ask whether the target is right, and it cannot notice its own measurement drifting. The fix is not a better loop. It's a graph of loops, a network where cycles watch and correct each other. For agents, that translates into one design habit: stop writing one agent that does everything in a line, and start designing the shape of the work. What runs before what. What runs at the same time. What waits. Nodes do the thinking. Edges carry the results. ## Finding the edges that aren't there A graph has two parts. A node is one unit of work: one agent, one job, one input, one output. An edge is 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" is not a dependency. The weather does not read the summary. Those are two independent jobs that a linear script chains together for no reason. So the habit that starts everything: for every "and then" in your workflow, ask whether the next step actually reads the previous step's output. - If yes, that's a real edge. Keep the order. - If no, there is no edge. The wait is wasted. Run them side by side. If no data crosses between two boxes, they are independent, and that independence is the entire resource you're going to exploit. Your plain "do A, then B, then C" agent is already a graph. It's just the saddest possible one: a single chain where if C stalls, D never happens. ## Build one this afternoon Enough theory. Claude Code shipped this as a first-class feature called dynamic workflows, so you can build a real graph without writing an orchestrator yourself. You need a recent version and a paid plan (on Max, Team, or Enterprise it's on by default; on Pro, enable the Dynamic workflows row in `/config`). Open a repository you know well, so the result means something to you, and paste something like this: ``` 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. ``` Swap `src/routes/` for wherever your files live. The "max 20" line keeps your first run cheap, and I mean that seriously; more on cost below. What happens next is the interesting part. Claude Code flags that a dynamic workflow was requested, writes a JavaScript orchestration script, and shows you the phases before anything runs. You approve the plan, and then a fleet runs: one agent per file, in parallel, while your own session stays free. You can type `/workflows` and watch it live: scope, fan out, verify, synthesize. At the end you get one report. Not twenty separate chat transcripts. One answer, because the intermediate results lived in the script's variables instead of your context window. That's a graph: a dozen agents, from one sentence. When a run is good, press `s` and it saves to `~/.claude/workflows`, re-runnable by name. Then change the task and keep the shape: swap "missing auth checks" for "unhandled promises" or "functions over 100 lines." One honest note on the "zero tokens" claim you'll hear around this feature. The coordination is code, so passing results between agents doesn't re-spend context the way a chat handoff does. But the agents themselves still cost usage, and a workflow costs meaningfully more than a normal session. The saving is in coordination, not in the work. Start scoped, watch your usage, then widen. ## How far this scales, and where it actually breaks A single workflow run can fan out to a thousand agents, with up to sixteen working at once. That ceiling is not a metaphor; it's the documented limit. A thousand agents means a job no single context could ever hold: a whole codebase audited at once, a migration that touches every file, a search that runs a thousand angles in parallel. The public high-water mark so far is Bun's Zig-to-Rust port, which Simon Willison wrote up in detail. Around fifty workflows, a peak of sixty-four agents in parallel, roughly 535,000 lines of Zig turned into over a million lines of Rust in eleven days. It also cost about $165,000 in usage, needed a human designing and monitoring the whole thing, and drew real criticism over whether that much AI-authored code can be safely reviewed. The scale is real. So is the price, and the supervision. Between your twenty-file starter and Bun's port sit the two failures that actually kill graphs in practice. **Failure one: the graph agrees with itself.** When an agent checks its own work, it goes easy on itself. Models prefer their own outputs. The standard fix is 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 anything; it's agreeing with itself in a different font. A graph of agents sharing one context is a single loop in a costume, and it fails the same way, just later and more expensively. The verifier has to be a fresh node, with its 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.** This one isn't hypothetical either. When Bun's team first fanned that port across many agents, the run failed operationally: agents shared git commands in one workspace and overwrote each other. The fix was structural, not clever prompting. Unsafe commands were forbidden and each group got its own isolated worktree. That is the real lesson of parallelism: two agents writing the same file race, every time. Before you fan out, answer three questions. Where does each agent work? How do results merge? What happens when two disagree? A graph without that plan doesn't scale. It just fails faster. ## Anchors keep the graph honest 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. The graph needs anchors: nodes that can't be argued with. - Tests that actually ran. Not "this should pass" but "this did pass." - A verifier that checks evidence, not vibes. - Frozen rules the agents are never allowed to tune, precisely because they're the ones an optimizer would weaken first. The graph is only as honest as the things in it that refuse to move. ## 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 failure modes. Skip the graph when: - **The task is small or isolated.** Adding a function or fixing one bug. A workflow is pure overhead here; a single agent is faster and cheaper. - **You need tight oversight.** If you want to read and approve every step before the next one runs, the graph's whole point, running wide without you, works against you. - **You don't know what you're looking for yet.** Exploratory work wants one agent you can steer, not a fleet committed to a plan before you understand the problem. - **The steps genuinely depend on each other.** If every step reads the last step's output, it's a real chain and parallelism has nothing to grab. Forcing a graph onto a sequential task adds coordination cost for zero speedup. The tell is the edge test from earlier. If you can't find two boxes with no arrow between them, there is no graph to build. It's a loop, and a loop is fine. A graph is a tool for width: independent work, done at once. When the work isn't wide, the line was never the problem. ## The shift The linear agent was never the ceiling. It was just the first shape, the one everyone reaches for because it matches how we type: one line, one thing at a time. Once you see the nodes and edges, you stop asking the agent to do more and start asking the graph to do it wider. Fan out where the work is independent. Gate the edges where confidence matters. Freeze the nodes that hold the truth. Most people will keep queueing steps in a line. The few who learn to draw the graph, and to respect what breaks it, will run a fleet. The job title quietly changes along the way: a prompter asks a question; an architect draws a graph. --- *This post was sparked by a thread from [codila on X](https://x.com/0xCodila/status/2079597821511020996) on graph engineering, and by [Simon Willison's write-up](https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/) of the Bun Zig-to-Rust port. The framing and opinions here are my own.*