Graph engineering academy · module 3 of 7 · 10 min
From a loop to a graph
What changes when the same job is a graph instead of a loop?
- Compare two architectures on one task.
- List what a graph makes explicit: control flow, handoffs, state, checkpoints, approval, recovery.
- Explain why a graph is not more powerful than a loop, only more explicit, and what that costs.
Same kind of job, two architectures. A risky code change arrives. In architecture A one agent handles it in a tool loop and asks a person when it judges it should. In architecture B a graph classifies the risk with rules, sends risky changes to a plan and a reviewer, saves its state before waiting, and loops implement and verify at most three times.
Run both. Then pick a capability on the left of the comparison to see how each architecture provides it, and what the graph pays for it.
Input The test `parses dates with timezones` in parser.test.ts is failing. Fix it. The ordinary case: read, run, edit, re-run, answer. Six decisions, four tool calls.
Every step in words
The developer’s request is the first and only trusted instruction. It is written into the context window along with the project notes and the list of available tools.
The model cannot fix what it has not seen. Reading the test first is the cheapest way to learn what "failing" means here. This is a decision, so it is a model call.
A tool is ordinary code. It returns the file contents, which are appended to the context as data. The model has not run during this step.
Every turn, code outside the model compares steps, tokens and elapsed time against the limits. 1 of 12 steps used; the loop may continue.
The test file explains the expectation but not the current behaviour. Running the suite gives the actual failure message, which is better evidence than guessing from the source.
The test runner executes in a sandbox with a 60-second timeout and returns exit code 1 plus the log. The log is the evidence the next decision will use.
The log names the cause: the offset is parsed but not applied. The model proposes a diff. Because editing changes the world, the permission mode decides whether a human sees it first.
The loop is in a cautious permission mode: edits wait for a human. The developer reads the diff and approves it once. In a trusted mode this step would not appear.
The edit tool checks that the old text still matches, applies the replacement, and returns a confirmation. Deterministic; no model involved.
An edit is a hypothesis. The model re-runs the suite to turn it into evidence rather than declaring success.
Exit code 0. The loop now has proof, not a claim.
With passing tests in context, the model chooses to answer instead of calling another tool. That choice is what ends the loop.
The developer receives the summary, the diff and the test log. Five model calls, four tool calls, one approval.
Explicit control flow
- In the loop
- The model decides the order every time it runs.
- In the graph
- The order is written down; the model decides inside a node.
- What the graph costs
- You must know the order well enough to write it.
A graph is not more powerful than a loop. The loop above is a graph: one node that decides, a few tool nodes, an edge back. The graph can contain loops, and does: implement and verify repeat until the tests pass. What the graph adds is structure written down where the job needs it, at the price of designing, testing and versioning that structure. Choose it when a requirement forces it, not by default.
The Agents & Humans Briefing
How humans and agents work together: the day's field notes and the patterns behind them, in one short email around noon UTC.
Free. No spam. Unsubscribe anytime.