From loops to graphs: what actually changed in agent engineering

Agent engineering acquired a name in June and replaced it in July.

On 7 June, Addy Osmani published an essay called Loop Engineering that gave the practice an anatomy: a cycle of plan, act, observe, retry, wired up with automations, worktrees, skills, connectors, sub-agents and external memory. The same day, Peter Steinberger — who built OpenClaw — posted that you should stop prompting coding agents and start designing the loops that prompt them for you. That post reportedly crossed six and a half million views, and for a few weeks loop engineering was the frame everyone was building against.

Then on 18 July, Steinberger posted twelve words: are we still talking loops or did we shift to graphs yet? The reported view counts for that one vary wildly depending on who is doing the reporting, so treat the number as unverified. The direction of travel is not in dispute. Within a month the essays, the framework docs and the conference talks had all switched vocabulary.

It would be easy to file this as terminology churn. It is not, quite. There is a real engineering distinction underneath, and it is worth being precise about — partly because the distinction is useful, and partly because the enthusiasm around it is skipping past a harder problem.

What the graph framing actually means

A loop is one agent, cycling. It plans, acts, observes the result, and decides whether to go again. Everything interesting happens inside a single context, and the design work is about what goes into that context and when.

A graph is several of those loops wired into a structure. The definition that has settled across the write-ups is specific enough to build against, and it has three parts.

Nodes are the units that do work, and each has a single responsibility. A node is usually a specialised agent — a researcher, an implementer, a reviewer — but it does not have to be an agent at all. A plain deterministic function, a database query, a tool call with no model in the path: these are legitimate nodes, and the good designs use a lot of them. Not every step needs a language model.

Edges are the routing between nodes, and they carry more variety than people expect. An edge can be sequential (A then B), conditional (if review passes, ship; if not, route back), fan-out (one node dispatches three in parallel), or fan-in (three results join back into one). Crucially, the topology supports cycles as well as directed acyclic graphs, which is why the loop did not actually die. It became a node, or a cycle within the graph.

Shared state is the object that travels along the edges — the thing each node reads from and writes to.

That is the whole model. The claim implicit in the rename is that once you have more than one agent, the structure between the agents matters more than the behaviour of any one of them. On that narrow claim, the shift is correct. If you have been treating a multi-agent system as a pile of prompts, moving to an explicit graph will make it legible, testable and debuggable in a way it was not before.

The constraint everyone repeats

The obvious appeal of a graph is parallelism. Three independent nodes running concurrently finish in the time of the slowest, not the sum of all three. Latency drops, and different agents can examine different dimensions of the same problem without contaminating one another.

The constraint that shows up in every serious treatment: only genuinely independent work may fan out. Parallel branches with a hidden dependency on one another do not fail loudly. They return quickly, and they return inconsistent results, because branch B read state that branch A had not finished writing. This is an old distributed-systems lesson arriving in a new costume, and it will catch teams who read "parallel" as a free speed-up rather than as a claim they need to prove about their own workflow.

Context does not cross an edge for free

Here is the failure mode that dominates the practitioner reporting, and it is not a topology problem — it is a plumbing problem.

Each node keeps its own context. Context does not automatically flow between nodes just because you drew an edge. You have to design the handoff: decide what gets carried, in what form, and how much fidelity survives. When teams skip that, the result described most often is an infinite handoff loop — every agent re-plans from scratch because no node actually owns the task, and what context does transfer degrades a little more on each hop until downstream agents are working from something close to noise.

The tooling ecosystem is reacting to this in real time. There is a Show HN this month for a tool whose entire pitch is git diff for your agent's context window, and an active thread on transferring context between agents mid-task. When people start building diff tools for a thing, it is a reliable sign that the thing has become hard enough to need debugging.

The counter-intuitive result worth sitting with

The instinct, once you have a graph and shared state, is to give every node as much context as possible. The evidence from the past month points the other way.

A practitioner running an agent team across three model vendors reported that their reviewer agent caught more defects once it stopped seeing the implementer's context. Blind review beat informed review. That should be intuitive to anyone who has run a code review process with humans — an independent reader catches what someone primed by the author's reasoning glides past — but it cuts directly against how most people wire a multi-agent system.

It also lines up with the architecture the labs are describing. The sub-agent pattern being reported gives each sub-agent an isolated context window and has it return a condensed summary of one to two thousand tokens, rather than sharing raw working context. One vendor-reported internal research eval put that architecture more than ninety per cent ahead of an equivalent single-agent setup. Treat vendor-reported evals with the scepticism they deserve, but the qualitative direction is corroborated by independent practitioner reports, which is the more interesting part.

The design principle that falls out: shared state is the graph's plumbing, not automatically its advantage. Deciding what a node should not see is as much of a design decision as deciding what it should.

The memory gold rush, and the result that should slow it down

Adjacent to all of this, agent memory has become the most crowded infrastructure category in the space. In the last thirty days alone the Show HN feed has carried memory-in-SQLite projects, a memory-from-your-repos CLI, a memory layer arguing you need nothing beyond Go's standard library, a memory system for keeping third-party claims from hardening into facts, and a public leaderboard. The first Agent Memory Challenge opened on 29 July with more than twenty universities and research organisations behind it, which finally gives the category a shared evaluation protocol.

Against that, the single most useful result of the month came from a practitioner, not a vendor. They ran eight agent memory systems across 2,176 tasks and reported that a plain Markdown wiki beat every commercial product in the comparison. It drew 175 upvotes and 112 comments, and nobody in the thread produced a convincing rebuttal. Read alongside a well-circulated post arguing that most self-improving agents do not measurably improve, the honest position on this layer is that it is pre-consensus. Products are shipping considerably faster than evidence that they beat a text file.

We have written before about why plain files make good agent memory — inspectable, editable, version-controllable. This month's benchmark is the strongest evidence yet that the boring option is also frequently the performant one. If you are being sold a memory layer, the question to ask is not what it indexes. It is what it beats, and whether the baseline in that comparison was a directory of Markdown under version control.

Where the actual bottleneck is

The graph framing is a genuine improvement in how we describe multi-agent systems. It is also, read uncharitably, a way of spending attention on the part of the problem that is fun.

Orchestration topology is tractable. You can draw it, reason about it, and test it. Verification is not, and the reporting from the last month is uncomfortable on exactly that point. A study covered in early August found that humans in the loop miss roughly a third of dangerous AI coding agent requests — which undercuts the safety story most teams are telling themselves, since human review is usually the entire control. The practitioner threads are asking the same question from underneath, in almost plaintive terms: how do you actually know your agent did what it says it did? And there is a cautionary tale doing the rounds about an agent that, unprompted, worked its way into a gym's booking system and cancelled a stranger's reservation.

The evaluation discipline is adjusting. The direction is from scoring final outputs to scoring whole trajectories, on the reasoning that intermediate tool calls, ordering and reasoning steps all fail independently of whether the final answer happened to look right. A frequently cited figure puts the gap between lab benchmark scores and real deployment performance at around thirty-seven per cent. For anyone operating in a regulated context, the EU AI Act's high-risk obligations began phasing in this month, which converts audit trails and explainability from governance slideware into engineering requirements with dates attached.

None of that is solved by a better graph. A well-structured multi-agent system that cannot prove what it did is a well-structured liability.

What to take from it

If you are building with agents right now, three things from this cycle are worth acting on and one is worth resisting.

Act on the explicit structure. If you have more than one agent, draw the graph — nodes with single responsibilities, edges you have actually specified, and a deliberate decision about what state travels along each one. Use deterministic nodes wherever a model is not earning its place.

Act on context isolation. Default to giving each node the minimum context it needs, and treat blind review as a first-class pattern rather than an oversight. The instinct to share everything is expensive and, on the current evidence, often counterproductive.

Act on verification early. Build the trajectory logging before you need it, not after an incident. The question of what your agent did, and how you would prove it, is the one that will still be hard when the orchestration is elegant.

Resist the tooling rush, particularly on memory. The category has more products than evidence, and the current best-supported baseline is a directory of Markdown files under version control. That may not stay true — the new leaderboard exists precisely to settle it — but until it is settled, buying ahead of the evidence is a choice, not a default.

The rename from loops to graphs described something real. It did not solve the thing that is actually hard.

---

If you are designing a multi-agent system and want a senior read on the structure, the context boundaries, and what it will take to verify what it does in production, that is the kind of work we do at Think and Form Limited. Get in touch at admin@thinkandform.co.nz.