Is 'graph engineering' real? From loop engineering to the debate on agent graphs

By Turing Post · July 20, 2026.

The editorial in this edition of FOD examines a very recent phenomenon in the public conversation about agentic AI: the emergence of the term 'graph engineering' just six weeks after the term 'loop engineering' became popular, and how within days the community was already declaring the latter dead in favor of the former.

The origin of the debate dates to July 18, when Peter Steinberger asked on X: 'Are we still talking about loops or have we already moved on to graphs?' A few hours later, Hamel Husain published what the newsletter describes as the 'obituary' of loop engineering, in a post titled 'Loop Engineering Is Dead. Enter Graph Engineering.' According to Turing Post, over the following weekend courses, roadmaps, tool stacks, and threads had already emerged claiming that Microsoft, Stanford, and Anthropic had 'discovered' graph engineering simultaneously.

The term 'loop engineering' had been coined and popularized by Addy Osmani in an essay published on June 7, which in turn drew on an earlier slogan by Steinberger and a statement from Claude Code's creator, Boris Cherny, who stated: 'I no longer prompt Claude'; his job, he explained, was to write the loops that do it for him. The central idea of loop engineering is not to guide the agent turn by turn, but to give it a goal, a way to check its own work, and a cycle it can repeat until the task is complete—an approach with precedents in science and software engineering.

The article explains that a loop describes the basic cycle of an agent (find the next step, plan, act, check the outcome, continue or stop), but that this scheme stops being sufficient once the task grows more complex: parts that can run in parallel, steps requiring different models (one for code, another for search), an agent producing an answer while another tries to refute it, or decisions that need human approval versus others that can be automated. At that point, designing the loop is no longer enough, and one must decide how the different pieces connect: that larger structure is what's called a graph, made up of nodes (a unit of work: an agent, a model call, ordinary code, or a human decision), edges (what happens next), and state (the information passed from one step to another). The piece notes, with some irony, that a loop is itself already a graph: simply one whose path loops back to a previous node.

According to the editorial, none of this is new to software engineering (state machines, DAGs, workflow engines, and orchestration systems have been doing versions of this for decades), and it recalls that LangChain launched LangGraph in January 2024 specifically to help build stateful agent workflows. What does seem to be changing is the role assigned to the model within that system: early agent systems asked the model to do almost everything (decide what happens next, choose a tool, interpret the result, update the plan, decide whether to stop), which looked impressive in a demo but produced equally general failures in production: unnecessary loops, business-logic jumps, lost state, and contexts clogged with tool outputs.

The article cites two concrete examples of this trend. On one hand, Google reportedly made this problem explicit when presenting Agent Development Kit (ADK) 2.0, arguing that code should control predictable routing while models handle the steps that require interpretation or judgment. On the other hand, Anthropic reportedly tackles the same problem from a different angle: Claude Code's 'dynamic workflows' let Claude write a JavaScript orchestration script that coordinates subagents in parallel, so that by encoding the workflow, the model spends fewer tokens repeatedly deciding what to do next. For Turing Post, this would be a practical version of 'graph engineering': the model operates within a broader execution system, where reliability also depends on how work is routed, state is preserved, outputs are verified, and failures are managed.

The piece also warns that much of the current confusion comes from the word 'graph' being used for different things, and proposes a distinction into four categories: (1) control graph, the workflow structure and the rules about what runs next, used to orchestrate agent workflows, with examples like LangGraph and ADK; (2) knowledge graph, information stored as entities and relationships, used to improve retrieval and reasoning over documents, with Microsoft's GraphRAG as an example; (3) execution trace, what happened during a specific agent run, used for debugging and observability; and (4) improvement graph, a concept proposed over the weekend by Carlos Perez, consisting of loops that optimize, verify, and audit one another (one loop optimizes a metric, another watches the counter-metric, and others audit whether those metrics still represent the real goal), relevant for self-improving systems, since an optimization loop without a verification loop can become very good at producing the wrong outcome.

Finally, the editorial explicitly debunks a claim that reportedly went viral over the weekend: that 'graph engineering' had replaced RAG at Microsoft, Stanford, and Anthropic, achieving 18% higher accuracy and 85% lower cost. Turing Post states flatly that 'that is simply not true,' clarifying that those performance figures actually came from a paper applying Grap[...] (the email body cuts off here, so the rest of the explanation is not available).

The email also includes, outside the main editorial, a 'This Week in Turing Post' section with links to pieces from the publication itself (Friday: 'Global AI Affairs' on the limitations of global AI rankings; Sunday: 'Library' on AI protocols every builder should know) and a block sponsored by MongoDB about infrastructure for agents in production, which cites a Gartner prediction that 40% of agentic AI projects will be canceled by 2027, not because of the model but because security, cost, and evaluation fail first.