From Agent Loops to Agent Graphs

July 24, 2026 · 18 min read

Software Engineer

A single glowing loop unfurling into a network of interconnected loops, drawn as an abstract editorial illustration

Every agent is, at heart, a loop: a model calling tools until the job is done. The interesting engineering question of 2026 is what happens when you wire many of those loops together into a graph — and when you shouldn't.

note

This post is a snapshot of a fast-moving field as of mid-2026. The ideas are settling, but the tools, numbers, and links cited here will age — verify current details before betting an architecture on them.

The mental model

Strip away the frameworks and the hype, and there are only two shapes in artificial intelligence (AI) agent engineering. An agent is a large language model (LLM) running inside a loop: it reads its context, calls a tool, sees the result, and goes around again until it decides it's finished. An agent graph is several of those loops wired together — one loop delegating to others, their outputs flowing back as inputs. Everything else in the multi-agent conversation — orchestrators, subagents, workflows, swarms, crews — is a way of drawing edges between loops.

This post walks that arc in order: what the loop is, why it eventually hits a wall, what a graph of loops buys you, the patterns people actually use, what production systems taught us, and the very public debate about whether you should build any of this at all.

The agent loop

The most-quoted definition of an agent came from Simon Willison in September 2025, after he crowdsourced 211 competing definitions on Twitter and distilled them into one sentence: "An LLM agent runs tools in a loop to achieve a goal."^[1] That's not a metaphor — it's nearly the literal implementation. If you call a model through an application programming interface (API) and it asks to use a tool, you run the tool, append the result, and call the model again:

const messages = [{ role: "user", content: task }];

while (true) {
  const response = await claude.messages.create({ model, messages, tools });
  messages.push({ role: "assistant", content: response.content });

  if (response.stop_reason !== "tool_use") break; // the model answered

  const results = await runTools(response.content);
  messages.push({ role: "user", content: results });
}

Anthropic teaches the same loop in slightly richer terms in its Claude Agent software development kit (SDK): gather context → take action → verify work → repeat.^[2] One iteration looks like this:

What makes the loop remarkable is how far it goes before you need anything fancier. The team at MinusX reverse-engineered Claude Code — the most successful agent product of 2025 — and found "just one main thread" and "a simple while(tool_use) loop with sequential tasks", concluding: "Debuggability >> complicated hand-tuned multi-agent lang-chain-graph-node mishmash."^[3] Braintrust reported the same pattern from production teams: people start with graph frameworks and multi-phase planners, then retreat to the while-loop because it's the thing that survives contact with reality.^[4] Even Andrej Karpathy's 2025 year-in-review called Claude Code "the first convincing demonstration of what an LLM Agent looks like — something that in a loopy way strings together tool use and reasoning for extended problem solving."^[5]

Not everyone accepts the minimalist framing — swyx pushed back the same day Willison published, arguing that "llm + tools + loop + goal" describes only a minimal viable agent and that real ones also need intent, memory, planning, trust, and control flow (his thread on X). But notice what his additions have in common: they're all about managing what goes into the loop. Which points at the loop's real constraint — everything it knows, plans, and produces lives in a single context window, and that window is finite.

Where the single loop hits a wall

The single loop doesn't fail by crashing; it fails by degrading as its one context window fills up. Anthropic's context-engineering research describes an "attention budget": as token count grows, models get measurably worse at retrieving and reasoning over what's in context — a phenomenon they call context rot.^[6] A long-running loop accumulates every tool result, dead end, and intermediate file listing it has ever seen, and drags that weight into every subsequent decision.

Past a certain task size, three characteristic failure modes appear — Anthropic names them explicitly in its dynamic-workflows post:^[7]

Agentic laziness. The agent "stops before finishing a particularly complex, multi-part task and declares the job done after partial progress."
Self-preferential bias. "Claude's tendency to prefer its own results or findings, especially when asked to verify or judge them" — the agent that wrote the code is the wrong agent to review it.
Goal drift. A "gradual loss of fidelity to the original objective across many turns" — after enough iterations, the loop is optimizing for something subtly different from what you asked.

You can fight context exhaustion within one loop — compaction (summarize and restart the window) and structured note-taking (persist state to files outside the window) are the first two tools Anthropic recommends.^[6] But the third recommendation is the interesting one: give the work to other loops. That's where graphs come in.

Agent graphs: loops wired together

An agent graph is a set of agents — each one still a plain loop — connected by edges that define who talks to whom and what flows along each connection. The nodes do the reasoning; the edges carry compressed results. The canonical shape is orchestrator-workers: a lead agent holds the plan and the user-facing context, delegates scoped subtasks to worker agents, and synthesizes what comes back.

The obvious selling point is parallelism — three subagents search three directions at once. But the deeper reason agent graphs work is context isolation: each edge in the graph is a compression point, so the orchestrator receives distilled findings instead of inheriting every worker's exploratory mess. Anthropic's subagent docs are explicit about the mechanism: "Each subagent runs in its own fresh conversation. Intermediate tool calls and results stay inside the subagent; only its final message returns to the parent."^[8] In their research systems, workers explore with clean contexts and send back summaries of "typically 1,000-2,000 tokens" while "the detailed search context remains isolated within sub-agents".^[6] The graph is a context-management technique first and a parallelism technique second.

There's one more axis worth having in your head, because it explains most framework differences: who holds the plan. In Anthropic's December 2024 taxonomy, workflows are "systems where LLMs and tools are orchestrated through predefined code paths", while agents "dynamically direct their own processes and tool usage".^[9] The same distinction applies to graphs. A graph can be model-driven — an orchestrator agent decides at runtime which subagents to spawn — or code-driven, where a script owns the loops and branching and the model only fills in the nodes. Claude Code's dynamic workflows are the purest example of the second kind: "A dynamic workflow is a JavaScript script that orchestrates subagents at scale", running dozens to hundreds of agents while "Claude's context holds only the final answer".^[10]

The patterns

Almost every agent graph in production is built from a small vocabulary of recurring shapes. The 2024 foundation is Anthropic's Building Effective Agents taxonomy, ordered by increasing autonomy;^[9] the 2026 additions come from the dynamic-workflows work, which treats the graph itself as disposable generated code.^[7]

Pattern	Topology	Reach for it when
Prompt chaining	Straight line: each call feeds the next	The task decomposes into fixed sequential steps
Routing	One classifier fans into specialized branches	Inputs fall into distinct categories needing different handling
Parallelization	Same task or independent slices run side by side	Subtasks are independent, or you want multiple votes on one question
Orchestrator-workers	Star: a lead agent spawns and synthesizes workers	Subtasks can't be predicted up front — the model decides them at runtime
Evaluator-optimizer	Two-node cycle: generator ↔ critic	Output quality is checkable and iteration measurably helps
Fan-out-and-synthesize	Many finders → one merger	Broad discovery work: research sweeps, audits, migrations
Adversarial verification	Findings → independent skeptics → verdict	Countering self-preferential bias — the author must not be the judge
Tournament	N attempts → pairwise judging → winner	The solution space is wide and one iterated attempt underexplores it
Loop-until-done	A cycle that respawns finders until dry	The work's size is unknown in advance (bug hunts, edge-case sweeps)

The pattern worth internalizing first is adversarial verification, because it attacks the failure mode a single loop structurally cannot fix: an agent grading its own homework.

The skeptics work precisely because they are separate nodes in the graph: fresh context, no attachment to the finding, prompted to tear it down.

What production taught Anthropic

The best public data on agent graphs in production is Anthropic's write-up of its multi-agent research system: an orchestrator-workers graph with Claude Opus 4 as lead agent and Claude Sonnet 4 subagents searching in parallel.^[11] Three numbers from that post do most of the arguing:

The multi-agent system outperformed single-agent Claude Opus 4 by 90.2% on their internal research eval.
It cost roughly 15× more tokens than a chat interaction (a single agent already costs ~4×).
In their analysis of the BrowseComp benchmark, token usage alone explained about 80% of the performance variance — leading to the post's most honest sentence: "Multi-agent systems work mainly because they help spend enough tokens to solve the problem."

Read together, the numbers say the graph is not magic — it's a machine for spending more tokens productively than one context window can hold, which is transformative for some tasks and a pure waste for others. The same post is unusually clear about which is which. Graphs shine on breadth-first work: queries with several independent directions to explore, tasks that exceed a single context window, high-value questions that justify the cost. They do poorly where every agent needs the same shared context or the subtasks depend on each other — and the post calls out coding by name: "most coding tasks involve fewer truly parallelizable tasks than research."

The debate the graph started

That caveat about coding isn't a footnote — it was the center of the loudest architecture argument of 2025. On June 12, Walden Yan of Cognition (the company behind Devin) published Don't Build Multi-Agents, built on two principles: "Share context, and share full agent traces, not just individual messages" and "Actions carry implicit decisions, and conflicting decisions carry bad results."^[12] His example became famous: asked to build a Flappy Bird clone, one parallel subagent builds a Super-Mario-style background while another builds an incompatible bird sprite — neither saw the other's implicit decisions, and no merging agent can reconcile them. His conclusion: default to a single-threaded linear agent, and treat context engineering as "the #1 job of engineers building AI agents". Anthropic's multi-agent post shipped the next day, and the pairing framed a year of discourse.

The twist is that the two camps were never as opposed as the headlines suggested. Harrison Chase of LangChain praised Cognition's essay on X the day it landed, and LangChain's synthesis a few days later located the actual fault line: multi-agent works when subagents read (research, retrieval, review) and fails when they write (code, documents), because writing is where conflicting implicit decisions collide.^[13] Anthropic's own guidance agrees — its research graph fans out reads, and its subagent design (fresh context, only the final message returns) exists precisely to contain the conflicts Yan described.

By April 2026, Yan himself published a partial revision, Multi-Agents: What's Actually Working, announcing on X: "A year ago, I'd tell people to not build multi-agents and to focus on context engineering fundamentals. Today, many sexy ideas are still impractical, but we've found some setups that actually work." The revised thesis: "multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions."^[14] Their concrete win is a graph-shaped one — code-review agents with "completely clean context" catching an average of 2 bugs per pull request (PR), roughly 58% of them severe. The 2026 consensus, arrived at from both directions, is a hybrid: one loop owns the plan and every write; ephemeral subagents fan out to read, verify, and judge, returning compressed intelligence rather than actions.

The framework landscape

The major frameworks are best understood as different answers to the "who holds the plan" question — and most of the marketing noise between them dissolves once you see which edges of the graph each one makes explicit.

Framework	How it models agents	Multi-agent story
LangGraph	Explicit directed graph / state machine: nodes are steps or agents, edges are transitions over shared typed state	The graph is the program — control flow written by you, valuable when you need determinism and inspectability
OpenAI Agents SDK	One loop per agent, connected by handoffs (a specialist takes over the conversation) or agents-as-tools (a manager keeps it)	Decentralized triage vs centralized manager — two graph shapes as first-class primitives
CrewAI	Role-playing teams: agents with role, goal, and backstory in a "crew", run sequentially or under a manager agent	Organizational metaphor over explicit edges — the hierarchy implies the graph
Claude Agent SDK	One primary loop (gather → act → verify) with subagents for isolated, parallel reads	Model-driven delegation by default; script-driven dynamic workflows when the graph needs to scale to hundreds of nodes

Even the vocabulary has converged on the loop as the atom. LangChain's own Deep Agents post concedes that "using an LLM to call tools in a loop is the simplest form of an agent", then defines depth as what you add around it — planning, subagents, a file system (Deep Agents); by mid-2026 the company was writing about "loop engineering" outright (The Art of Loop Engineering). The frameworks disagree about ergonomics, not physics.

Choosing: loop or graph

The decision is less philosophical than the 2025 discourse made it look, because the trade-offs are now measured rather than argued:

Dimension	Single loop	Agent graph
Token cost	Low (~4× chat)	High (~15× chat)
Debuggability	One linear trace	Many interleaved traces
Context capacity	One window	Many isolated windows
Parallel throughput	Sequential	Fan-out
Write consistency	Single-threaded by nature	Safe only if writes stay single-threaded
Self-verification	Judges its own work	Independent skeptic nodes

strong good medium weak

Start with the loop; reach for the graph when the task is breadth-first, bigger than one context window, and valuable enough to pay for — and even then, let subagents read and verify while a single thread does the writing. That's not a compromise between the two camps of the debate; it's the position both of them independently reached. Anthropic's original advice from December 2024 still holds as the tiebreaker: find the simplest solution possible, and only add complexity when it demonstrably pays for itself.^[9]

The mental model​

The agent loop​

Where the single loop hits a wall​

Agent graphs: loops wired together​

The patterns​

What production taught Anthropic​

The debate the graph started​

The framework landscape​

Choosing: loop or graph​

References​