{"id":"2081089131808243999","url":"https://x.com/akshay_pachaar/status/2081089131808243999","text":"","author":{"name":"Akshay 🚀","username":"akshay_pachaar","avatarUrl":"https://pbs.twimg.com/profile_images/1578327351544360960/YFpWSWIX_200x200.jpg"},"createdAt":"Sat Jul 25 18:48:08 +0000 2026","engagement":{"replies":18,"retweets":83,"likes":586,"views":95886},"article":{"title":"Graph Engineering Clearly Explained ","previewText":"Loop engineering got about six weeks in the spotlight before the timeline moved on.\nOn July 18, Peter Steinberger, the person behind OpenClaw, posted a nine-word question. \"Are we still talking loops","coverImageUrl":"https://pbs.twimg.com/media/HOGCCe-aUAAXzQF.jpg","content":"Loop engineering got about six weeks in the spotlight before the timeline moved on.\n\nOn July 18, Peter Steinberger, the person behind OpenClaw, posted a nine-word question. \"Are we still talking loops or did we shift to graphs yet?\"\n\n![](https://pbs.twimg.com/media/HOF0SHLbEAAfDBs.jpg)\n\nA few hours later, Hamel Husain published an article titled \"Loop Engineering Is Dead. Enter Graph Engineering.\"\n\n![](https://pbs.twimg.com/media/HOF0XAnacAAm-TD.jpg)\n\nBoth were at least half joking. The field renames itself so fast that mocking the renaming has become its own genre.\n\nBut the joke landed on something real. The moment you have several loops that need to work together, you have a coordination problem, and graphs are how engineers have always described coordination.\n\nThat's the whole idea behind graph engineering. Now let's separate the substance from the meme.\n\n# First, the graph itself\n\nA graph is three things.\n\n- Nodes are units of work, whether that's an agent, a plain model call, a deterministic function, a tool, or a human approving something.\n\n- Edges decide what runs next, either in sequence, in parallel, or conditionally based on what the last node produced.\n\n- State is a shared object that flows along the edges. Every node reads from it and writes to it.\n\nThis is the starter graph almost every example uses. A researcher gathers material, a writer drafts, a reviewer judges. If the review passes, the run ends. If it fails, an edge sends the draft back to the writer.\n\nThree nodes, four edges, and one of those edges is a loop.\n\nHere's the part that reframes everything. A single agent loop is just a one-node graph with an edge pointing back to itself. Graphs don't replace loops. They connect and govern them.\n\n![](https://pbs.twimg.com/media/HOF1N2SagAAzyPU.jpg)\n\n# The stack kept growing\n\nThe center of gravity in AI keeps drifting away from the model, and each shift picked up a name.\n\n- Prompt engineering. The words you send.\n\n- Context engineering. Everything the model sees, not just your instructions.\n\n- Harness engineering. The code around the model that runs tools, tracks state, and handles errors.\n\n- Loop engineering. The autonomous cycle that drives one agent toward a goal.\n\n- Graph engineering. The coordination layer across many loops, covering what runs when, in what order, and who checks whom.\n\nEach layer wraps the one before it. A graph is made of loops, each loop needs a good harness, each harness call is a context problem, and every context contains prompts. Skip a lower layer and the graph just fails in a more elaborate way.\n\n![](https://pbs.twimg.com/media/HOF74j8boAAI44E.jpg)\n\nOne more thing worth being honest about. None of this is new technology. LangGraph shipped this exact model, nodes and edges over shared state, back in January 2024. Microsoft's AutoGen has GraphFlow, and Google built ADK 2.0's entire workflow runtime on the same idea. The name is new, the practice isn't, which is why one of the top replies to Hamel's post was simply \"welcome back, langchain.\"\n\nSo the discipline isn't inventing graphs. It's knowing when to use one, and how to keep it from rotting. That part has four hard problems.\n\n# Hard part 1: knowing when a node deserves to exist\n\nThe most common failure is turning \"summarize this PDF\" into a five-node graph with a fetcher, a chunker, a summarizer, a reviewer, and a formatter.\n\nA node earns its place only if it represents a real specialty, meaning a different model, a different toolset, or a genuinely separate role like a read-only reviewer. Steps you could inline into an existing loop are not nodes.\n\nA useful filter comes from the practitioners writing about this. If you can't draw the graph on a napkin, it's too complex. And if collapsing two nodes into one loses nothing, they were never two nodes.\n\n# Hard part 2: keeping shared state clean\n\nIn a loop, the failure mode is context rot. In a graph, the same disease moves into shared state.\n\nEvery node writes to the state object, so a sloppy write in node two becomes a confident input for node five. Nobody notices until the output is wrong, and by then the bad data has flowed through half the system.\n\n![](https://pbs.twimg.com/media/HOF8slQaUAE4NOB.jpg)\n\nThe solutions are simple and boring, yet effective. Give the state a typed schema. Decide explicitly which nodes may write to which fields. Checkpoint state between nodes so you can replay a run and see exactly where it went bad.\n\nOne caution applies to replay. Nodes after a checkpoint execute again, so any node with external side effects, like sending an email or creating a record, must be safe to run twice.\n\n# Hard part 3: routing you can trust\n\nAn edge is a decision, and the question is who makes it.\n\nIf a model decides the route, you get flexibility and instability in the same package. The same state can take different paths on different runs, which makes debugging miserable.\n\n> Google's design rule for ADK 2.0 is the cleanest position in the discourse. Deterministic code should control predictable routing, and models should only handle the steps that need actual judgment.\n\nRoute with code wherever the condition is checkable, and spend model calls only where interpretation is genuinely required.\n\n# Hard part 4: agents agreeing with each other\n\nLoop engineering's sharpest rule was to never let an agent grade its own homework.\n\nGraphs raise the stakes. Twenty agents built on the same base model, reading the same flawed context, will happily agree with each other, and models measurably prefer their own outputs. \n\nThe result feels like an \"organized nonsense\" at industrial scale, impeccable structure wrapped around a wrong answer.\n\nThe fix is a reviewer node with teeth. Run it on a different model, give it fresh context instead of the full conversation, and anchor its verdict to evidence the graph can't fabricate, like tests that actually ran or code that actually compiled.\n\n![](https://pbs.twimg.com/media/HOF9QHTakAAy_hY.jpg)\n\n> Cognition landed in the same place after a year of running Devin, their coding agent. Their working setup lets several agents read the work and weigh in, but only one agent is ever allowed to change anything.\n\nThat split is the useful part. Reading is safe to do in parallel, because a bad opinion costs you nothing until someone acts on it. Writing is where the damage happens, so you keep it in one place where you can see it.\n\n# Where the graph is overkill\n\nThe honest answer is most of the time.\n\nAnthropic's published numbers make the cost concrete. A single agent burns roughly 4x the tokens of a chat interaction, and multi-agent systems burn roughly 15x. Every node you add multiplies that.\n\n![](https://pbs.twimg.com/media/HOGBHWcbMAAbXlV.jpg)\n\nThe ceiling is real when the task genuinely parallelizes. Anthropic's multi-agent research system outperformed a single Opus agent by 90.2% on their internal research eval, because research fans out into independent searches naturally. But their standing advice from Building Effective Agents hasn't changed. Find the simplest solution possible, and only add complexity when the task demands it.\n\n> Even LangGraph's own guidance says the quiet part. If your agent is a straightforward loop with tools, LangGraph is overkill.\n\nThe decision rule is pretty straightforward:  Reach for a graph when the work splits into genuine specialties, needs parallel fan-out and join, needs different models per step, or needs failure isolation and auditable routing. Otherwise stay in the loop.\n\n# Where to start\n\nYou don't need an org chart of agents on day one. Build up to it.\n\n- Master a single loop first, with brakes, a real completion check, and a critic. A graph of weak loops is just distributed failure.\n\n- Draw the graph on paper before writing code, and challenge every node to justify its existence.\n\n- Define the state schema and write access up front. State drift is the main way graphs rot.\n\n- Make the reviewer node a different model with fresh context, and anchor it to external evidence.\n\n- Put budget caps on every node. A graph is many loops spending tokens in parallel, and a weak verifier now burns money concurrently.\n\n# Key takeaway\n\nGraph engineering isn't a new discipline replacing loop engineering. It's the name that stuck for a decision every agent builder eventually faces. When one loop stops being enough, coordination becomes the engineering.\n\nThe word may not survive the year. The design question will.\n\nHere's a summary of key takeaways in graph engineering.\n\n![](https://pbs.twimg.com/media/HOGBSq1bUAAmkya.jpg)\n\nThanks for reading!\n\nCheers :)\n\nAkshay."}}