{"id":"2086784668003598356","url":"https://x.com/0xwhrrari/status/2086784668003598356","text":"","author":{"name":"rari","username":"0xwhrrari","avatarUrl":"https://pbs.twimg.com/profile_images/2029005608125431808/RHmOjHaB_200x200.jpg"},"createdAt":"Mon Aug 10 12:00:10 +0000 2026","engagement":{"replies":37,"retweets":164,"likes":971,"views":3906187},"article":{"title":"Graph Engineering: How to Build AI Agent Systems That Don't Break at Scale","previewText":"Most builders still design AI agents as a straight line\nResearch first\nWrite second\nReview third\nShip last\nEach step waits for the one before it, even when half of them never needed the previous","coverImageUrl":"https://pbs.twimg.com/media/HPUaW9FWUAE9PXe.jpg","content":"Most builders still design AI agents as a straight line\n\nResearch first\n\nWrite second\n\nReview third\n\nShip last\n\nEach step waits for the one before it, even when half of them never needed the previous result\n\nThe system does not branch\n\nIt does not parallelize\n\nIt does not know how to recover\n\nIt just keeps feeding one context window until the agent gets slow, confused, or expensive\n\nThe problem is no longer the prompt\n\nThe problem is the shape of the work\n\nThat is what graph engineering fixes\n\n> I publish practical breakdowns of AI agents, workflows, and production systems on Substack [Join the newsletter here](https://whrrari.substack.com/subscribe?next=https%3A%2F%2Fsubstack.com%2F%40whrrari%2Fnotes&utm_source=profile-page&utm_medium=web&utm_campaign=substack_profile&just_signed_up=true)\n\n## What graph engineering actually means\n\nGraph engineering is the practice of turning an agentic workflow into an explicit execution map\n\nInstead of hiding every decision inside one model loop, you define the system as nodes and edges\n\nA node can be an agent, a tool call, a deterministic function, a verifier, or a human approval step\n\nAn edge says what is allowed to run next and what data crosses the boundary\n\nThe graph decides which loops run, in what order, with which branches, joins, and recovery paths\n\n> A loop helps one agent improve its work A graph coordinates many loops into one system\n\n## 1. Stop treating every \"and then\" as a dependency\n\nMost agent workflows are linear because that is how people write instructions\n\nDo A, then B, then C\n\nBut sequence is not the same as dependency\n\nIf B does not consume A's output, there is no reason for B to wait\n\nThe first question in graph engineering is simple\n\n> Does the next step actually read the previous step's output\n\nIf the answer is no, cut the edge\n\nThat single change usually turns a slow chain into a fast parallel graph\n\n## 2. Give every node a contract\n\nA node you cannot describe precisely is a node you cannot route, test, or replace\n\nEvery useful node needs four things\n\n- One job\n\n- Explicit input\n\n- Structured output\n\n- A clear failure state\n\nFree text forces the next node to guess what happened\n\nStructured output turns a model response into something the graph can trust\n\nThis also makes nodes replaceable\n\nYou can swap the model, prompt, or tool without rebuilding the entire system as long as the contract stays the same\n\n## 3. Treat edges as data contracts, not arrows\n\nAn edge should not mean \"B comes after A\"\n\nIt should mean \"A produced data that B is allowed to consume\"\n\nThat distinction matters because most workflow plumbing does not need another model call\n\nFlattening arrays, removing duplicates, filtering nulls, checking a status, and joining records are deterministic operations\n\nNo agent is needed here\n\nSave model calls for judgment\n\nUse code for plumbing\n\n> A graph where every edge is another agent is paying tokens for its own wiring\n\n## 4. Learn the four shapes behind almost every agent graph\n\nYou do not need fifty patterns\n\nMost production graphs are combinations of four shapes\n\nThe chain\n\nUse it when every step genuinely requires the previous output\n\nIt is simple, predictable, and often slower than necessary\n\nThe diamond\n\nSplit one job into independent branches, run them together, then merge the results\n\nThis is the workhorse for research, code review, due diligence, and market scans\n\nThe router\n\nInspect state and choose only the path the task needs\n\nSmall work stays cheap\n\nRisky work gets a deeper graph\n\nThe controlled cycle\n\nRepeat only when evidence says the result is incomplete\n\nEvery cycle needs a hard stop, a budget, and a convergence rule\n\n![](https://pbs.twimg.com/media/HPU4_H3WYAAM-7_.jpg)\n\n## 5. Fan out independent work, then join it deliberately\n\nParallelism is the easiest graph advantage to understand and the easiest one to abuse\n\nIf five nodes are independent, run them together\n\nOne failed branch should not destroy the other four\n\nBut do not place a barrier after every stage\n\nA join is worth the wait only when the next node needs the complete set\n\nExamples include cross-source deduplication, ranking all candidates, comparing alternatives, or deciding whether coverage is complete\n\nIf each item can continue independently, keep the graph streaming\n\n> Parallel is not automatically fastYour topology decides where the system waits\n\n## 6. Make routing inspectable\n\nThe model can make a judgment\n\nThe graph should enforce what that judgment is allowed to trigger\n\nThe classifier is probabilistic\n\nThe allowed routes are deterministic\n\nThis gives you the model's flexibility without giving it unlimited control over the system\n\nOpenAI's visual Agent Builder makes this shift obvious: agent behavior is increasingly designed as an inspectable workflow instead of a hidden chain of prompts\n\n## \n7. Put verification on the edge\n\nThe highest-leverage node in a graph is often the one that produces nothing new\n\nIts job is to stop weak work from moving downstream\n\nA verifier can check\n\n- Whether every claim has a source\n\n- Whether the cited source supports the claim\n\n- Whether code passes tests\n\n- Whether the result matches the requested schema\n\n- Whether another independent path reaches the same conclusion\n\nDo not ask the same agent to generate, approve, and publish its own work in one context\n\nSeparate the roles\n\nSeparate the prompts\n\nSeparate the failure boundaries\n\nAnthropic's production research system follows this logic at a larger scale: a lead agent coordinates parallel subagents, findings are synthesized, and a dedicated citation stage attaches evidence before the result reaches the user\n\n![](https://pbs.twimg.com/media/HPU5FYiWgAA83Uo.jpg)\n\n## 8. State is the part most diagrams hide\n\nBoxes and arrows look clean until the system has to resume after a crash\n\nA production graph needs durable state\n\nDo not move giant transcripts between nodes\n\nMove references to artifacts\n\nA research node should store its report and return a path, ID, or structured summary\n\nA reviewer should read the artifact directly instead of receiving a compressed retelling through three agents\n\nThis reduces context loss and makes every transition auditable\n\nThe graph should be able to answer three questions at any moment\n\nIf it cannot answer them, the graph is still a demo\n\n## 9. Add cycles only when they converge\n\nA cycle is useful when the amount of work is unknown in advance\n\nBug discovery, deep research, and iterative repair are good examples\n\nBut \"repeat until good\" is not a stop condition\n\nUse measurable convergence\n\nNotice what the system remembers\n\nIt deduplicates against everything already seen, not only the findings that passed verification\n\nOtherwise rejected ideas keep returning and the graph pays to rediscover the same dead ends forever\n\nEvery controlled cycle needs\n\n- A completion test\n\n- A maximum number of rounds\n\n- A token or cost budget\n\n- A record of previous attempts\n\n- An escalation path when convergence fails\n\n## 10. Design failure as a local event\n\nIn a chain, one broken step can freeze the whole workflow\n\nIn a graph, failure should stay inside the smallest possible boundary\n\nEach node needs a policy\n\nCheckpoint after expensive nodes\n\nMake writes idempotent so a retry does not duplicate side effects\n\nGive parallel workers isolated workspaces when they modify files\n\nRecord every routing decision with the state that produced it\n\nReliability does not come from hoping every node succeeds\n\nIt comes from deciding what the graph does when one does not\n\n## 11. Topology is your cost model\n\nA graph is not automatically cheaper than one agent\n\nIt can burn far more tokens if every task spawns a fleet\n\nThe shape controls both latency and cost\n\nUse cheaper models for bounded extraction, classification, and formatting\n\nUse stronger models for decomposition, synthesis, and difficult verification\n\nRoute simple tasks through a short path\n\nReserve the full graph for work that earns it\n\nAnthropic reports that multi-agent research can materially outperform a single agent on breadth-first work, but it also uses far more tokens\n\nThat is the tradeoff\n\nGraph engineering is not about maximizing the number of agents\n\nIt is about spending coordination only where parallelism, specialization, or independent verification creates enough value\n\n## 12. A production graph for research and publishing\n\nHere is a practical graph for turning one idea into a cited article\n\nThe system works like this\n\n1. The scope node defines the question, audience, and completion criteria\n\n1. The decomposition node creates independent research lanes\n\n1. Research nodes run in parallel with separate contexts\n\n1. Deterministic code removes duplicates and normalizes sources\n\n1. The draft node writes from structured evidence\n\n1. The checker validates claims, citations, style, and missing sections\n\n1. Failed checks route only the relevant section back to repair\n\n1. A human approves the final artifact before publishing\n\nThis is not one giant agent pretending to be a team\n\nIt is a system with explicit ownership, state, and authority\n\n![](https://pbs.twimg.com/media/HPU5KdCWAAE7TKx.jpg)\n\nWhen a graph is the wrong answer\n\nDo not turn every prompt into an architecture diagram\n\nKeep one agent in one loop when\n\n- The task is short\n\n- One context can hold all relevant information\n\n- There are no independent branches\n\n- Failure is cheap\n\n- A human can review the final result quickly\n\nMove to a graph when\n\n- Work can run in parallel\n\n- Different nodes need different tools or permissions\n\n- Outputs require independent verification\n\n- The task must resume after interruption\n\n- Several loops need shared state\n\n- Cost and authority must be controlled by route\n\nStart with one loop\n\nDraw a graph only when the dependencies force you to\n\n## The graph engineering checklist\n\nBefore you ship, ask\n\nIf the answer to the last question is no, delete nodes\n\n## The real shift\n\nPrompt engineering improves the instruction\n\nContext engineering controls what the model sees\n\nHarness engineering builds the environment around the model\n\nLoop engineering makes one unit of work improve through feedback\n\nGraph engineering coordinates the entire job\n\nThe model is only one node\n\nThe product is the system around it\n\n> A prompter asks the agent to do more An architect redesigns the graph so the system can do more safely\n\n## Keep reading\n\n- [The Three Layers Behind Reliable AI Agents: Harness vs Loop vs Graph Engineering](https://x.com/0xwhrrari/status/2082096897964306572)\n\n- [How I set up Obsidian + Claude as my second brain](https://x.com/0xwhrrari/status/2063231716974584157)\n\n- [How I set up Claude to actually get work done](https://x.com/0xwhrrari/status/2060017822172864745)\n\n- [How I set up Claude projects so they actually work](https://x.com/0xwhrrari/status/2064288737442365925)\n\n- [30 Claude system prompts I actually use](https://x.com/0xwhrrari/status/2065012527864430730)\n\n- [Loop Engineering: The AI skill every builder needs in 2026](https://x.com/0xwhrrari/status/2065539680146182270)\n\n- [30 Claude Code settings, shortcuts & workflows most users miss](https://x.com/0xwhrrari/status/2070865993811820915)\n\n- [How I Use Claude Cowork to Run Like a One-Person Company](https://x.com/0xwhrrari/status/2071337983899271175)\n\nFor shorter notes, new tools, and AI systems I am testing\n\n[Join my Telegram](https://t.me/+qqS3Qn-x1305ZmUy)\n\nFor deeper breakdowns delivered directly\n\n[Subscribe to my Substack](https://whrrari.substack.com/subscribe?next=https%3A%2F%2Fsubstack.com%2F%40whrrari%2Fnotes&utm_source=profile-page&utm_medium=web&utm_campaign=substack_profile&just_signed_up=true)\n\n## If you read this far\n\nBookmark the article so you can use the patterns later\n\nFollow @0xwhrrari for more practical AI systems\n\nAnd send this to a builder who is still forcing every agent through one long chain"}}