Between April and July 2026, the way people talk about driving Claude Code changed twice.
First it was loops. Stop typing prompts, and write the thing that types the prompts for you. Boris Cherny, said it at Anthropic's developer conference: he does not prompt Claude directly any more. He runs loops that prompt Claude and decide what to do next, and his job is to write those loops. Geoffrey Huntley's Ralph method had already shown that an agent kept running until it hits a goal beats an agent asked once. He later generalised it in everything is a ralph loop. /goal commands landed in Codex and Claude Code. For about three months, "loop engineering" was the whole conversation.
Then this guy posted :)
Within two days the term "graph engineering" had three competing definitions, a wave of explainer threads, and at least one fake Stanford study going around as proof it worked, and eventually someone already debunking it
The clearest version of the claim: loops made agent behaviour programmable, graphs make agent organisations programmable. The clearest objection came from the LangGraph side, which had been running loops on top of graphs for two years already and did not see what had changed. Everyone else queued up to write the explainer.
Six days later, a two-step recipe went around that is worth more than most of those explainers:
Yeah, read step 2 again. There is no graph framework in it. No runtime, no scheduler, no node registry, no shared state object whatsoever. The graph exists on paper long enough to be turned into a script, and then the script is the system. Nodes become functions, edges become calls, and the fan-out becomes whatever concurrency primitive the language already has. That is a real architectural claim, and it is testable. If your workflow can be written down as a script that a compiler and a test suite can check, the graph gave you a way to think and nothing else. If it cannot, the reason is almost always state: retries, partial failures, resuming after a crash, work that outlives one process. Those are the cases where you need a real runtime, and they are the cases a diagram will not solve for you. Which sets up the actual question...
So what actually comes next?
Actually theres a problem with guessing the next hype: there might not be one, at least not in this direction.
A loop is one node with an edge pointing back at itself. A tree is a graph with the rule that edges never cycle and every node has one parent, which is already what Claude Code does when an orchestrator spawns subagents. A general graph lets you have cycles, merges, and any fan-out you want. Graph is the top of this ladder if edges connect two things at a time. There is no shape between "tree" and "graph" that you forgot to buy, and nothing above "graph" except a hypergraph.
It is also worth noting that the shapes themselves are not new. Anthropic's blog Building effective agents already names orchestrator-workers (a lead model splits a task, delegates to workers, merges the results), parallelisation in two flavours (sectioning and voting), and evaluator-optimizer (one model produces, another judges, repeat). That is the graph discourse, drawn and labelled, eighteen months early. Their advice was to reach for these only when a simpler setup demonstrably does better, and to be wary of frameworks that hide the prompts and responses underneath an abstraction.
So the next buzzword will not come from drawing a more complicated picture. It will come from one of these five places.
1. Hypergraphs and group checks. A normal edge joins two nodes. A hyperedge joins many at once. This starts to matter when you need several agents to agree before something happens, rather than passing work down a chain: three reviewers on three different models, each with its own fresh context, all of whom have to pass before a merge. The "graph of loops watching each other" idea points at this without naming it, though the voting variant of parallelisation has been documented since 2024. The reason it will get named eventually, argued at length here: twenty agents on the same model, reading the same bad context, will agree with each other at scale and produce very tidy nonsense.
2. Compiling the graph away. This is the two-step recipe above, generalised. Draw the shape, turn it into a plain script, run the script. The graph becomes a design sketch, useful while you are writing and gone by the time it runs. If this wins, "graph engineering" is a way of drawing, not a way of building.
3. State and durability. The strongest technical objection to the whole recipe was one line: skip the steps and go straight to managing state. This camp says the graph was never the hard part. Keeping state correct across time and across processes was. So model the workflow in ordinary code, run a durable state machine around it (Temporal, or something you write yourself), and keep the messy reasoning loop inside single nodes where you actually want it. Call it durable-state engineering. It is the least exciting option and the most likely to be right.
4. Verifier engineering, which is my personal bet. Every step here has quietly been about the same thing: moving the human further from the tokens and closer to "what counts as done". Loops need a stop condition. Graphs need conditions on the edges. Both break the same way, which is a node that confidently produces garbage because nobody wrote a check for it. The scarce thing in 2026 is not the shape of the system. It is a definition of "done" that a machine can test. The evaluator-optimizer pattern in the Anthropic post says the same thing in a quieter way: it works when you already have clear criteria to evaluate against, which is doing all the load-bearing work in that sentence. Whoever names that well gets the next three million views.
5. Topology orchestration. Somebody in the replies predicted this name for next week, and there is no reason to bet against it. Prompt, context, harness, loop, graph. The rename rate has been roughly one per quarter and nothing suggests it is slowing.
Why Claude Code does so much better when the context is parseable
This is the thread running under all four steps, and it is worth pulling out of the naming argument.
Claude Code is not better with parseable context because parsing is easy. It is better because structure changes four things at the same time.
You get addresses. src/auth/session.go:412 is an address. "the session bug" is a search problem. In a repo with clean module boundaries, typed interfaces, and sane file names, everything you talk about has a stable address that holds up across turns and across subagents. In a 4,000-line utils.py, nothing does, and the model burns its budget finding things instead of fixing them. Anthropic's context engineering post makes the same point from the other side: a file called test_utils.py sitting in tests/ tells the agent something different from the same filename sitting in src/core_logic/. Folder layout and naming conventions are signal, not decoration.
The tools do the narrowing, not the model. grep, glob, and symbol search return exact slices. When the structure is real, the filtering happens in ripgrep for free, and the model gets 200 relevant lines instead of 20,000 vague ones. Messy context pushes that filtering job back onto attention, which is the most expensive place to do it. This is a design choice, not an accident: Claude Code loads CLAUDE.md up front and then uses glob and grep to pull files in just in time, which sidesteps stale indexes and syntax-tree machinery entirely. Attention is a finite budget, and every token you spend locating something is a token you do not spend reasoning about it.
It matches what the model was trained on. These models saw a lot of code, markdown, JSON, YAML, and structured logs. Delimiters carry a lot of signal. A heading, a closing brace, a type annotation, or an XML tag each cut down what can come next. Plain prose does not. This is also why instructions wrapped in tags beat the same instructions written as a paragraph. The appendix on tool design in the Anthropic post makes the practical version of this argument: keep output formats close to what the model has seen occurring naturally, and avoid formats with bookkeeping overhead, like diffs that need an accurate line count in the header, or code that has to be escaped into JSON.
You can check the work, which is the one that matters most. A loop's stop condition needs something that returns true or false. Compilers, type checkers, linters, test runners, and schema validators all do that. Prose does not. A parseable codebase comes with a free army of checkers, so the agent can work against reality instead of against its own opinion of its work. This is the exact failure that killed naive loops and the exact one graphs are being sold to fix, and neither shape fixes it. The checker fixes it, and the checker only exists if the thing being checked is parseable. This is also the stated reason coding turned out to be the best agent domain in the first place: solutions are verifiable by automated tests, the agent can iterate against those test results, the problem space is structured, and output quality can be measured objectively. Nothing about that list is specific to loops or graphs.
Which is the real answer to the title. Loops, trees, graphs, and whatever gets named in August are all just shapes of control flow sitting on top of something. That something decides whether any of them work. Every edge in your beautiful graph is carrying a package from one node to the next, and if nothing can check that package at the boundary, you have not built an org chart. You have built a rumour mill with better diagrams.
Pick the simplest shape that works. Spend the effort you save on making the output at every boundary parseable and the definition of done runnable.
Anthropic's own guidance, written across two posts eighteen months apart and through four renamings, is still "do the simplest thing that works". That is a boring sentence and it has outlasted every noun on the ladder.
Top comments (0)