{"id":"2079899723947712845","url":"https://x.com/0xWast3/status/2079899723947712845","text":"","author":{"name":"wast3","username":"0xWast3","avatarUrl":"https://pbs.twimg.com/profile_images/1978452473338880000/_lIVCi0x_200x200.jpg"},"createdAt":"Wed Jul 22 12:01:51 +0000 2026","engagement":{"replies":29,"retweets":86,"likes":539,"views":1115466},"article":{"title":"Graph Engineering: How to Run 1,000 AI Agents in Parallel From One Prompt","previewText":"Everyone building multi-agent systems in 2026 is still writing straight lines. Step one, then step two, then step three - each one waiting on the last. Here's why that's slow, and how to fix it.","coverImageUrl":"https://pbs.twimg.com/media/HNzxE_0WEAARTN-.jpg","content":"Everyone building multi-agent systems in 2026 is still writing straight lines. Step one, then step two, then step three - each one waiting on the last. Here's why that's slow, and how to fix it.\n\n![](https://pbs.twimg.com/media/HNzkvaPWoAAf53v.png)\n\n# The problem nobody checks\n\nYou built a multi-step agent. It works. It's also slow.\n\nYou assume the model is the bottleneck. It isn't.\n\nThe bottleneck is the shape you drew. A chain - step 1 waits for step 2, step 2 waits for step 3 - forces sequential execution even when half those steps have nothing to do with each other.\n\n\"Summarize this document, then check the weather\" is two independent jobs wearing a trench coat as one workflow. The weather task doesn't need the summary. It never did. But if you wrote it as a chain, it waits anyway.\n\nThat wasted wait, multiplied across dozens of steps, is where most of your runtime disappears.\n\n# Chapter 1 - Loops vs graphs\n\nA loop is one unit of self-improvement:\n\nThat's the atom. One agent, one metric, cycling until it converges.\n\nLoops have a known failure mode: they optimize exactly what you measure and nothing else. A support bot tuned to close tickets fast will close tickets fast - while satisfaction quietly craters. The loop can't see outside its own metric. That's Goodhart's Law showing up in your agent architecture.\n\nA graph fixes this by design. Instead of one loop chasing one number, you build a network of loops that watch and correct each other. Node A's output feeds Node B. Node C runs independently and checks both. No single metric drives the whole system - the structure does.\n\n![](https://pbs.twimg.com/media/HNzlYS5XMAAqnxh.png)\n\nFor agent systems this means one concrete shift: stop writing one agent that does everything top to bottom. Design the shape of the work first - what has to happen before what, what can run at the same time, what actually needs to wait.\n\n# Chapter 2 - Nodes, edges, and the test that separates them\n\nA graph has exactly two components:\n\nNode - one unit of work. One agent, one job, one input, one output.\n\nEdge - a real dependency. Node B's input requires Node A's output.\n\nThe mistake almost everyone makes: treating \"and then\" as an edge by default.\n\nAsk one question for every \"and then\" in your workflow:\n\n> Does the next step actually read the previous step's output?\n\nIf yes → real edge. Keep the sequential order.                                                                      If no → no edge. The wait is wasted. Run them in parallel.\n\nIf no data crosses the boundary between two tasks, they're independent — and every independent pair you're running sequentially is runtime you're throwing away for free.\n\nHere's the test applied in code:\n\nYour current \"do A, then B, then C\" agent is technically already a graph. It's just the worst possible one - a single chain where if C stalls, nothing downstream ever runs.\n\n# Chapter 3 - Building your first graph\n\n![](https://pbs.twimg.com/media/HNzmfHDXEAAwZRi.png)\n\nRequirements:\n\n- Claude Code (recent version with Dynamic Workflows support).                             \n\n- Max, Team, or Enterprise plan - workflows on by default. On Pro, enable manually.\n\nOpen a real repository. Not a toy example - the payoff only shows up at real scale.\n\nThe prompt that kicks off your first graph:\n\nNotice the structure embedded in the prompt itself: parallel work explicitly called out, the one real dependency (consolidation waiting on all checks) explicitly named. You're not hoping the agent infers the graph - you're describing it.\n\nWhat happens under the hood - a simplified version of the orchestration:\n\n40 sequential API calls at ~8 seconds each is over 5 minutes. The same 40 calls fanned out in parallel: under 15 seconds, bounded by your slowest single file, not the sum of all of them.\n\n# Chapter 4 - Where graphs actually break\n\nGraph engineering fails in three predictable places. Know them before you hit them.\n\nContext collapse. Fan out 1,000 nodes and try to feed all 1,000 outputs into one consolidation step, and you'll blow past any context window before synthesis even starts.                                                                                                                Fix: layer your fan-in. Group nodes into batches of 20-50, summarize each batch, then consolidate the summaries - not the raw outputs.\n\nFalse independence. You'll assume two nodes are independent because their prompts don't reference each other - but they both write to the same file, or hit the same rate-limited API. That's a hidden edge. Fix: audit for shared resources, not just shared data. Two nodes with a write conflict need an edge even with zero data dependency.\n\nSilent node failure. In a chain, one failure stops everything - annoying but obvious. In a graph, one failed node among 200 can vanish into a report that looks complete. Fix: every fan-in step checks node count against expected count before synthesizing, and flags gaps explicitly instead of quietly working with partial data.\n\n# Chapter 5 - Scaling to a real fleet\n\n![](https://pbs.twimg.com/media/HNzns5_XcAAWnfv.png)\n\nOnce the pattern works at 40 nodes, scaling to hundreds is a config change, not a redesign - provided you built the graph correctly from Chapter 2 onward.\n\nThe full production shape:\n\nThe orchestrator's only job: decompose the task into nodes, identify real edges, and dispatch. It does no work itself - it draws the graph.\n\nThis is the actual shift graph engineering represents: you stop being the person who writes every step, and become the person who designs the dependency structure. The agents fill in the nodes. You own the edges.\n\n# What changes when you think in graphs instead of lines\n\nA linear agent with 40 steps has 40 points of sequential failure and 40x the latency of its slowest single step.\n\nA graph with the same 40 units of work has as many points of parallel failure as you have real dependencies - usually 3 to 5 in most workflows - and latency bounded by your slowest layer, not your total step count.\n\nThat's not a marginal speedup. It's the difference between a workflow that takes 5 minutes and one that takes 15 seconds, running the exact same underlying work.\n\nThe model was never the bottleneck. The line you drew was.\n\nThis is a technical breakdown of multi-agent orchestration patterns as of July 2026. Code examples are illustrative - adapt error handling, rate limiting, and retry logic to your production environment before deploying at scale.\n\nThank you for reading."},"adhxContext":{"savedByCount":1,"publicTags":[],"previewUrl":"https://adhx.com/0xWast3/status/2079899723947712845"}}