A chatbot answers once and stops. An agent keeps going — it takes a step, sees what happened, decides the next step, and repeats until the job is done. That repeating cycle is the agent's loop, and designing it well is the difference between an agent that quietly completes a task and one that gets stuck, wanders off, or runs forever. This course is about engineering that loop.
- Understand the core agent loop and why repetition makes agents powerful
- See how an agent uses feedback from its own actions to self-correct
- Design loops that converge (finish) instead of wandering or spinning
- Know when a simple fixed workflow beats a free-roaming loop
The core loop: plan, act, observe, repeat
A single model call is one shot: question in, answer out. But many real tasks cannot be done in one shot — they need several steps, and each step depends on what the last one revealed. So an agent runs a loop.
┌──────────────────────────────────────────┐
│ ▼
┌─────────┐ ┌───────┐ ┌─────────┐ ┌──────────────┐
│ PLAN │──►│ ACT │──►│ OBSERVE │──►│ DONE? CHECK │
│ what's │ │ use a │ │ see the │ │ if not, loop │
│ next? │ │ tool │ │ result │ │ again │
└─────────┘ └───────┘ └─────────┘ └──────┬───────┘
▲ │ done
└──────────────── not done ────────────────┘ ▼
finish
A worked example — "Find the cheapest flight to Lisbon next Friday and hold it."
- Plan: I need to search flights first.
- Act: call the flight-search tool.
- Observe: three options come back.
- Check: not done — I still need to pick the cheapest and hold it. Loop.
- Plan → Act → Observe: pick the cheapest, call the hold tool, get a confirmation.
- Check: done. Finish.
The power is that the agent adapts as it goes — it did not need the whole plan up front, just the next step, informed by what it just saw.
- An agent runs a loop: plan the next step, act, observe the result, check if done
- Each step is informed by the last — the agent adapts as it learns
- This lets agents handle multi-step tasks a single answer never could
Self-correction: learning from what went wrong
The loop's quiet superpower is recovering from mistakes mid-task. Because the agent observes the result of each action, it can notice when something failed and try a different approach — without a human stepping in.
A coding agent is the classic example: it writes some code, runs it, sees the error message, reads it, fixes the bug, and runs again — looping until the tests pass. The error message is feedback, and the loop lets the agent use that feedback. A one-shot model would have handed you broken code and stopped.
- Observing each result lets the agent notice failures and try again
- A coding agent loops: write, run, read the error, fix, repeat until it passes
- Self-correction depends on the agent seeing real outcomes (feedback)
- Walk through the four stages of the loop for the task "order more printer paper when it runs low."
- Why can a looping agent fix its own buggy code when a single model call cannot?
Making loops converge — not spin
Loops are powerful and dangerous. A poorly designed loop can run forever, repeat the same failed action, or wander away from the goal — burning time and money. A core job of loop engineering is making sure the loop converges: it gets closer to done and then stops.
The guard rails that make loops safe:
A clear 'done' condition
The agent must be able to recognise success — the test passed, the booking is confirmed, the question is answered. Vague goals make loops that never end.
A step limit (a budget)
Cap the number of loops. If the agent hasn't finished in, say, 10 steps, stop and report — rather than spinning forever. A budget protects your time and cost.
Loop detection
Notice when the agent repeats the same action with the same result — a sign it is stuck. Break out and try a different path or ask a human.
Progress checks
Every few steps, ask: am I actually getting closer? If not, change strategy instead of grinding on.
- Loops can spin forever, repeat failures, or drift off-goal
- Make them converge with a clear "done" condition and a step budget
- Add loop detection and progress checks to catch stuck agents early
When a fixed workflow beats a free loop
A free-roaming loop — where the agent decides each step itself — is flexible but unpredictable. For many real tasks, you do not want that freedom. If the steps are always the same (fetch order → check status → draft reply → send), a fixed workflow is better: more reliable, cheaper, easier to test.
This is the maturity point of the whole journey: you have a model (the engine), a harness around it (the car), and a well-designed loop (how it drives). The last thing standing between you and a real product is running it safely, day after day, in the real world — which is the final course, AI Ops.
- Free loops are flexible but less predictable; fixed workflows are reliable but rigid
- Use free loops only where the path truly varies; use workflows where steps are stable
- The best systems are mostly structured, with agent freedom only where it's needed
- List two guard rails that stop a loop from running forever.
- Give one task you'd build as a fixed workflow and one you'd build as a free agent loop.