Every few months the AI tooling world converges on a name for something practitioners were already doing. "Prompt engineering" got its name years after people started doing it. "Context engineering" got its name in 2025. The one consolidating right now is graph engineering, and this time the label arrived for work our own stack runs daily.
Six channels, two weeks, one label.
The definition the wave has settled on: instead of handing a goal to a single agent that works through it serially, you decompose the task into a graph. Each node is an agent working in its own isolated context window. Each edge is a decision about what moves forward.
The videos frame graphs as the successor to "loop engineering," a single agent iterating until done. We would put it less dramatically: fan-out complements iteration, it does not replace it. A loop is still the right tool when each step depends on the last. A graph earns its place when the work contains genuinely independent subtasks, because independent subtasks can run in parallel, in clean contexts, without contaminating each other.
If your team uses an agentic coding tool that spins up subagents, you have already run a graph without calling it one. What the new label adds is a way to talk about the shapes deliberately, and the shapes are where the useful decisions live.
Nodes are context windows. Edges are decisions.
Two shapes cover most of what we run in production.
The diamond: fan out, then merge. One brief splits into several specialist nodes that work in parallel, and a final node synthesizes what comes back. Our internal code-review pipeline is a diamond. The brief fans out to finder agents, one per review dimension (correctness, performance, security). Each finding then passes to a separate verifier agent whose only instruction is to try to refute it. Only findings that survive refutation reach the synthesizer that writes the merged report.
request
finder
finder
finder
report
The barrier: same problem, several lenses, wait for all. The second shape sends the same input to several agents that examine it through different lenses, and nothing advances until every lens reports. We use it when a deliverable can fail in more than one way: a French page goes through a linguistic pass, a technical parity pass, and a compliance pass, and the merge only fires once all three are in. The barrier costs wall-clock time, so it is reserved for the cases where a missing lens is worse than a slow answer.
deliverable
Why isolated contexts matter is worth one plain paragraph, because it is the actual mechanism. An agent that has spent an hour building something carries that hour in its context: its assumptions, its shortcuts, its reasons. Ask the same agent to review its own work and it re-reads its reasons and finds them convincing. A fresh node reviews the artifact, not the journey. The graph structure is what buys you that separation.
Never downgrade the judge.
Once each node is its own agent, each node can run its own model, and the temptation writes itself: put a cheap model on the review nodes, since "checking is easier than building." The AI LABS video contains the best practitioner account we have seen of why that fails, and it is the reason this note exists.
The channel ran the same UI-review skill twice against their own build: once on a cheap fast model, once on their strongest.[1] The cheap run returned a long list of findings. The strong run returned a short one. The long list looked more thorough until they read it: most of the findings flagged deliberate choices that the surrounding code explained, context the strong model had picked up and the cheap model had missed. Their conclusion, in their words: "the cheap review hadn't saved us anything because now the review itself needed reviewing."
Inside a graph, that failure compounds. Many nodes self-check with the same review skill. A weak judge does not fail quietly; it floods the graph with plausible false positives, downstream agents burn tokens fixing what was never broken, and by the time the merged output looks wrong there is no telling which node started it. One anecdote, one channel, no counts. But it lands on ground that measured research has already prepared: our judge-bias note covered a Cambridge-led study that put numbers on how ungracefully judges fail, and the shared conclusion is that judge quality is a structural property of the pipeline, not a nice-to-have.
Our own routing rule, standing for months and reinforced every time we test against it: cheap models go on mechanical stages, and the judge node runs the strongest model at the highest reasoning setting we can afford. A verifier is also prompted to refute, not to confirm, and told to default to "refuted" when uncertain. A judge that wants to say yes is barely a judge.
Unit cost down. Total cost up.
Per-node model selection lowers the price of each call, and every graph-engineering video presents that as the win. The number that matters points the other way: a graph exists to spend more compute on one deliverable. Five nodes re-read overlapping material in five separate contexts, verifiers re-examine what finders produced, and the merge reads everything again. The token bill lands at a multiple of what a single agent would have burned on the same task.
Credit where due: the AI LABS video is blunt about this, blunter in its description than on camera: "On API pricing, don't run graphs at all. On a subscription plan, expect your limits to arrive much sooner."[1] That is directionally right, and honestly said by a channel that benefits from people running more of this.
Our version of the same advice: budget the deliverable, not the API call. A graph is justified when the deliverable's failure cost justifies the multiple: a production code change, a contract, a page shipping under your client's name. It is not justified for work a single agent gets right nine times in ten, and it is never a substitute for asking whether the task decomposes at all. The controlled studies we covered in June said coordination pays only under narrow structural conditions, and that decomposability, not task complexity, predicts the payoff. Graph engineering, done honestly, is the discipline of finding those narrow conditions on purpose.
Four rules before you fan out.
- Fan out only what is independent.
If step B needs step A's output, drawing them as parallel nodes buys coordination overhead and nothing else. The graph shape should fall out of the task's real dependency structure, never the other way around.
target · shape follows dependencies, not ambition - Put your strongest model on the judge node.
Route cheap models to mechanical stages: extraction, formatting, first-draft generation. The one place economizing costs you everything is the node whose output decides what the other nodes' output is worth.
target · judge = strongest model, highest effort, prompted to refute - Budget the deliverable, not the call.
Expect the graph to cost a multiple of a single agent on the same task. Decide the deliverable is worth the multiple before you draw the graph, and keep a plain loop as the default for everything that is not.
target · failure cost of the deliverable > token multiple of the graph - Log every node's output.
When a merged result is wrong, you need to trace which node started it. Keep each node's raw output next to the merge. And know the honest state of the art: attribution of a bad merge back to its source node is the weakest part of this practice everywhere, including here.
target · every merge traceable to its inputs
What we are not claiming.
The judge-node story is one channel's anecdote, with no counts behind it. We repeat it because it matches what measured judge-bias research predicts and what our own practice keeps confirming, not because it proves anything on its own. Our production examples are our practice, not a controlled benchmark: we have not run the counterfactual where the review graph runs on cheap judges and we tally the damage, and we are not going to pretend otherwise.
The label itself may not stick. "Graph engineering" is a wave in a corner of the internet that produces a new wave monthly. The shapes underneath it are older than the name and will outlive it either way, which is exactly why the name is worth learning now: the vocabulary is consolidating while the practices are still unevenly understood, and the gap between the two is where bad fan-outs get sold.
If you are deciding whether a workflow in your shop deserves a graph or a loop, the contact form is the fastest way in. We do 30-minute reviews for production agent stacks, free.