An agent loop is the repeating cycle that turns a single model call into a program that does work. The noun refers to the pattern, not any specific library: the model observes some state, decides what to do next, performs an action such as calling a tool or running a command, then interprets the result and loops again. Compared with a plain chat completion, an agent loop adds three things: an external state the model can read, an external state the model can change, and a stopping rule so the cycle can converge instead of wandering forever. Without that stopping rule, the loop either runs until a token budget is exhausted or until an error finally stops it, and neither outcome is what a builder wants.[1]
Step by step, the loop looks like this. The harness gathers context (system prompt, recent messages, tool results, retrieved documents), calls the model, and parses the response. If the response contains a tool call, the harness executes it, captures the output, and feeds that output back into the next model call as additional context. If the response is plain text, the harness treats it as a progress update, an answer, or a request for human input depending on policy. The model is the decision maker; the harness is the runtime that enforces limits, persists state between turns, handles errors, and decides when the model has actually finished. Loops that ship reliably share the same hygiene: explicit completion detection, action or step caps, retry and backoff logic, and structured logging so you can see why a loop terminated the way it did.[3]
Practitioners choose a loop because language on its own cannot read a file, run a test, or query a database. A loop lets a model keep acting until a real-world condition is satisfied, which is the difference between answering a question and completing a task. The most common failure mode is a loop that never converges: the model adds another step each turn, context fills with stale tool results, and the next decision is made on a corrupted view of state. A second failure mode is the opposite problem, premature termination, where the loop stops on the first plausible-sounding answer instead of verifying the result. Before building custom orchestration, classify the work into a named pattern such as a read-then-edit loop, a search-and-summarize loop, or a tool-orchestrated pipeline; reusing a known shape is faster than inventing one and easier to debug when it misbehaves.[1][2]
A read-then-edit loop on a bug report
A bug report says that /api/orders returns 500 when a customer has no address. The agent has two tools: read_file and apply_patch. The harness caps the loop at 8 steps and stops when the model emits a final answer with no tool call.
- 01Step 1. Harness calls the model with the bug report and the list of available tools. The model replies with a tool call: read_file('/app/handlers/orders.py').
- 02Step 2. Harness reads the file, returns its contents as a tool_result message. The model calls read_file('/app/models/customer.py') to find the Customer schema.
- 03Step 3. Harness returns that file. The model sees Customer.address is nullable, then calls apply_patch with a guard clause that checks for a missing address and returns 422 with a clear error.
- 04Step 4. Harness applies the patch, returns a diff and a patch-applied confirmation. The model reads the diff, calls read_file one more time to verify the change, then emits a final text answer summarizing the fix.
- 05Step 5. Harness sees the final answer has no tool call, marks the loop complete, and surfaces the summary to the user.
A good loop separates decision making (the model) from execution and bookkeeping (the harness), and it always has a clear termination condition. If you cannot name the condition that ends the loop, the loop is not finished, it is just lucky.