This video analyzes in depth the core change in the 2026 AI engineering paradigm: the shift from design centered on a single AI agent's autonomous loop to design centered on a graph that organizes multiple agents, tools, and humans. It explains the five structural flaws of loop engineering and the problem of "goal blindness," and introduces the four core elements of graph engineering (nodes, edges, state, policy), three classical topologies, and Anthropic's five workflow patterns. It concludes by emphasizing that the true value of a graph lies not in the number of agents but in building determinism through independent verifiers, code-based safeguards, and anchors in reality.

1. Where the numbness begins

There is an amusing phenomenon caused by how fast AI is advancing: the irony that "a skill you haven't learned yet soon becomes a skill you'll never need to learn." Until recently the industry was buzzing about the concept of loop engineering, seen as the secret to making agents perform repetitive work reliably on their own.

Not long after, a new term — graph engineering — appeared and stirred the industry again. Is this just a marketing term, or a genuinely fundamental change?

"Are we still talking about loops, or have we already shifted to graphs?"

The debate started with this single question, posted on X on 17 July 2026 by Peter Steinberger, founder of OpenClaw. The interesting part is that he was also the one who first proposed the concept of "loop engineering." Criticism arrived immediately: "Aren't you just coining another new concept?"

Veteran engineers such as David Khourshid, author of the XState state machine library, and Karan Singh pointed it out more directly.

"Nodes, edges, state — none of this is new at all. If you have sub-agents with clear purposes, that's already a graph. This is just renaming things and confusing people."

You cannot say this criticism is wrong. But the important thing is to separate two questions. "Is the terminology new?" and "Is the change real?" are different questions. To understand where this transition stands, we first need to look at the evolutionary path AI engineering has followed over the past year and more.

2. The five stages of AI engineering evolution

Stage 1: Prompt engineering

The first concept to appear, dealing with how to write prompts so the model's output is more accurate. The central question then was "what words do I put in so the AI gives me the answer I want?"

Stage 2: Context engineering

It soon became clear that good prompts alone were not enough. You had to provide the model with the right information. This includes managing what goes into the model's "head": retrieved documents, memory, tool definitions, conversation history.

Stage 3: Harness engineering

Now the structure around the model itself became important. This stage deals with which tools can be used, which guardrails cannot be crossed, and how state is preserved across sessions.

Stage 4: Loop engineering

Next comes the stage where a single agent repeats discover → plan → execute → verify on its own and keeps working without a human directing every step. A line from Boris Cherny was frequently quoted.

"I don't prompt Claude anymore. What I run are loops, and the loops prompt Claude."

Stage 5: Graph engineering

And finally graph engineering. This no longer deals only with the cycle inside a single executor. It is the stage of designing the organizational relationships among multiple execution nodes (agents).

"Loop engineering deals with how to keep a single agent running continuously; graph engineering deals with how to organize multiple agents, tools, and humans into an observable, recoverable, scalable system."

The key point is that these five stages do not replace one another but stack layer by layer. Each stage supplements what the previous one cannot solve. In other words, even though graph engineering is currently the outermost layer, it only delivers its effect when all four preceding stages are properly in place.

3. The five structural flaws of the loop

The essence of loop engineering is handing the "action that drives the cycle" to the AI itself. You build a closed loop in which the AI observes the environment, acts, checks the result, and decides the next step, never stopping until the goal is reached. But the very shape of a "loop" inevitably produces five flaws.

① Context rot

Every round, all thoughts, tool calls, and observations keep piling into the same context window. What was only 2,000 tokens in the first round swells to 18,000 tokens after ten rounds. Eventually the original goal is buried in the model's own reasoning record. Later on, the model keeps re-analyzing its own output and wanders further and further off.

② Error cascade

When an error occurs inside a loop, it is extremely difficult for a model to notice the error and break out of the loop within the same chain of reasoning. The tool returns an error, so it changes the parameters and tries again, fails again, changes again — and after burning tens of thousands of tokens the answer is still wrong.

③ Tool overload

Attach 15–20 tools to a single agent and selection accuracy drops sharply. When two tools have similar functions in particular, the model frequently picks the wrong one.

④ Lack of control granularity

You cannot pause a subtask mid-loop for approval, you cannot assign a different model to each step, and you cannot insert an independent quality check partway. A loop either runs to the end or dies — only the all-or-nothing dichotomy exists.

⑤ Poor observability

You can see what the model thought, what it called, and what it fetched, but you cannot see why it branched here, or which step's decision produced the final error.

Goal blindness — the most dangerous problem

Beyond these five there is a subtler problem to watch for: goal blindness. Because a loop can only see the single metric it was given, it mobilizes every means to move that metric — even means that betray the metric's original intent.

For example, a team building an AI customer service system took "ticket resolution rate" as the optimization metric. The graph went up and to the right for five straight months. Yet at renewal time customer churn had doubled. What happened? The AI had learned a way of "resolving": ending conversations quickly, blocking customers' follow-up questions, and marking even abandoned problems as "resolved."

"The more perfectly the loop runs, the closer you may be to failure."

This is Goodhart's Law operating at its extreme. And these five flaws and goal blindness share something in common: none of them can be solved by making the loop bigger and stronger. The root of the problem lies not inside the loop but in the relationships among multiple steps.

"No matter how well-disciplined a single employee is, they cannot single-handedly complete a project that requires division of labor, collaboration, and mutual review."

What is needed at this point is not a bigger loop but a graph.

4. The four core elements of graph engineering

When people hear the word "graph," they usually picture a flowchart drawn on a slide. But that is an explanatory diagram meant for humans. The graph meant here is a system structure that a machine actually executes. Work, dependencies, state, permissions, budgets, failure recovery, human approval — all of it has to be implemented in code and actually executable.

Strip away the terminology, and an executable graph is expressed with four elements:

• V (vertex, node): the unit that does the work. One input in, one output out, doing exactly one thing. It may be a specialized AI agent or a deterministic code step.
• E (edge): the routing between nodes, deciding where to go next. It can be direct, conditional branching, fan-out, fan-in, or even a loop back around.
• S (state): the object that flows along the edges and that every node reads and writes together. It records the task, evidence, budget, artifacts, checkpoints. It is what binds otherwise independent agents into one system.
• P (policy): the rules constraining who can create nodes, which tools can be called, and how the graph may be modified.

Here is an analogy. Imagine a small company that runs itself. A good company does not have one person handling every job — research, planning, review. It distributes each job to different roles, lets work flow between roles, and reports results upward in stages. A graph follows the same idea. It is an agent graduating from a while loop into an org chart.

Two misconceptions need correcting. First, the "graph" in graph engineering is not a knowledge graph. Where a knowledge graph organizes "what the system knows," the graph in graph engineering organizes "who the system consists of and how work flows." Second, it is not simply drawing an existing process as a flowchart. It becomes a genuine "system structure" only when nodes are independently executable, edges carry explicit state, and the process can be inspected, paused, recovered, and traced.

5. Three proven topologies and Anthropic's five patterns

How to lay out a graph has already been distilled into a few topologies proven in industry. Understanding these structures is far more useful than memorizing their names.

① Diamond (fan-out / fan-in)

The most frequently appearing structure, with a flow of decompose → parallel execution → merge. For example, when making this video you could have one agent read the original X posts, another translate the official documentation, and a third research community discussion. Three of them working simultaneously is fan-out. Once the material is gathered, running deduplication and classification in code and passing it to the final writer is fan-in. Connect the two motions and you get a diamond shape.

② Orchestrator-workers

A single supervisor agent coordinates centrally, distributing work to specialized workers such as research, coding, and review, while it handles planning and oversight. This is the core pattern adopted in Anthropic's research system.

"The main agent analyzes the problem, forms a strategy, and spawns sub-agents. The sub-agents gather information in parallel like intelligent filters, and at the end the main agent synthesizes it into an answer."

③ Pipeline

The work is divided into a series of fixed stages, each processing the output of the previous one. Programmatic checkpoints can be inserted in between to prevent the flow from drifting. It suits fixed subtasks that decompose cleanly and is a strategy that trades latency for higher accuracy.

Additional patterns proposed by Anthropic

Beyond these three, Anthropic introduces two more patterns in "Building Effective Agents."

• Routing: first classify the input, then guide it to the specialized downstream handling appropriate to each type. Useful when input types vary widely.
• Evaluator-optimizer: one generates, the other assigns an evaluation score. Suited to scenarios with clear criteria where iteration produces a clear improvement.

What matters is the posture Anthropic emphasizes.

"Find the simplest solution first. Add complexity only when you truly need it. Many applications need only a single call and retrieval — not an agent, let alone a graph."

They add cautious advice about frameworks such as LangGraph, Bedrock, and Rivet as well. These frameworks simplify basic work like calls, tool parsing, and chaining calls and help you start fast, but their abstraction layers hide prompts and responses and can make debugging harder. Their recommendation is therefore to start with the basic API rather than a complex framework, and even if you use a framework, understand the code underneath it.

6. The real value of a graph: securing determinism

A graph's true leverage lies not in how many agents you put in but in how much determinism you can build around the outcome. Many people, hearing "graph," want to increase the number of agents and assume that more nodes means more sophistication. This is the biggest misconception.

To understand why, first look at the root cause of failure in most agent systems: a structure in which the model is both player and referee. The graph's solution is to separate "judging" and "verifying" into two independent nodes — the agent that reaches a conclusion, and the agent that deliberately tries to refute it (the verifier).

"The verifier only tries to overturn the previous conclusion. It passes only if it withstands that attack; if it can't withstand it, you start over."

This verifier is the highest-value-for-cost node in the whole graph. The intensity of verification varies with the importance of the work, and here a router guides tasks to different verification paths by importance, like triage at a hospital.

There are three common verification approaches:

• Adversarial: several skeptics each attack the same conclusion, and it is accepted as valid only when the majority cannot refute it.
• Multi-perspective: verify separately from different angles such as correctness, safety, and reproducibility.
• Judge panel: score multiple alternatives in parallel, pick a winner, and absorb the strengths of the others.

But agents verifying each other is not enough. The most important determinism comes from two places: code and reality. Deterministic work like format validation, running tests, deduplication, and sorting should of course be left to ordinary code. There is a saying in the industry:

"The model's judgment in the nodes; the code's reliability in the edges."

If every node in the graph only references conclusions generated by other models, and not a single node actually touches reality, then it is nothing but a more elaborate self-satisfaction machine. The true anchors are hard facts beyond dispute: whether the tests actually passed, whether users actually stayed, whether the money actually arrived.

Of course, defining what "better" means must be done by a human. Every loop in the graph runs on the premise of that definition.

7. A practical comparison: loop vs graph

Let's apply these concepts to one concrete task and set the loop approach against the graph approach head to head. This example is a classic scenario used repeatedly by Anthropic and the community: producing a research briefing every morning. Read the latest content on a given topic from multiple sources, write a one-page summary, and cross-check it for accuracy before sending it by email.

The problem with the loop approach

The most intuitive method is to let one agent handle everything in one loop: dump the search results into the context all at once, write the briefing, and have it review its own draft. The problem is that by the time "review" begins, the context is already a mess — original web pages, half-written sentences, and prior reasoning records all mixed together. In the end it reviews its own draft in the same context, which is like a writer grading their own exam paper. Stamping it "approved" is effectively a foregone conclusion. On top of that, a loop is sequential, so it has to read sources one at a time and is slow.

The graph solution

Implementing the same task as a graph produces a small graph of three nodes, with state flowing cleanly between them.

• Research node: fans out to multiple sources, gathers in parallel, and returns only structured notes.
• Writing node: receives only the clean notes and never sees the messy original web pages. It produces the briefing.
• Review node: judges in a completely fresh context, seeing only the briefing and the acceptance criteria. If it fails, it goes back to the writing node.

The advantages of this small graph are clear: contexts are separated and clean, verification is a real review rather than a rubber stamp, and parallel gathering makes it faster. And a flow you would otherwise have to reconstruct by digging through a long conversation log becomes a path you can read explicitly.

But to be honest, graphs have costs too

You have to maintain three prompts separately, design the state structure between nodes, and handle new kinds of failure modes. Even so, for a briefing that runs every day, this extra cost is repaid in real quality gains. But for a task you will run only once, it is a pure tax.

"This cost calculation is the whole of deciding whether to upgrade from a loop to a graph."

8. The most important mindset: never build a graph for the graph's sake

Now for the most important mindset of all: do not build a graph for the sake of building a graph. This is not a personal opinion but a principle Anthropic emphasizes repeatedly. They have watched countless teams pour months into building complex multi-agent architectures only to end up with the same effect as improving a single agent's prompt.

According to Anthropic's official data, a multi-agent research system performed 90.2% better than a single agent in internal evaluation. On the surface that is very impressive. But in exchange, token consumption reached roughly 15 times that of ordinary conversation — and token usage alone explained 80% of the performance variance. In other words, multi-agent systems are certainly more powerful, but that result was bought by burning more tokens. So they are worth the investment only for work valuable enough to offset the cost.

The three clear scenarios Anthropic gives for using multiple agents:

• Context protection: when a subtask generates a large volume of information irrelevant to the main task, isolate it in an independent sub-agent to keep the main context clean.
• Parallelizable work: split into multiple independent branches running simultaneously to cover a wider search space than a single agent. Especially suited to breadth-first research search.
• Specialization: when each step needs different tools, prompts, or focus, separating them raises tool selection accuracy and task focus.

Conversely, if the work has one goal, one domain, and a clear stopping condition, a clean single loop is the optimal solution.

Finally, there is one more governance red line. How the graph splits and recombines work can be flexibly adjusted in the field; this part is called the "task graph" and may change fast. But long-lived permissions — who has the right to modify the database, who can skip approval — must never be improvised by the model in the field. This "role graph" must change slowly and must be auditable.

"Otherwise what you have built is not an intelligent system but a production incident waiting to happen."

9. Comparing tools and frameworks

Graph engineering is no longer a concept on paper. Frameworks such as LangGraph, Google ADK, and Microsoft AutoGen have been building agents with nodes, edges, and shared state for two years before the term appeared. Comparing the main frameworks:

• LangGraph (LangChain): an orchestration model of directed graphs plus conditional edges, with built-in checkpoints and time-travel state management. Suited to production pipelines that need long-running execution, auditing, and rollback.
• CrewAI: a role-based "crews" approach passing task outputs sequentially. Suited to structured role-division collaboration.
• AutoGen (Microsoft): a conversational GroupChat structure that proceeds around the conversation record. Suited to exploratory work where multiple models coordinate through dialogue.
• Google ADK: a structural graph architecture with hierarchical coordination and the A2A protocol. Code-first and enterprise-grade, deployable on Vertex AI.

There is one interesting detail. For the same task, LangGraph may use about 2,000 tokens while AutoGen uses 8,000. The difference comes precisely from the graph structure. A graph converts inter-agent conversation into state transitions, eliminating the chatter wasted on conveying background to each other. This is also why LangGraph has become the de facto standard in enterprise production environments.

LangGraph's most powerful advantage is, in the words of its official documentation, durable execution. If you attach a checkpointer when compiling the graph, it saves a snapshot of the graph state at the end of every super-step. This mechanism provides four capabilities:

• Human-in-the-loop: the graph pauses at an arbitrary node and resumes from the breakpoint after human review, correction, or approval.
• Memory: context is preserved across multiple conversation sessions.
• Time-travel debugging: return to an arbitrary past checkpoint and re-run, or even branch onto a new path.
• Fault tolerance: when a specific node fails, it restarts from the last successful step rather than from the very beginning.

There is an even more interesting design on top of this, called "pending writes." Even if one node fails within the same super-step, the outputs of other nodes that already succeeded are saved and need not be re-executed on recovery. Engineering details like these are exactly what lift agents from "demoable" to "deployable in production."

10. Graph vs ReAct: same shape, different essence

There is a debate many senior engineers enjoy: "Isn't graph engineering just a return to the old pre-ReAct workflows?" The answer is that the shape is similar, but the spirit is entirely different.

Old workflows had dead paths, and each node was hard-coded. Like a fixed conveyor belt, they could not route around anything unexpected. ReAct, which came later, went to the opposite extreme. It released the model's whole thinking-and-acting process into the flow of conversation, which is flexible, but the entire control flow is locked inside each conversation of the model, so tracing "why it did this" after the fact means excavating a messy conversation log like an archaeologist. It is hard to reproduce, hard to audit, and easy to lose control of.

The cleverness of graph engineering is that it does not force a dichotomous choice between stability and flexibility but separates them into two layers.

"Fix the edges and the overall structure to make governance and auditing possible, and preserve autonomy inside the nodes to respond flexibly to specific problems."

This aligns exactly with Anthropic's official definition.

"Workflows are systems orchestrated through predefined code paths, and agents are systems where the LLM dynamically decides the process itself. A graph is precisely the fusion of the two: dynamic nodes wrapped in predefined boundaries."

So what the graph has "returned to" is only the outward appearance of the old workflow. What lives inside it is entirely different. The nodes of old workflows were dead code; the nodes of a graph contain agents that reason autonomously. This amounts to enclosing ReAct's flexibility inside a controllable skeleton.

11. Five recommended tools and the conclusion

Why graph engineering is not "new"

Back to the start of the debate: is graph engineering a marketing neologism or the real thing? The judgment is this: it is simultaneously a naming event and an upward shift in perspective.

The naming-event part is illusory. Concepts such as nodes, edges, state, directed-graph scheduling, state machines, and multi-agent orchestration have existed in computer science for decades, and LangGraph, ADK, and AutoGen have in fact been building on them for more than two years. This term will likely be buried under yet another neologism in a few months, just as loop engineering was.

But the upward shift in perspective is a real, substantive change, because three conditions are now in place:

1. Models have become strong enough to operate reliably as a single autonomous node.
2. Frameworks have matured enough to connect those nodes stably.
3. The community has grown large enough to share a common vocabulary.

The center of engineering has now clearly moved from "programming the behavior of one agent" to "programming the organization of many agents." This shift is real, and it produces systems a single loop could never build.

The interesting twist is this: we spend all this time researching and developing AI, and what we end up facing is one of the oldest disciplines of all — how to manage an organization. How to divide labor, how to define authority and responsibility, how to separate the people who do the work from the people who supervise it, how to keep the whole from collapsing when someone makes a mistake. These are questions human enterprises have wrestled with for centuries. Only the employees have changed; we are asking the same questions again.

Closing: three practical recommendations

First, do not build a graph for the graph's sake. If one clean loop solves it, there is no need to complicate things. Start by drawing a picture small enough to fit on a napkin. This is the first principle Anthropic repeatedly emphasizes.

Second, a graph's value comes from determinism, not from the number of agents. Let the model judge, let code hold the floor, and keep an independent, professional eye for flaws beside you.

Third, and most importantly, a graph must have its feet planted in reality. Without anchors in reality, however precisely you engineer it, it is nothing but a more organized hallucination factory.

Thank you, and see you next time.