# Graph Engineering ## What it is Graph engineering is designing the *network* of feedback loops that drive a system, instead of designing a single loop. [[Peter Steinberger]] posted nine words on 18 July 2026 that got three million views: "Are we still talking loops or did we shift to graphs yet?" It was a joke, and it needed no explanation to anyone building agents, which is exactly why it landed. Within hours Hamel Husain posted "Loop Engineering Is Dead. Enter Graph Engineering." A field recognized itself mid-stride, one foot on the pattern it was leaving. The claim underneath the meme: the unit of design is no longer the cycle. It is the network of cycles. ## Two different things called "graph" The word got attached to two distinct ideas in the same week. Keeping them apart is the first job. **Graph as topology of control** ([[Carlos E. Perez]]'s framing, the substantive one). A graph of *improvement loops* that watch, feed, constrain, and veto one another. Governance and reliability, in other words. Everything below is about this version. **Graph as topology of execution** (the orchestration framing). Replacing a straight chain of agent steps with a DAG: parallel branches, fan-out, joins, conditional edges. Codez's "Graph Engineering with Claude: 14-step roadmap" runs on this reading, and points at [[Andrew Ng]]'s one-hour course on agentic knowledge graphs (built with Google ADK) as the canonical build-along. Useful, but it is [[AI Agent Orchestration]] with a new label, not a new discipline. The two overlap only incidentally. A perfectly parallel execution DAG can still have exactly one blind optimizing loop at its heart. ## Why the single loop breaks Perez's essay is built on four named failure modes, and each one is a consequence of the loop's *shape*, not of bad execution. **[[Goodhart's Law]].** A support team built a feedback loop on ticket resolution rate. The number climbed for five months. Then renewals came in and churn had doubled: the bot had learned to resolve tickets by deflecting them, closing conversations fast and marking abandoned problems solved. The loop was not malfunctioning when it gamed its own measure. A loop can only see its metric, so it will find every way to move that metric, including the ways that betray the metric's purpose. **Blindness upward.** A loop drives a variable toward a reference, but nothing inside the loop can ask whether the reference is right. A thermostat cannot wonder whether 68 degrees is correct. An eval loop cannot question whether the benchmark measures anything a customer feels. Somebody set that target, often long ago, often by instinct. The harder the loop works, the more thoroughly a wrong target gets achieved. **Conflict.** Real systems contain many loops, and loops built independently fight. Speed undermines thoroughness. Hiring for growth strains the culture loop. A single-loop mindset has no vocabulary for the collision, because each loop, examined alone, is working fine. **Measurement decay.** Sensors drift, pipelines rot, definitions shift under the metric while the dashboard stays green. Worst case, measurement slides from checking reality into checking paperwork: one report confirmed against another report. A loop that runs on schedule while its measurements have detached from the world is theater with good attendance. ## How the graph answers them Every answer is topological. Change the wiring, not the loop. **Pairing answers Goodhart.** Every optimizing loop gets a watching loop on a counter-metric that catches the cheap way to win. Resolution rate paired with renewal rate. Speed paired with error rate. A metric must never travel alone. **Hierarchy answers blindness upward.** A slower loop owns the faster loop's reference. Revising targets becomes a governed cycle instead of an accident of whoever set them first. **Arbitration answers conflict.** A loop above the fighting loops owns the trade-off explicitly, rather than letting the collision resolve by whoever pushes hardest. **Audit loops answer measurement decay.** Loops whose only function is to check, periodically and independently, that the other loops' numbers still touch the world. **Speed separation is the fifth rule.** Fast loops must not be able to thrash what slow loops steward. A well-governed company is a graph of loops at different tempos: daily standups inside quarterly planning inside annual audit inside the board asking whether the targets are still the right targets. MLOps grew the same shape incident by incident: champion-challenger gating, drift monitors, automatic rollback, and a held-out evaluation set the training loop is never allowed to see. That last one is the purest example of the pattern. It is a deliberately blinded loop whose entire job is catching the optimizing loop gaming its own test. The reliability lives in the edges, not the nodes. Which loop feeds which, which watches which, which can veto which. ## The execution graph, done properly The execution reading stays the shallower of the two, but it acquired a real curriculum in late July 2026, and dismissing it wholesale would cost you the practical part. Anatoli Kopadze's article (1M views, 24 July) is the best teaching artifact the wave produced. What follows is the useful core of it. **The vocabulary is two words.** A **node** is one job: one agent, one task, one input, one output. An **edge** means one job needs what another produced. Nodes do the thinking, edges carry results. That is the whole vocabulary. **A node is only wire-able if it has a contract.** One bounded job, a defined input, a defined output, schema enforced. A node that returns a wall of free text is a node only a human can read, so the next node has to guess. Reject and retry on schema violation. **The fake-edge test is the single most actionable idea in the whole wave.** Walk your current workflow step by step and ask one question at each step: does this step actually need the result of the one before it? If yes, the edge is real. If no, there is no edge, and the wait is pure waste. "Review file A for bugs, then review file B" reads like a sequence, but B never looks at A's output. They run in series only because that is the order you typed them. You will find two or three fake edges in almost any workflow you draw. **Your linear workflow is already a graph, just the saddest one.** "Do A, then B, then C" is a graph where every node has one arrow in and one out. A 40-step chain has 40 sequential failure points and the latency of all 40 added together. The same 40 jobs with only their real dependencies (usually three to five) finish at the speed of the slowest layer. Same work, same model. The line you drew was the bottleneck. **The diamond is close to the only pattern you need.** Its formal name is **fan out, reduce, synthesize**. Fan out for breadth, reduce with plain code (no model, no tokens), synthesize with one final agent. Claude's own research feature runs this in production: a lead plans the angles, workers gather in parallel, findings get checked, one report reaches you. Once you see the diamond you stop asking "how do I make my agent do more steps" and start asking "where is the split, where is the merge." **The checker is the whole trick, and it needs a clean context.** Never let the agent that did the work check the work. Put a separate node on the edge whose only job is to try to kill the finding. The catch almost everyone misses: give that checker the worker's chat and it is not checking, it is nodding along to 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, only later and pricier. Then split the checking three ways, because three different lenses catch what ten identical ones miss: 1. Is it correct? Does the claim hold up 2. Is it current? Is the source recent rather than stale 3. Is the source real? Does the link resolve to the claim it is cited for Keep the finding only on a majority verdict. ### Where execution graphs break Three failure modes, each with a cheap fix: - **Context collapse.** Fan out to a thousand nodes, then pour a thousand outputs into one synthesis step, and you blow the context window before synthesis starts. Fix: layer the fan-in. Batch, summarize each batch, combine the summaries, never the raw pile - **False independence.** Two nodes look independent because their prompts never mention each other, but they write the same file or hit the same rate-limited API. That is a hidden edge. Bun's team hit exactly this when they first fanned a large job across many agents in one shared workspace and the agents overwrote each other. Fix: isolated worktrees per worker, and audit for shared *resources*, not just shared data - **Silent node failure.** In a chain one failure stops everything, which is annoying but obvious. In a graph, one dead node among two hundred slips into a report that looks complete. Fix: every merge step counts its inputs against the number expected and flags the gap instead of quietly synthesizing on half the data ### When not to build one A graph buys breadth. It does not buy judgment. Skip it when the task is small or isolated, when you want to approve every step, when you do not yet know what you are looking for, or when the steps genuinely depend on each other. The tell is the fake-edge test itself. If you cannot find two jobs with no edge between them, there is no graph to build. It is a loop, and a loop is fine. ## Four primitives, from outside software Shann Holmberg's marketing-side framing is worth keeping because it names a piece the coding-side versions leave implicit. Four parts, not two: - **Nodes**: a stage the work passes through. Some run once, some are their own loop the agent circles until that step clears - **Routes**: the paths drawn ahead of time, every direction the work is allowed to travel - **Checkpoints**: the check on each route that reads the result and sends the work forward, or back to an earlier node - **Gates**: a checkpoint the work cannot skip. Nothing publishes until the draft clears the rubric If you have built an n8n workflow you have already drawn one. An agent graph is the same shape, with each node holding an agent doing the work n8n would hand to a single API call. His worked example (research, brief, draft, score, publish, where score loops back to draft) makes the anchor problem concrete in a domain with no test suite: the critic can like the draft, the rubric can clear, the piece can publish, and it still never ranks. The loop was grading writing against another agent's opinion while the only thing that counts is whether Google indexed it, whether it climbs on the target query, whether AI answers cite it, and whether people stay once they land. Note where a stall sends the work: back to *research*, not to rewriting. A miss that late usually traces to the angle chosen at the start, and no rewrite fixes a wrong angle. ## Rails and motor Alex Prompter's compression is the cleanest way to hold graphs and loops in the same head: > Graph engineering is the rails. Loop engineering is the motor. Rails keep you from crashing. The motor is what actually moves you forward. Build the loop first when you want a task to improve without your input. Add the graph once you have handoffs, approval steps, or decisions you cannot afford to get wrong. His example: a support agent whose *loop* makes responses better over time, and whose *graph* routes any refund above $500 to a human. The failure he names is the mirror image of the one this note warns about: most people build only the graph, then wonder why their agent never gets smarter. ## The failure mode of graphs The meme stops before this part. Build the full graph (paired metrics, audit loops, meta-loops tuning the lower loops) and every one of those loops consumes reports. The audit loop checks operations numbers against finance numbers; finance numbers come from the systems operations feeds; the meta-loop tunes thresholds using dashboards built on all of it. Every loop watches another loop, and no loop touches the ground. That graph is circular: an elaborate network of mutual confirmation in which everything is consistent and nothing is verified. It fails exactly as the single loop failed, only later, more expensively, and with far more green lights on the way down. Topology buys sophistication. It does not buy contact with reality. So the graph needs three things no arrangement of edges can supply: - **Anchors.** Measurements that cannot be argued with. Revenue that landed in the bank. Tests that actually executed. Customers who actually stayed. The physical count that matches or does not. - **Frozen nodes.** Rules the optimizing loops are never allowed to tune, precisely because they are the rules an optimizer would be tempted to weaken. The held-out set, again. - **An external answer to "better."** Graphs revise references; they cannot generate the original judgment about which things are worth controlling at all, because every loop in the graph presumes it. That comes from people, through contact with real failures. Perez's own conclusion is that the durable axis was never loops versus graphs. It is **ungrounded versus grounded**. The single loop was how systems learned to get better. The graph is how they are learning to get better *without fooling themselves*. He also notes his one regret: "graph" was a poor word for a more nuanced phenomenon. ## Recommendations **Pair every optimizing metric before you ship the loop.** If you cannot name the counter-metric that catches the cheap way to win, you have not finished designing the loop. This is the cheapest change on the list and the one that would have caught the support team. **Name the owner of every reference.** Not the metric's owner: the *target's* owner. If nobody can say who set the number and when it gets revisited, the loop is optimizing toward a guess someone made once. **Give the graph at least one anchor that touches money, users, or physics.** Everything else is a report about a report. Write down which node it is. **Freeze the rules an optimizer would want to weaken, and say so out loud.** Held-out evals, safety checks, permission scopes. If they are tunable by the loop, they are decoration. **Separate tempos deliberately.** Decide explicitly which loop runs daily, which weekly, which quarterly, and forbid the fast one from editing what the slow one owns. **Put the audit loop under different ownership.** An audit loop reporting to the team it audits is a paired metric in name only. Independence is structural, not attitudinal. **Do not confuse a parallel DAG with a control graph.** Fanning agents out across a repository is a topology you deploy inside a loop, not a graph of loops. Ask what watches what before claiming you have graduated from loop engineering. **Run the fake-edge test tonight, before you touch any new tool.** Draw the workflow you already run, find the edges that carry no data, delete them. It costs nothing and it is the highest-return move in this entire note. **Never let a worker and its verifier share a context.** If you take one rule from the execution side, take this one. The moment they share, you are back to one loop grading its own homework with a bigger bill. **Cap the first run, then widen.** Put an explicit limit on the first pass (20 files, 5 angles) so you can watch what a run costs before deciding it earned a wider one. ## Tips and tricks **The graph is not new, only newly named.** Biology has run it forever: thermoregulation is a mesh of interacting reflexes, the immune system is essentially an audit loop over the whole organism, and slow developmental processes reset what the fast loops defend. Control engineering and corporate governance both converged on the same shape independently. Convergence that broad tells you the pattern is real. It also tells you the AI framing is mostly new branding on old engineering. **Expect the graph hype to fail the same way loop hype did.** The safe prediction is that "why one metric is never enough" becomes conference-talk canon. The deeper prediction, following the pattern of the essay itself, is that graphs of loops will fail circularly and plausibly wherever they are built without anchors, and the discourse will lurch again. **Steinberger's joke is doing real work.** It landed because practitioners had already hit the ceiling of single-loop design and had no word for what came next. Treat the meme as a symptom, not a discovery. **The critique that applies to loops applies twice to graphs.** If one stochastic component generates output and another stochastic component reviews it, adding a third stochastic component to watch the reviewer is not control. It is recursion with a bigger dashboard. See the control-theory pushback recorded in [[Loop Engineering]]. **Graph-max: draw it, then hand it over.** Alex Kotliarskyi's method needs no framework. Draw the graph in any tool, even on paper, then tell a coding agent to write a code-mode script implementing that workflow and run it with your inputs. There is no step three. This works because the coordination lives in code rather than in conversation, so passing results between agents costs no extra context. [[GPT-5.6]]'s programmatic tool calling and Claude Code's dynamic workflows are both built for exactly this shape. **In Claude Code, the trigger word is `ultracode`.** Put it in the prompt and Claude writes an orchestration script and spawns a coordinated fleet rather than working through a single line of steps. Write the spec as goal, fan-out, verify, cap, on-fail, report. See [[Claude Code]]. **Three people arrived at anchors independently, from three domains.** [[Carlos E. Perez]] from control theory, Kopadze from coding agents, Holmberg from SEO. None of them cite each other, and all three land on the same conclusion: topology alone does not buy truth, so the graph needs measurements that cannot argue back. When people reasoning from unrelated starting points converge that hard, the finding is load-bearing rather than fashionable. **The bill is the part demos leave out.** The public example is the Bun runtime rewrite: roughly 535,000 lines of one language into over a million lines of another, in about eleven days, using around 50 workflows with up to 64 agents at once. It also cost roughly $165,000 in usage, needed a human designing and watching throughout, and drew real criticism over whether that much AI-written code can be reviewed safely. A graph can chew through work no single context could hold. It can also spend your money quietly in the background if you point it at the wrong task. **Watch the word "agentic knowledge graph."** In the Ng/ADK sense it means using a knowledge graph as retrieval substrate for agents. That is [[Knowledge Graph (KG)]] work, adjacent to but distinct from either sense of graph engineering. ## References - Peter Steinberger on X, the nine-word post that started it (2026-07-18) — https://x.com/steipete/status/2078277297791189132 - Carlos E. Perez, "From Loop Engineering to Graph Engineering?" (2026-07-18) — https://x.com/IntuitMachine/status/2078419526354378975 - Carlos E. Perez, related earlier thread — https://x.com/IntuitMachine/status/2068808668393451770 - Hamel Husain on X, "Loop Engineering Is Dead. Enter Graph Engineering" (2026-07-18) — https://x.com/HamelHusain/status/2078346425621237935 - Codez on X, on Andrew Ng's agentic knowledge graphs course and the "14-step roadmap from 0 to graph architect" (2026-07-20) — https://x.com/0xCodez/status/2079234800766816633 - QPT on loops (YouTube) — https://www.youtube.com/watch?v=53Y3SYR5vTU - Anatoli Kopadze, "Graph Engineering explained: what it is, when to use it and when not to" (2026-07-24, ~1M views) — https://x.com/AnatoliKopadze/status/2080668775796314331 - Anatoli Kopadze on the Anthropic engineer's 25-minute breakdown of parallel agents that check each other's work (2026-07-24) — https://x.com/AnatoliKopadze/status/2080702441809399834 - Shann Holmberg, "graph engineering explained (marketing edition)" (2026-07-22) — https://x.com/shannholmberg/status/2079896903186260259 (quote-tweets his own earlier "what's the difference between a loop and a graph?" post from 2026-07-20) - Alex Prompter, the rails-and-motor framing (2026-07-24) — https://x.com/alex_prompter/status/2080683022123470853 - Alex Kotliarskyi, "How to graph-max with Codex and 5.6 Sol" (2026-07-25) — https://x.com/alex_frantic/status/2080776965070496115 - Dex Horthy, "Why Software Factories Fail" — the counter-argument that topology cannot fix a model-training problem (2026-07-24) — https://x.com/dexhorthy/status/2080697380379427275 ## Related [[Loop Engineering]] · [[Goodhart's Law]] · [[Harness Engineering]] · [[Agentic loops]] · [[Feedback Loop]] · [[AI Agent Orchestration]] · [[AI Verifiability]] · [[AI Guardrails]] · [[AI Observability]] · [[Knowledge Graph (KG)]] · [[Agent System Engineering]] · [[Human-in-the-Loop]] · [[Agentic Engineering]] · [[Goal Engineering]]