Is "graph engineering" real? Why everyone is talking about it

The editorial in this edition of FOD (Turing Post) examines a very recent phenomenon in the conversation about AI agent development: the term "loop engineering" was declared obsolete barely six weeks after being coined, replaced by a new term, "graph engineering."

The origin of the controversy: on July 18, Peter Steinberger asked on X whether the community was still talking about "loops" or had already moved on to talking about "graphs." A few hours later, Hamel Husain published what the newsletter describes as the "obituary" of the earlier term, in a post titled "Loop Engineering Is Dead. Enter Graph Engineering." By the following Sunday, the conversation on social media had already generated courses, roadmaps, tool lists and threads explaining that Microsoft, Stanford and Anthropic had supposedly all arrived at the same idea independently.

The term "loop engineering" was barely six weeks old: it was popularized by an essay by Addy Osmani published on June 7, which in turn drew on an earlier slogan by Steinberger and on a statement by Boris Cherny, creator of Claude Code, who declared "I no longer prompt Claude": his job, he explained, consists of writing the loops that do. The core idea of "loop engineering" is simple: instead of guiding an agent turn by turn, you give it a goal, a way to check its own work, and a cycle it can repeat until it finishes the task.

The newsletter explains the difference between a loop and a graph. A loop describes an agent's basic cycle: find the next piece of work, plan, act, check the result, and continue or stop. That scheme works well until the task gets complicated: for example, when several parts can run in parallel, when one step needs a code model and another needs search, when one agent produces an answer and another tries to refute it, or when some decisions can be automated while others require human approval. At that point, designing the loop is no longer enough: you also have to decide how the different pieces connect to each other, and that larger structure is the graph.

According to the email, a graph's architecture is nothing exotic: it has nodes, edges and state. A node is a unit of work (an agent, a call to a model, a piece of ordinary code, or a human decision). An edge determines what happens next. State carries the relevant information from one step to the next. And here the newsletter itself points out the irony: a loop is already a graph, simply one whose path returns to an earlier node. None of this is new to software engineering: state machines, DAGs, workflow engines and orchestration systems have been doing versions of this for decades. It recalls that LangChain launched LangGraph in January 2024 specifically to help build stateful agent workflows.

What is changing, according to the text, is the role assigned to the model. Early agent systems asked the model to do almost everything: decide what happened next, choose a tool, interpret the result, update the plan and decide when to stop. That looked very general in a demo, but it also created many ways to fail in production: agents entered unnecessary loops, skipped required business logic, lost track of state, and filled their context window with tool outputs.

The email cites two concrete examples of this transition. Google, in explaining its Agent Development Kit (ADK) 2.0, argued that code should control predictable routing, while models should handle the steps that require interpretation or judgment. Anthropic, for its part, approaches the same problem from another angle: Claude Code's "dynamic workflows" let Claude write an orchestration script in JavaScript that coordinates subagents in parallel, so that the model spends fewer tokens repeatedly deciding what to do next. For the newsletter, this is a practical version of "graph engineering": the model operates within a broader execution system, where reliability also depends on how work is routed, how state is preserved, how outputs are verified and how failures are handled.

An important part of the article warns about the ambiguity of the term "graph," which people are using to refer to different things: a control graph (the structure of the workflow and the rules about what runs next, like LangGraph or ADK); a knowledge graph (information stored as entities and relationships, like Microsoft's GraphRAG, which extracts a structured graph from documents and uses it during information retrieval); an execution trace (the graph that shows what happened during a specific agent run, useful for debugging and observability); and, a fourth interpretation proposed this weekend by Carlos Perez, a graph of improvement loops, where one loop optimizes a metric, another watches the opposing metric, and others audit whether those metrics still represent the real goal —something especially relevant for self-improving systems, since an optimization loop without a verification loop can become very good at producing the wrong result.

Finally, the newsletter explicitly debunks a viral claim that circulated on social media: that "graph engineering" had "replaced RAG" at Microsoft, Stanford and Anthropic, with an 18% accuracy improvement and an 85% cost reduction. According to the email, that figure is not true and comes from an academic paper that applied GraphRAG to industrial engineering diagrams, an interesting result but limited to a specific case. The text further clarifies that Microsoft describes GraphRAG as a type of RAG and not as its replacement, that Stanford's DSPy optimizes programs based on language models and is not a knowledge-graph system, and that Anthropic has not announced any discipline or product called "graph engineering."

In addition to the editorial, the edition includes a "This Week in Turing Post" section with links to a Friday analysis on where global AI rankings go wrong and a Sunday piece on AI protocols every developer should know, as well as sponsored content by MongoDB on infrastructure for agentic platforms, which cites a Gartner prediction that 40% of agentic AI projects will be canceled by 2027 due to problems of security, cost and evaluation, not because of the model itself.