Graph engineering academy · module 1 of 7 · 6 min

What is an agent loop?

What happens when a model decides which tool to use, again and again?

  • Name the four beats of a loop: observe, decide, act, receive feedback.
  • Tell a model decision from a tool running.
  • Say what stops a loop and why the model should not be the only thing that can.

An agent loop has four beats. The agent observes what it has so far: the request and every result it has received. It decides what to do next, which is the only part a model does. It acts, which means a tool runs as ordinary code. It receives feedback: the tool's result joins what it observes. Then it repeats, until it decides to answer or something outside it says stop.

Press play below and watch the green ring. Every time it lights, a model is deciding; every time a rectangle lights, plain code is running. Then try the scenarios: a tool that hangs, a file that contains instructions, a budget cut to three steps.

Learning simulation

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.

A request enters from the left into a model ring. Three tools sit to its right: read file, run tests, edit file. Each tool call returns to the ring, which holds a context window above it and a step budget below it. When the ring answers, the result leaves to the right; when the budget runs out, the loop escalates to the developer at the bottom right.promptevery turncallcallcallcallcallcallresultresultresultresultresultansweranswerexhaustedexhaustedapproveapproveRequestContext windowrequest · resultsModel decidestool call or answerStep budget12 steps · 40k tokensRead filepath → contentsRun testspass/fail + logEdit filepath + diffAnswerDeveloperapprove · interrupt
ready
Every step in words

  1. 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.

  2. 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.

  3. 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.

  4. Every turn, code outside the model compares steps, tokens and elapsed time against the limits. 1 of 12 steps used; the loop may continue.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. The edit tool checks that the old text still matches, applies the replacement, and returns a confirmation. Deterministic; no model involved.

  10. An edit is a hypothesis. The model re-runs the suite to turn it into evidence rather than declaring success.

  11. Exit code 0. The loop now has proof, not a claim.

  12. With passing tests in context, the model chooses to answer instead of calling another tool. That choice is what ends the loop.

  13. The developer receives the summary, the diff and the test log. Five model calls, four tool calls, one approval.

What a loop is good at

  • Jobs whose steps depend on what each step reveals.
  • Verifying its own work by running tools.
  • Being simple: one model, one list of tools, one budget.

Where a loop strains

  • The model decides the order every time, so the order is never guaranteed.
  • Its state is a growing conversation, readable but unstructured.
  • It lives in memory: it cannot wait a day for a person or survive a crash.