A post went around in late July about drawing your agent workflow as a graph. The recipe was three lines long. Draw a graph, in any tool, even on paper. Send it to a coding agent and ask it to write a script that implements the workflow. There is no step three. It reached several hundred thousand people in two days, and the most-liked reply under it was four words long: how is this not a loop?
Graph engineering is the practice of deciding an agent workflow's control flow before the agent runs, by drawing the workflow as a graph and generating the orchestration code from that drawing. It matters because control flow decided at authoring time costs nothing per run, while control flow decided at inference time is billed on every iteration forever. What separates it from an agent loop is not the shape of the work but the moment the routing decision gets made.
Nobody answered that four-word reply properly, and I have been sitting with it for a few days, because I think it is the most useful thing anyone said in that entire thread. It is not a gotcha. It is the actual design question, and the answer turns out to be precise rather than philosophical.
Table of Contents#
- What is graph engineering, exactly?
- How is a graph different from a loop?
- Why did this become a conversation in July 2026?
- What does each pattern actually cost?
- When should you still choose a loop?
- How do you draw a graph that survives production?
- What goes wrong with graph engineering?
- Should you adopt this now?
- FAQ
What is graph engineering, exactly?#
The name is doing something slightly annoying, because it collides with two other things people call graphs. It is not knowledge graphs, and it is not graph databases. If you want the retrieval version of graphs, I wrote about knowledge graphs as a context retrieval layer separately, and this is a different subject entirely.
Graph engineering here means the control plane. The nodes are units of work, usually model calls or tool calls. The edges are the transitions between them. The claim is that for a large class of agent workflows, you already know what the nodes and edges are before you run anything, and writing them down explicitly is cheaper and more reliable than asking a model to rediscover them on every execution.
The workflow part is not new. Orchestration frameworks have modelled agent execution as state graphs for a while now. What is new, and what made the July post travel, is the authoring step. You do not write the graph in a framework's DSL. You draw it, badly, in whatever tool is nearest, and hand the drawing to a coding agent that turns it into a running script. The drawing is the spec. That is a real shift, because the expensive part of graph orchestration used to be expressing the graph, and that part just got very cheap.
How is a graph different from a loop?#
How is this not a loop?
Here is the answer to that reply, and I think it is genuinely clarifying once you see it.
A loop is a graph. It is a graph with one node and an edge pointing back at itself. The person asking how a graph differs from a loop is right that the topology is not the distinction, and anyone who answers by drawing boxes is missing the point.
The distinction is when the routing decision happens.
In a loop, the model decides what to do next, during inference, every single iteration. It reads enough state to orient itself, reasons about what remains, and picks an action. That reasoning is real work, and you are billed for it in tokens on every pass. The routing logic lives inside the model's head and exists only during the run.
In a graph, you decided the routing when you drew it. The model still does the work inside each node, but it does not choose what happens next, because the edges are code. You paid for that decision once, in the twenty minutes you spent drawing, and you never pay for it again.
That is the whole thing. Everything else about the two patterns falls out of that single difference. Loops are adaptive and expensive. Graphs are cheap and rigid. Neither property is a virtue on its own.
There is a second consequence that I think is underrated. A drawn graph is a review artifact. A colleague can look at it and tell you that the retry edge is missing, or that two nodes could run in parallel, without reading a line of code and without scrolling through a transcript. Loops produce nothing a person can review at a glance. Their behaviour exists only in the run, which is one reason the observability gap hurts more in loop architectures than in graph ones. You cannot review a decision that was never written down.
Why did this become a conversation in July 2026?#
Two things happened at once, and the timing is not a coincidence.
The first is that coding agents got good enough at code generation that the translation step stopped being work. Drawing a workflow and getting a correct script out of the drawing used to require you to know an orchestration framework well. Now the drawing is close enough to the spec that a frontier model can bridge the gap reliably. The bottleneck moved from expressing the graph to deciding what the graph should be, which is a much better place for a bottleneck to live.
The second is that the field spent the previous year learning, expensively, that longer context does not solve orchestration. That lesson arrived through evidence rather than opinion. The Lost in the Middle work showed a U-shaped accuracy curve as relevant information moved through a long input, with models performing worst when the key content sat in the middle. Chroma's Context Rot study tested 18 frontier models and found consistent degradation as input length grew, well before the window was full.
Put those together and you get the current mood. If piling more into one context makes things worse, and the model's per-iteration routing reasoning is both expensive and unreviewable, then moving structure out of the context and into code starts to look obviously correct. Graph engineering is what that instinct looks like when someone writes it down as a recipe. The recipe went viral because it was three lines long, not because it was novel, and the four-word reply was the field noticing that the recipe skipped the interesting part.
What does each pattern actually cost?#
This is the part I care about most, because the cost structure is what should drive the decision and it almost never gets stated plainly.
| Pattern | Who decides the next step | Cache behaviour | Primary failure mode |
|---|---|---|---|
| One session | Model, continuously, with full history visible | Prefix stays stable, caches well by default | Accuracy decays as the transcript fills with noise |
| Loop | Model, every iteration, from a rebuilt context | Prefix changes unless deliberately pinned, so cache misses | Routing tokens compound, and reasoning is lost between turns |
| Graph | You, once, at authoring time | Per-node prefixes are stable and cache cleanly | The work needed a step or a branch you did not draw |
The cache column is where the money is. Prompt caching only works on an exact prefix match. Anthropic's caching documentation is explicit that cache hits require identical prompt segments up to the cached block, and advises putting stable content at the very beginning. A cache read costs roughly a tenth of the normal input price. That discount only exists if the prefix does not move.
A loop threatens that prefix by design, because each iteration rebuilds context from a different set of files in a different order. You can fix it, and the disciplined version of the pattern does exactly that by pinning the system prompt and the spec at the front and letting only the tail vary. But it is a thing you have to do on purpose, and skipping it converts a clever technique into the most expensive way to run an agent. I went through that mechanism in more detail in prompt caching in practice and in treating context as a cost lever, and both apply directly here.
A graph gets the stable prefix almost for free. Each node has its own prompt, that prompt does not change between runs, and caching works without anyone thinking about it. This is a real and underdiscussed advantage. The graph does not just save routing tokens. It also makes the remaining tokens cheaper, because the structure that stayed constant is now expressed in code rather than re-established in the prompt on every pass.
Then there is coordination overhead, which is the cost that surprises people. Multi-agent structures multiply token consumption substantially against a single agent on the same task, because context gets duplicated across agents and results get passed between them. That matters more than it sounds, because the reliability numbers do not improve to match. Carnegie Mellon's agent benchmark work found the best-performing agent completed roughly 30% of realistic office tasks, and chaining agents together drove end-to-end success rates down rather than up. You are paying considerably more for a structure whose success rate is lower than that of its parts. I unpacked that arithmetic further in when a swarm earns its cost.
When should you still choose a loop?#
Graphs are not the destination and loops are not a phase you grow out of. There is a clean test for which one you are in, and it takes one question.
Can you draw the workflow without running it?
If you can sketch the whole thing on paper before executing anything, you have a graph, and drawing it is cheaper than every alternative. If drawing it requires knowing what step three returns, you have a loop, and no amount of graph tooling will make the shape knowable in advance. This is the test I keep coming back to, because it is answerable in about a minute and it is almost never wrong.
The loop territory is real and it is larger than graph enthusiasts admit. Open-ended research, where the next query depends on what the last one surfaced. Debugging, where the next hypothesis depends on the last failed test. Any task where the interesting part is the agent noticing something you did not anticipate. Draw a graph for those and it will either fail at the undrawn branch or, worse, route around the thing you needed it to notice and hand you a confident answer that skipped the point.
A graph cannot discover a step you did not draw. That sentence is the whole limitation, and it is worth saying out loud before you commit, because the failure is quiet. The run completes. The output looks reasonable. Nothing in the logs says a branch was missing.
How do you draw a graph that survives production?#
The viral recipe stops at "send it to the model," which is where the actual engineering starts. A few things separate a drawing that produces a working system from one that produces a demo.
Draw the failure edges before the happy path is finished. Most people draw the workflow they want and then discover, in production, that they never specified what happens when node four returns nothing. The failure edges are usually more than half the real graph, and they are the part a coding agent will invent badly if you leave them out. If a node can time out, return empty, or return something malformed, each of those is an edge, and you should decide where it goes while you are still holding the pen.
Mark which nodes are independent. This is the one thing a drawing gives you that a loop never will, and it is free performance. Two nodes that do not depend on each other can run at the same time, and the wall-clock saving is often the largest single win in the whole exercise. A loop cannot do this, structurally, because it does not know what is coming next.
Keep the drawing in version control next to the generated code. The drawing is the spec, and a spec that lives in someone's notes app drifts from the implementation within a week. When the graph changes, change the drawing and regenerate, rather than patching the script directly. This is the discipline that decides whether graph engineering is a technique or a one-time trick, and it is the same argument for keeping evaluation harnesses close to the code that I made in eval-driven development.
Give every node one job. Nodes that do three things are the ones that fail ambiguously, because when the node returns something wrong you cannot tell which of the three jobs broke. This is the same decomposition instinct that makes multi-agent systems work or fail, applied at a smaller scale.
What goes wrong with graph engineering?#
Four failure modes, and each has a recognisable tell.
The undrawn edge. The workflow needed a branch that is not in the drawing, so the run either fails there or routes around it and produces something plausible and wrong. The tell is a graph that passes every test case you designed and breaks on the first real input, which happens because you designed the tests from the same drawing. The fix is not a bigger graph. It is recognising that the problem belonged in loop territory.
Premature graphing. Someone draws a graph for a workflow they do not understand yet, and the drawing calcifies a wrong decomposition. Graphs are much harder to change than prompts, so an early graph can lock in a bad structure for months. The tell is a graph whose nodes keep needing "just one more input" from three nodes upstream. Loop first, learn the shape, then draw it once you know.
The rigid retry. A node fails, the graph retries it exactly as written, and it fails identically forever because nothing about the input changed. Loops handle this better by accident, since a fresh reasoning pass will often try something different. If your graph has retries, the retry edge needs to change something, or it is just a slower way to fail.
Silent parallelism bugs. Two nodes marked independent are not actually independent, because they write to the same file or assume the same ordering. The tell is a workflow that succeeds when run sequentially and fails intermittently under parallel execution. This is ordinary concurrency, and it arrives the moment you take the free performance win, which is why marking independence deserves more care than it usually gets.
Should you adopt this now?#
Yes, for the workflows that pass the drawing test, and with clear eyes about what the evidence actually supports.
Here is my honest read on the state of the claim. The premises are well established. Context degradation over long inputs is measured across multiple studies. Prompt caching economics are documented by the providers themselves. The value of decomposition in agent systems shows up in benchmark after benchmark. None of that is in dispute.
What is not established is the recipe. There is no controlled comparison of a drawn graph against a disciplined loop on the same task, measuring cost and quality together. What exists is field reports, a viral post, and a lot of people agreeing with each other quickly. That is not nothing, and the convergence is meaningful, but it is not evidence in the way the context studies are evidence. Treat graph engineering as convergent practice with a sound theoretical basis rather than as a proven method, and you will make better decisions than the people treating it as either revelation or hype.
The practical move is small. Next time you are about to build an agent workflow, try drawing it first, before you write anything. If the drawing completes, you learned that you had a graph, and you now have both a spec and a review artifact for roughly twenty minutes of work. If the drawing stalls because you do not know what step three returns, you learned something more valuable: you have a loop, and you should go read about keeping its prefix stable before you run it a few hundred times.
The four-word reply was the right question. The answer is that a loop decides at inference time and a graph decides at authoring time, and knowing which one your problem needs is most of the skill.
FAQ#
What is graph engineering in AI agents?#
Graph engineering is the practice of deciding an agent workflow's control flow before the agent runs, by drawing the workflow as a graph of nodes and edges and generating the orchestration code from that drawing. Nodes are units of work such as model calls or tool calls. Edges are the transitions between them, expressed as code rather than as model reasoning.
How is a graph different from an agent loop?#
A loop is a graph with one node and an edge pointing back at itself, so the difference is not topology. The difference is when routing gets decided. In a loop the model chooses the next step during inference, on every iteration, and you pay tokens for that choice each time. In a graph you chose the routing when you drew it, so the model only does the work inside each node.
Is graph engineering the same as a knowledge graph?#
No. Knowledge graphs are a retrieval structure, used to store and traverse relationships between entities so an agent can find relevant context. Graph engineering describes the control plane, meaning the order in which work executes. The two can appear in the same system and solve unrelated problems.
When should I use a loop instead of a graph?#
Use a loop when you cannot draw the workflow without running it. Open-ended research, debugging, and any task where the next step depends on what the previous step surfaced all belong in loop territory. A graph cannot discover a step you did not draw, so drawing one for genuinely exploratory work produces either a failure at the missing branch or a confident answer that skipped the point.
Does a graph actually save money compared with a loop?#
It saves in two places. You stop paying for per-iteration routing reasoning, because the routing is now code. You also get better cache behaviour, because each node has a stable prompt prefix, and prompt caching requires an exact prefix match to hit. A loop can achieve a stable prefix too, but only if you deliberately pin the system prompt and spec at the front, which is a step people skip.
What is the first thing to draw when designing an agent graph?#
Draw the failure edges early rather than last. Most drawings capture the happy path and leave timeouts, empty returns, and malformed responses undefined, which is exactly the part a coding agent will invent badly. Also mark which nodes are independent of each other, because that is where the parallelism is, and it is usually the largest wall-clock win available.
Is there evidence that graph engineering works better than the alternatives?#
The premises are well supported and the recipe is not. Context degradation over long inputs is measured across multiple published studies, and prompt caching economics are documented by the providers. There is no controlled head-to-head comparison of a drawn graph against a disciplined loop on the same task measuring cost and quality together. Treat it as convergent practice with a sound basis rather than a proven method.