From completion to agent loop

An agent is not a smarter completion. It is a change in who owns control flow.

Completion

The model is a stateless function inside your program. Your code builds the prompt, makes one call, reads the text. Every branch, retry and stop is code you wrote and can test.

Agent loop

The model picks the next action. It may call a tool or finish. Your code checks the limits, runs the tool, appends the result, and calls the model again. The loop ends when the model finishes, or when your code stops it on a step cap, a token or wall-clock budget, or a rejected approval, and returns partial work with a reason. The limits check in the diagram is drawn in sienna because it is the one box the model does not own.

The vocabulary

Anthropic’s December 2024 essay “Building effective agents” gives names that hold up. The augmented LLM is the building block: a model with retrieval, tools and memory, where each tool result costs another model call. Workflows fix the pattern in code: prompt chaining, routing, parallelisation, orchestrator-workers, evaluator-optimizer. Agents let the model direct its own process and tool use, for open-ended tasks whose path cannot be written ahead, at the price of turns, latency and tokens that vary per run.

Every loop needs

• A maximum step count, a token budget and a wall-clock budget.
• Explicit stop conditions, and tool permissions scoped to the task.
• Human approval before any consequential action: a write to a system of record, a message outside the team, money spent.

Where it goes wrong

A loop with no step cap, and a tool that returns the same ambiguous error every time. It burns calls all night.

What to do

• Can you write the path at build time? Ship a workflow.
• If the next step depends on tool results, let the model loop, inside limits you enforce in code.
• Return partial work with a reason. A silent stop is the hardest failure to debug.