{"id":"2082442856417956173","url":"https://x.com/Mahaximus_/status/2082442856417956173","text":"","author":{"name":"Mahax","username":"Mahaximus_","avatarUrl":"https://pbs.twimg.com/profile_images/2054577237463126016/qf-_Y1uF_200x200.jpg"},"createdAt":"Wed Jul 29 12:27:21 +0000 2026","engagement":{"replies":16,"retweets":74,"likes":530,"views":1950504},"article":{"title":"Graph Engineering with Claude. What It Is and How to Actually Use It","previewText":"A few weeks ago the whole AI field was talking about loops. Then graphs showed up on everyone's timeline and loops were suddenly old news overnight.\nThe shift happened fast. But most of what gets","coverImageUrl":"https://pbs.twimg.com/media/HOVxJdDWIAEWu_d.jpg","content":"A few weeks ago the whole AI field was talking about loops. Then graphs showed up on everyone's timeline and loops were suddenly old news overnight.\n\nThe shift happened fast. But most of what gets posted about graph engineering is either too vague to be useful or too technical to actually follow. Nobody explains what a graph actually is before they start telling you to build one.\n\nBy the end of this article you will know what a graph actually is, how to recognize one hiding inside your current workflow. The single pattern that makes them powerful, where they quietly fail, and how to build one yourself with Claude in a couple of minutes.\n\n##                         What a graph actually is\n\nMost people hear \"graph\" and think of a chart with bars or lines. That's not this. A graph in the context of AI work is simpler than it sounds: it's a map of which jobs need to happen and what each one depends on.\n\nTwo things make up the whole thing.\n\nA node is a unit of work. One agent, one task, one thing going in and one thing coming out. Not \"research everything about this topic and then write a summary and also check the sources.\" Just one of those. The smaller and more defined the job, the more useful the node.\n\nAn edge is a dependency. It connects two nodes when the second one genuinely needs what the first one produced. Not \"these two things happen in sequence.\" Only when the output of one actually feeds the input of the other.\n\n![](https://pbs.twimg.com/media/HOVfttcXYAAscNA.jpg)\n\nThat's it. Nodes do the work. Edges carry what moves between them. Everything else in graph engineering is just applying those two ideas at different scales.\n\n##      Your current workflow is already a graph\n\nHere is the thing most people miss when they first hear about graph engineering: you are already doing it. Just badly.\n\nWhen you write a prompt like \"research this topic, then summarize what you find, then write a draft based on the summary\" - that is a graph. A single unbranching chain where every step waits for the one before it to finish. One head, one line, one thing at a time.\n\nIt runs correctly. It also runs slowly, and it breaks easily. If the summary step produces something unusable, the draft step fails. If the research step takes too long, everything behind it waits. A chain has no redundancy and no flexibility - it is the simplest possible graph, and simple is not the same as efficient.\n\nThe first move in graph engineering is not learning something new. It is looking at what you already have and asking: does every step actually need to wait for the one before it? Because most of the time, it doesn't.\n\n❌ Linear chain:\n\n> Research → Summarize → Write → Check sources → Format → Publish\n\nSix steps in a line. Each one waiting. Total time: the sum of all six.\n\n✅ Redrawn as a graph:\n\n> Research + Check sources (run at the same time) → Summarize → Write + Format (run at the same time) → Publish\n\nSame work. Less waiting. Finishes faster because independent jobs stop queuing behind each other.\n\n##                              The fake-edge test\n\nOnce you can see your workflow as a graph, the next move is finding the edges that shouldn't be there.\n\nLook at your current workflow step by step. At each arrow, ask one question: does this step actually need the result of the one before it? Not \"does it come after it\" - does it genuinely use what the previous step produced?\n\nIf yes, the edge is real. Keep the order.\n\nIf no, there is no edge. Those two jobs have nothing to do with each other and the wait between them is pure waste.\n\nTake a simple example: \"review file A for bugs, then review file B for bugs.\" It reads like a sequence. But the review of file B never looks at what file A returned. They only run one after the other because that is the order you typed them in. Run them at the same time and the whole thing finishes in the time of the slower one - not the two added together.\n\nRun this test on any workflow in under five minutes:\n\n1. Write out every step as a box\n\n1. Draw an arrow between each pair of consecutive steps\n\n1. For each arrow, ask: does data from step A actually go into step B?\n\n1. If yes - keep the arrow. Real dependency\n\n1. If no - delete the arrow. That's a fake edge\n\n1. Everything with no incoming arrow can start immediately\n\n1. Everything with no outgoing arrow is a final output\n\n> You will find two or three fake edges in almost any workflow you draw. Each one is time you are giving away for free.\n\n##                                     The Diamond\n\nOnce you start removing fake edges, one pattern shows up more than any other. It's called the diamond and it's the shape that makes graphs worth using.\n\nThe idea is simple. One node fans out into several parallel nodes. Those parallel nodes all feed into one final node that pulls their outputs together. Draw it out and it looks like a diamond.\n\n![](https://pbs.twimg.com/media/HOVmhU6WQAA9iEi.jpg)\n\nHere is what that looks like in practice. Say you are researching a topic to write about. The linear version looks like this: search → read source 1 → read source 2 → read source 3 → synthesize.\n\nThe diamond version: search → [read source 1 + read source 2 + read source 3 in parallel] → synthesize.\n\nThe final synthesis node gets the same inputs either way. But the time it waits is the length of the slowest source read - not all three added together.\n\nThe diamond works because synthesis genuinely depends on all three reads. Those are real edges. But the three reads have no dependency on each other. Those connections don't exist. So you run them at the same time and the only wait is at the end, where the wait is unavoidable anyway.\n\nThis is why the diamond shows up everywhere once you start looking. Research pipelines. Code review. Market analysis. Any time you have a \"gather from multiple places, then combine\" shape in your work, you have a diamond. The gathering is parallel. The combining is the convergence point.\n\nThe pattern has two rules. First, the parallel nodes must be genuinely independent - no fake edges disguised as real ones. Second, the convergence node must actually need all of them. If it only needs one, the others are wasted work.\n\nGet both of those right and the diamond is the fastest shape a workflow can take.\n\n##                       Where graphs quietly fail \n\nThe diamond is clean in theory. In practice it breaks in two specific places, and both are easy to miss.\n\nThe first is a bad node going undetected. When three sources run in parallel and one of them returns garbage - a hallucination, an empty result, a misread file, that bad output flows straight into your synthesis node alongside the two good ones. \n\nThe synthesis node doesn't know one of its inputs is wrong. It combines everything and produces a confident answer built on bad material. The parallel structure that made things fast also removed the natural checkpoints where you would have noticed the problem.\n\nThe second is a cascade. In a linear chain, a bad step produces a bad output and you see it immediately. In a graph with converging paths, the bad output gets mixed with good outputs and the error becomes harder to trace. By the time the final node responds, the damage is diluted and invisible.\n\nBoth problems have the same fix: a checker node.\n\nA checker node sits between your parallel layer and your convergence point. Its only job is to evaluate each output before it moves forward. It doesn't synthesize, doesn't write, doesn't do any of the main work. It asks: is this output usable? If yes, pass it through. If no, flag it, retry, or drop it before it poisons the next step.\n\nThe five things a checker node should catch:\n\n1. Empty or null outputs - a node that returned nothing useful\n\n1. Outputs that contradict each other in ways that can't both be true\n\n1. Outputs that are off-topic relative to the original task\n\n1. Confidence signals that are too low to be reliable\n\n1. Format errors that will break the synthesis node's parsing\n\n> A graph without a checker node is a graph that assumes everything upstream worked. That assumption fails more often than you'd expect.\n\n##             Static graphs vs. dynamic graphs\n\nEverything so far has assumed you know the shape of your graph before you start. You define the nodes, draw the edges, and run it. That works for repeatable workflows where the structure doesn't change.\n\nBut a lot of real work doesn't fit that shape. You start a research task and discover halfway through that one source requires three additional lookups. You start a code review and find that one file needs deeper analysis than the others. The structure you needed wasn't knowable at the start - it only became clear once the work was underway.\n\nThat's where dynamic graphs come in. Instead of a fixed structure defined upfront, the graph builds itself as it runs. A node completes its work, looks at what it found, and decides what nodes should come next. The graph isn't planned - it's grown.\n\nThe difference matters in practice. A static graph is fast and predictable. You know exactly what will run, in what order, and how long it should take. A dynamic graph is flexible and handles the unexpected. But it's harder to debug when something goes wrong, because the structure that ran isn't the one you originally drew.\n\nKnowing which one you need before you start saves a lot of backtracking:\n\n1. Use a static graph when the task is repeatable and the structure is the same every time\n\n1. Use a static graph when speed and predictability matter more than flexibility\n\n1. Use a dynamic graph when the scope of the work depends on what you find along the way\n\n1. Use a dynamic graph when some nodes need to decide what comes next based on their output\n\n1. Use a static graph first, always - switch to dynamic only when you hit a wall the static version can't handle\n\n1. Never use a dynamic graph for anything where you need to audit exactly what ran and why\n\nMost workflows that feel like they need a dynamic graph actually just need a better-designed static one. The dynamic version is more powerful and harder to control. Reach for it second, not first.\n\n##        What the difference actually looks like\n\nTheory is easy to follow in the abstract. Here is the same task run two ways so you can see what actually changes.\n\nThe task: analyze three competitor products and write a comparison.\n\nWithout a graph:\n\nResearch competitor A → Research competitor B → Research competitor C → Compare all three → Write draft → Check facts → Format output\n\nSeven steps, all sequential. Total time is the sum of every step. If step two takes longer than expected, everything behind it waits.\n\nWith a graph:\n\n[Research A + Research B + Research C] → Checker node → Compare → [Write draft + Format output] → Final check\n\nFive logical stages. The three research steps run at the same time. The write and format steps run at the same time. The checker catches bad research before it reaches the comparison. Total time collapses.\n\nThe output is the same. The structure is not.\n\nHere is where each approach wins and loses:\n\nThe table makes it look like graphs win everywhere except setup and debugging. That's roughly true for anything you run more than once. For a one-off task you'll never repeat, the linear version is almost always faster to build and run.\n\nThe graph is worth it when the task is big enough that the time savings compound, or when errors in the middle are expensive enough that the checker node pays for itself.\n\n##                   How to build one with Claude\n\nEverything above is still just a mental model until you give Claude something it can execute. This is where it becomes practical.\n\nClaude Code has a workflow keyword that changes how it processes your instructions. Without it, Claude reads your prompt as a sequence and runs each step one after another. With it, Claude parses the structure, identifies which nodes have no dependencies on each other, and runs those in parallel automatically. You describe the graph. Claude figures out the execution order.\n\nA basic workflow looks like this:\n\n![](https://pbs.twimg.com/media/HOVraK_XcAEtkR4.jpg)\n\nThree things to notice. First, research_a, research_b, and research_c have no depends_on - Claude runs all three at the same time the moment the workflow starts. Second, checker lists all three as dependencies, so it waits until all three finish before it runs. Third, compare depends only on checker, not directly on the research nodes - the checker is the gatekeeper\n\nThat depends_on line is the only thing you need to understand to design any graph. No dependencies means parallel. A dependency means wait. Everything else is just deciding which nodes need what.\n\n##                      Ready-to-paste prompts\n\nThe workflow syntax from the last section works across any repeatable task. Here are four you can drop straight into Claude Code and adapt.\n\nCompetitive research:\n\nMulti-file code review:\n\nArticle research and draft:\n\n> Replace anything in brackets. The structure stays the same regardless of what you put inside the nodes.\n\n##        What changes when you think in graphs\n\nThe workflows in the last two sections are useful immediately. But the bigger shift is what happens after you use them for a few weeks.\n\nYou stop reading a task as a list of things to do and start reading it as a set of dependencies. The first question stops being \"what do I do first?\" and becomes \"what actually needs to wait for what?\" Most of the time the answer is: less than you assumed.\n\nThe change shows up in how you write prompts too. A linear prompt tells Claude what to do in order. A graph prompt tells Claude what each piece needs and lets it figure out the order. That's a smaller prompt, easier to edit, and it doesn't break when you swap out one node.\n\nThe last thing worth adding to any workflow you run more than twice is a CLAUDE.md entry. This tells Claude how you want graphs handled in that project - your defaults for output format, checker behavior, and error handling, so you don't rebuild that context every session:\n\n> One file, set once. Every workflow you run in that project inherits it.\n\nThe graphs you draw now will look obvious in six months. Not because they were easy - because once you see dependencies clearly, you can't unsee them. The linear version of any workflow starts to look like what it is: a graph with all its edges faked.\n\nAt the start of this article I said most of what gets posted about graph engineering is either too vague or too technical. I meant it, and I tried to thread the gap.\n\nYou now know what a graph is. You know how to find the one hiding inside your current workflow. You know the fake-edge test, the diamond, the checker node, and when to reach for a dynamic graph instead of a static one. You have the syntax to build one in Claude Code and four prompts you can use today.\n\nThat is the whole thing. There is no deeper layer of graph theory you need before any of this is useful.\n\nThe one thing I'd push back on if someone told me not to include it: the fake-edge test. Run it on one workflow this week. Just one. Draw out the steps, go through the arrows, and ask which ones are actually carrying data. You will find at least one that isn't.\n\nThat's the moment the whole model clicks. Not when you understand the theory - when you find the first fake edge in something you built yourself and realize you've been waiting on it for months.\n\nThe rest follows from there."},"adhxContext":{"savedByCount":1,"publicTags":[],"previewUrl":"https://adhx.com/Mahaximus_/status/2082442856417956173"}}