The loop: think, act, look
Every agent you will ever build is the same eight-step cycle, repeated until something says stop. Once you can see the cycle, you can debug any agent.
- You can trace any agent step by step and point at the exact iteration where it went wrong.
- You know the seven ways a loop is allowed to end — and why "the model decided it was done" is the weakest of them.
Here is the whole thing, in one sentence: build the best context you can, ask the model what to do next, do it, look at what happened, write it down, repeat. The model supplies judgement; the loop supplies persistence, safety and the ability to stop.
3.1Walk one real task
Step through a booking task. Watch what changes at each step — and notice how much of the work is the harness, not the model.
"Book the cheapest direct flight to Chicago on Thursday that gets me there before 10am, then put it on my calendar."
The harness turns prose into a checklist: direct, Thursday, before 10:00, cheapest, calendar entry. That checklist is what "done" will be verified against.
System prompt (how to behave), the goal, available tools (flight search, calendar), the user's home airport and preferences, and an empty history.
Only what fits in the budget is sent. The model has no memory of yesterday unless the harness includes it.
Model output: search_flights(origin="PHL", dest="ORD", date="Thu", direct=true)
Note what it did not do: it did not search the web. It emitted a structured request, which the harness will now validate and route.
The tool is marked risk: low and read-only, so it runs without asking. Had it been book_flight, the harness would stop and request approval — the gate is decided in code, not by the model's judgement.
The tool calls an API with a timeout, a retry policy, and a validated response schema. It returns four options, one of them sold out.
Failures here are normal. A timeout is data, not a crash — the loop can adapt.
The result is trimmed to the useful fields and appended to the history as a tool message. Errors are formatted too: "sold out" is information the model can act on.
The task list now shows search done, two viable flights, one below budget. The loop returns to step 2 — context is rebuilt including the new observation — and the model chooses the next action.
This is where most of the token bill is generated: each iteration resends a growing context.
The agent has a booking confirmation and a calendar event. It stops because the checklist is satisfied and verified by tool output — not because the model "feels finished".
3.2How a loop is allowed to end
Agents fail in two directions: they stop too early and declare victory, or they never stop. A serious harness does not rely on the model's opinion for either. It enforces limits and reports them.
| Stop condition | Why it exists | What "good" looks like |
|---|---|---|
| Verified completion | The goal checklist is satisfied by evidence, not by the model's summary | "Tests pass" is a tool result; "I believe the tests pass" is not |
| Max turns | Loops can oscillate between two wrong ideas forever | Stop at N, return partial work plus a clear "I got stuck here" |
| Budget | Tokens are money; a runaway loop can cost hundreds of dollars in minutes | Hard cap, warn at 80%, record spend per task |
| Wall-clock timeout | Some tools hang; some tasks are no longer worth finishing | Per-tool and end-to-end deadlines, propagated to sub-tasks |
| Repeated failure | Three identical failures mean the approach is wrong | Escalate to a human or replan, never silently retry a fourth time |
| Human interrupt | A person may simply want it to stop | Cancellation is cooperative, fast, and leaves state consistent |
| Needs input | Ambiguity or a high-stakes action | Ask one precise question with the options you already know |
3.3Three shapes the loop takes
ReAct — interleaved
Think, act, look, think. Maximum flexibility, minimum predictability. Best for open-ended research and exploration where the next step genuinely depends on the last result.
flexible · chatty · can wander
Plan-then-execute
One planning pass produces an ordered list; an executor works through it and only replans on failure. Cheaper, auditable, easier to approve — the plan itself becomes an artifact.
auditable · brittle to surprises
Thought → tool → thought
Several tool calls issued in one turn, all results returned together, then one decision. Fewer round-trips and lower latency, ideal when calls are independent (read five files at once).
fast · needs parallel-safe tools
Whichever shape you choose, the same three things must be true: the model's output is parsed into an action, the action is checked before it runs, and the result is written into state in a form the next iteration can use. If any of those is missing, you have a demo, not an agent.
The most common production failure isn't a crash. It's an agent that finishes, reports success in confident prose, and did nothing — or did the wrong thing — because the loop trusted the model's summary instead of a verifiable result. Make the last step of every task a check, not a claim.
An agent keeps retrying the same failing API call. Which fix belongs in the harness?
60-second recap
- Eight steps, endlessly repeated: goal → context → decide → permission → execute → observe → state → stop.
- The harness owns the arrows. Permissions, retries, budgets and termination are code, not instructions.
- Every iteration resends a bigger context — that's where cost and latency live.
- Stopping is a design decision. Verified completion beats "the model said it was done", every time.