Agents: loops, plans and stopping

Start without one

The same guide recommends finding the simplest solution that works and adding complexity only when it clearly helps, which often means no agent at all. In order of increasing complexity:

1. One well-prompted call, maybe with retrieval.
2. A workflow: a fixed chain (classify, then draft, then check), routing (a cheap classifier picks which prompt handles the request), or parallel calls whose results are combined. Each step can be tested on its own.
3. An agent: when you cannot know in advance how many steps a task needs or which tools, such as investigating a bug across a codebase or researching a question across many sources.

Agents trade cost and latency for flexibility, and their failures compound: a small mistake in step two can send steps three to twenty in the wrong direction.

Planning and the loop

Many agents interleave reasoning and acting (the ReAct pattern): the model states what it is trying to find out, calls a tool, reads the result, updates its plan. Some write an explicit plan or to-do list first and revise it as they go; keeping that plan in the context helps on long tasks. Either way, your code owns the loop and the budget.

Stopping conditions

The model deciding it is done is one way to stop, and not the only one you need. The example runs a fake agent that gets stuck repeating itself and shows the guards that end the run.

A practical set of limits:

• Step, token, time and cost caps per run, enforced by your code.
• No-progress detection: repeated identical calls, or several steps without new information.
• A goal check where one exists, such as tests passing, the form validating, or every required field being filled.
• Human checkpoints: before irreversible or external actions (payments, emails, deletes, deploys), and when the agent is stuck or unsure.
• A clean failure: when a limit is hit, return what was found and why it stopped, rather than a made-up final answer.

Running agents in production

• Least privilege. Give the agent only the tools and permissions the task needs, scoped to the current user. Prefer read-only tools; gate writes.
• Trace everything. Store each step's input, the model's decision, tool calls and results. Agent bugs are only debuggable from traces, and good traces become eval cases.
• Persist state. A long run is a workflow with slow, failure-prone steps; checkpoint after each step so a crash or a provider outage resumes instead of starting over.
• Evaluate the whole task and the steps. Measure task success on a set of realistic tasks, and also cost, number of steps and how often it needed a human.
• Manage the context. Long runs fill the context window with tool results. Summarise or drop old results, and keep the goal and plan visible.