Loop or Graph?

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Not everything should be a graph. See when one loop with a checker is the better shape, when work needs a graph of nodes, edges and shared state, and how to tell the two apart.

Watch a Graph Lose to One Loop

Here is a one-line fix: a typo in one file. Someone built a four-node graph for it: plan, edit, review, test. It looks serious and well organised.

Run it next to one plain loop. Watch the scorecards.

The graph did not do a better job. It used about three times the tokens and took longer. Every extra node had to read a handoff note, start up, and pass its own note on. The fix was already easy for one agent.

This is the most important lesson in the course: not everything should be a graph. In this lesson you learn to tell when one loop is enough, and when the work really needs a graph.

TL;DR

• A graph wires several steps together. Nodes do the work. Edges route between nodes. Shared state flows along the edges.
• A loop is a graph with one node and an edge back to itself. So every agent node in a graph is still a loop.
• Five patterns build every graph: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer.
• Research on 260 agent setups found that extra agents help work that splits into independent parts, and hurt strict step-by-step work, or work one agent already does well.
• So the first question is always: does this need a graph at all? Pick the simplest shape that works.

A Real-World Example

Mia runs the loop she built in the Loop Engineering course. It works through her team's backlog every night. Most tickets are small: a typo, a version bump, a label.

Then one night the loop picks up a ticket that changes how payments are rounded. It treats it like a typo. It writes a fix, the tests pass, and it marks the ticket done. Nobody checked it with care, because the loop has only one path.

Mia does not need a bigger loop. She needs a second path. Small tickets take the quick path. Tickets that touch money or logins take a careful path that ends with a person's approval. That is a small graph: one router and two paths.

But Mia's other job, "make the three failing tests in one file pass", stays a single loop. One agent does it well, and the test command is a perfect checker.

What You Will Learn

• What graph engineering is, and how it builds on loop engineering
• The three parts of every graph: nodes, edges and shared state
• Why a loop is just a graph with one node
• The five patterns, and how each one fails
• What research says about when extra agents help and when they hurt
• How to pick loop or graph for a real task, and prove it on a scorecard

Cheat Sheet: Where a Graph Lives in Each Tool

None of the three tools has a "graph" button. In each one, a graph is an agent that follows a written plan (a file called graph.md) and hands work to subagents, with the shared state kept in a file. So you learn the graph once, and only the file names change per tool.

The Ladder: From Prompt to Graph

You have climbed this ladder already. A prompt is one message. Context is everything the model sees. A harness adds rules, tools and checks. A loop runs the harness again and again until a goal is met.

A graph is the next step. It wires several loops together, so each one does one job.

Loop engineering took the human out of the repetition. Graph engineering fixes the ways a single loop fails because of its shape:

• It ends too early, or does steps in the wrong order.
• It gets stuck on one hard item.
• It drowns one context window in everything: every ticket, every dead end, every log.

The word "graph engineering" spread in July 2026, after a joke post by Peter Steinberger asked "are we still talking loops or did we shift to graphs yet?" But the patterns are older. Anthropic described them in 2024, in Building Effective Agents.

The Three Parts of a Graph

Every graph has three parts.

Nodes do the work. A node can be:

• plain code, such as a test run or a schema check;
• one model call: one prompt in, one answer out;
• a full agent running its own loop, with a checker and a stop rule.

Each node does one job.

Edges route between nodes. An edge can be:

• fixed: A, then B;
• conditional: go here if the ticket is high risk, there if it is low;
• loop-back: go back to the fixer if the review fails;
• fan-out: start several nodes at once;
• fan-in: wait for several nodes at a join.

Shared state is a small, typed record that travels with the work: the task, the results so far, and the checks that passed. Two rules keep it safe. Each field has one writer. And each node gets only the fields it needs.

Here is a tiny graph in code. The state moves along the edges, and each node sees only its fields:

State flows along the edges

const state = { report: "Login fails after a password reset", findings: null, script: null };

const nodes = {
  investigate: { reads: ["report"], run: (s) => ({ findings: "token is reused after reset" }) },
  write:       { reads: ["findings"], run: (s) => ({ script: "reset(); login(); // expect 401" }) },
};
const edges = [["investigate", "write"]];

let at = "investigate";
while (at) {
  const node = nodes[at];
  const input = Object.fromEntries(node.reads.map((f) => [f, state[f]]));
  Object.assign(state, node.run(input));
  console.log(at + " read " + Object.keys(input).join(", ") + " -> wrote " + Object.keys(node.run(input)).join(", "));
  at = (edges.find((e) => e[0] === at) || [])[1];
}
console.log("final script: " + state.script);

Expected output:

investigate read report -> wrote findings
write read findings -> wrote script
final script: reset(); login(); // expect 401

The writer never saw the bug report or the investigator's dead ends. It started clean, with only the findings. That small idea, context isolation, is what Lesson 3 is about.

A Loop Is a Graph With One Node

Now look at the loop you built in the last course. It has one agent, and when the checker fails, it goes back and tries again. Drawn as a graph, that is one node with an edge back to itself.

A loop, written as a graph

const loop = {
  nodes: ["worker"],
  edges: [{ from: "worker", to: "worker", kind: "loop-back" }],
};

const isSingleLoop = (g) =>
  g.nodes.length === 1 && g.edges.every((e) => e.from === e.to);

const size = (g) => g.nodes.length + g.edges.length;

console.log("single loop: " + isSingleLoop(loop));
console.log("size: " + size(loop) + " (nodes + edges)");

Expected output:

single loop: true
size: 2 (nodes + edges)

So "loop or graph?" is not a choice between two different things. It is a question of how many nodes the work needs. The answer is often one.

See It in the Lab

The same tiny fix as before, as one loop and as a graph. Open the Graph file tab to read both shapes as YAML. Each node lists what it reads and what it writes.

The Five Patterns

Every graph you will see is built from five patterns. Each one buys you something, and each one fails in its own way. This course gives each pattern its own lesson.

Routing is the pattern Mia needed. Here is the idea in a few lines:

Route by risk: two paths, one fallback

const tickets = [
  { id: 1, area: "docs" },
  { id: 2, area: "payments" },
  { id: 3, area: "ui" },
  { id: 4, area: "auth" },
  { id: 5, area: "???" },
];

const LOW = ["docs", "ui", "deps"];
const HIGH = ["auth", "payments", "migration"];

function route(t) {
  if (LOW.includes(t.area)) return "quick path";
  if (HIGH.includes(t.area)) return "careful path + human gate";
  return "careful path + human gate"; // unsure: take the safe path
}

for (const t of tickets) console.log("#" + t.id + " " + t.area + " -> " + route(t));

Expected output:

#1 docs -> quick path
#2 payments -> careful path + human gate
#3 ui -> quick path
#4 auth -> careful path + human gate
#5 ??? -> careful path + human gate

Notice ticket 5. The router did not know its area, so it took the safe path. A router with no safe fallback is one of the first things the linter in this course flags.

See a Graph Win

A graph is the right shape when the work has different risk levels. Run 40 mixed tickets through one loop and through a small routed graph.

The loop gave every ticket the same treatment, so the risky ones were handled like typos. The graph spent less on easy tickets and more care on risky ones.

The Honesty Rule: What Research Found

It is tempting to think more agents means better work. A large study by Google Research, Google DeepMind and MIT tested 260 agent setups on six kinds of tasks. It found three things:

• When one agent already got the task right more than about 45% of the time, adding agents made results worse.
• On work that splits into independent parts that can run at the same time, multi-agent setups did up to 80.8% better.
• On strict step-by-step planning, they did 39% to 70% worse. Every handoff loses some detail.

Two More Runs

Run each one. Before you press Run, guess the winner.

The audit split into 18 independent checks, so the graph ran them side by side and finished much sooner. The small feature was a strict sequence: plan, code, test, review. Split over four agents, each handoff dropped details, and quality fell.

The Decision: Five Questions

Ask these about the task. Any "yes" is a reason to consider a graph. All "no" means: keep one loop.

1. Does the work split into independent parts? Then branches can run at the same time (parallelization).
2. Does the work mix risk levels? Then a router can send risky work down a careful path (routing).
3. Does one step leave dead ends that would confuse the next? Then a clean handoff helps (prompt chaining).
4. Is the work list only found while running? Then an orchestrator can start workers for it (orchestrator-workers).
5. Is there a clear pass test, and the fix needs several tries? Then a fixer and a checker can go round (evaluator-optimizer). Note that your loop already does this.

And one question that points the other way: is this a strict step-by-step plan that one agent does well? Then keep one loop, however big the task feels.

One more rule. Before you add a node, check what the loop is missing. Give the loop that thing first. A loop that cannot run the tests needs a test tool, not a second agent. MarkTechPost puts it simply: extend the loop's tools before adding agents.

Does this task need a graph?

function shapeFor(t) {
  if (t.strictSteps && !t.riskMix) return "loop";
  const reasons = [];
  if (t.independentParts) reasons.push("parallel");
  if (t.riskMix) reasons.push("routing");
  if (t.deadEnds) reasons.push("chaining");
  if (t.foundWhileRunning) reasons.push("orchestrator");
  return reasons.length ? "graph (" + reasons.join(", ") + ")" : "loop";
}

const tasks = {
  "fix one typo":           { strictSteps: true },
  "audit 6 packages":       { independentParts: true },
  "work 40 mixed tickets":  { riskMix: true },
  "bug report to repro":    { deadEnds: true },
  "fix 3 failing tests":    {},
};

for (const [name, t] of Object.entries(tasks)) console.log(name + " -> " + shapeFor(t));

Expected output:

fix one typo -> loop
audit 6 packages -> graph (parallel)
work 40 mixed tickets -> graph (routing)
bug report to repro -> graph (chaining)
fix 3 failing tests -> loop

Prove It on a Scorecard

A good choice is not a feeling. In the lab, both shapes run on the same task and get the same scorecard: quality, tokens, wall time and size. The rule for the winner is simple:

• Clearly better quality wins.
• If quality is close, the shape that uses far fewer tokens wins.
• If it is still close, the simpler shape wins.

Who wins the scorecard?

function winner(loop, graph) {
  if (graph.quality - loop.quality > 3) return "graph: better quality";
  if (loop.quality - graph.quality > 3) return "loop: better quality";
  if (graph.tokens < loop.tokens * 0.8) return "graph: close quality, far fewer tokens";
  return "loop: close quality, so the simpler shape wins";
}

console.log(winner({ quality: 93, tokens: 900 },   { quality: 77, tokens: 3300 }));
console.log(winner({ quality: 70, tokens: 165000 }, { quality: 94, tokens: 21800 }));
console.log(winner({ quality: 92, tokens: 6000 },  { quality: 91, tokens: 5900 }));

Expected output:

loop: better quality
graph: better quality
loop: close quality, so the simpler shape wins

Lab Exercise: Loop or Graph? Eight Tasks

Now decide for yourself. The Decide tab has eight task cards. For each one, pick One loop or Graph. Use Compare in Run on any card to see both scorecards before you choose.

Then press Check my picks. Each pick runs on 3 versions of the task. A pick counts only if it wins on all three. You need 7 of 8.

Common mistakes

Exercises

Each exercise ends with a value on the last line. Press Check to compare it with the expected answer.

What to Remember

• A graph has nodes (do the work), edges (route) and shared state (flows along the edges).
• A loop is a graph with one node and an edge back to itself. Every agent node in a graph is still a loop.
• Five patterns build every graph: chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer.
• Extra agents help independent, risk-varied or run-time work. They hurt strict step-by-step work and work one agent does well.
• Pick the simplest shape that works, and prove it on a scorecard.

Further Reading

• How to Implement Graph Engineering: 5 Composable Patterns, by QA Wolf: nodes, edges and state, the five patterns, how each fails, and the 260-setup research summary.
• Building Effective Agents, by Anthropic: the 2024 article where these patterns were first described.
• Graph Engineering vs Loop Engineering, by AI Builder Club: why a loop is a one-node graph, and an honest look at the hype.
• Prompt Engineering vs Loop Engineering vs Graph Engineering, by MarkTechPost: the three layers compared, and "extend the loop's tools before adding agents".
• Loop Engineering, by Addy Osmani: the loop every node in this course is made of.
• The Loop Engineering course on this site builds the loop that every node in this course is made of.

Next: Nodes, Edges, Shared State. A node that reads the whole state overwrites another node's work, and you write a state contract that stops it.