Agent loops: plan, act, observe

0:00 Agent loops

Agent might be the most overused word in AI marketing right now. Everything from a chatbot to a scheduled email gets called one. In this lesson you'll get a precise, practical definition, see the loop that every agent runs, learn the stop conditions that separate agents that work from agents that embarrass you, and walk through a hands-on loop with approvals and loop detection built in.

0:29 Analogy: train vs taxi

Why does the definition matter? Because agents cost more, run slower and fail in more interesting ways than workflows. Here's an analogy. A workflow is a train on rails: it goes exactly where the track goes, reliably. An agent is a taxi driver: you give a destination, and they choose the route, adapting to traffic. Taxis are wonderful when you don't know the route in advance. But you'd never use one for a journey the train already runs perfectly.

1:03 Agent vs workflow

Here's the definition. An agent is a system where the model directs its own process. It decides which tool to use next, looks at the result, and decides again, in a loop, until the goal is met or it hits a limit. A workflow is different: the steps are fixed in code and the model fills in individual steps. Both are valuable. Workflows are predictable and cheap. Agents shine when the path genuinely can't be known in advance, like research, debugging or open-ended customer requests.

1:40 Plan → act → observe

The loop is plan, act, observe. The model states a short plan, takes an action like a search or a database lookup, observes what comes back, and updates the plan. Asking for an explicit plan at the start, and a quick revision as observations arrive, helps the agent stay oriented on longer tasks. The model's reasoning is only as good as the feedback it gets, so every tool result should say clearly whether the step worked, like tests passed, zero rows returned, or validation failed on the date field.

2:19 Stop conditions

Now the part people skip: stop conditions. Every agent needs a maximum number of steps or tool calls; a budget in tokens, money or time; success criteria it can check, ideally in code, like the report contains all five sections with sources; and escalation rules, such as if you can't find the order after two searches, hand off to a human. Without these, agents loop, repeat failing actions and quietly run up bills.

2:51 Simple example: 'Has my order shipped?'

A simple example before the bigger one. The goal: find out whether a customer's order has shipped, and if not, why. The agent plans: look up the order, then check the warehouse if needed. It calls get order and sees status pending. It calls check warehouse and sees out of stock, restock Friday. It checks its definition of done, status and reason found, and replies to the customer's agent with both. Two tools, two steps, and a path that depended on what the first step revealed.

3:28 Worked example: pricing research

Let's watch one. The goal: a one-page comparison of three competitors' pricing pages. The agent plans: find the pages, extract tiers, compare. It opens competitor A: three tiers, easy. Competitor B hides pricing behind contact sales. A good agent records not public instead of guessing. It extracts C, checks its definition of done, all three covered with sources and gaps noted, and delivers with citations. A fixed workflow would have broken on B. The agent adapted, but within guardrails.

4:02 Business example (illustrative)

A deeper business example, illustrative. A Dubai product team ran the pricing research agent weekly across eight competitors. Each run took about twelve minutes and cost less than a coffee, versus half a day of an analyst's time. Twice in the first month it recorded pricing not public rather than guessing, which the analyst then checked by phone. The analyst now reviews a finished draft for twenty minutes instead of compiling it from scratch.

4:34 Failure modes

Common failure modes are worth memorising. Looping, repeating the same failed action, which you detect by spotting identical calls. Premature completion, declaring victory early, which you counter with explicit checks. Goal drift, getting lost in a sub-task, so restate the goal periodically. Compounding errors, where an early wrong assumption poisons later steps. And unsafe actions triggered by manipulated content, which you prevent with approval gates and by treating retrieved content as untrusted.

5:05 Autonomy is a dial

Treat autonomy as a dial, not a switch. Level one, suggest only. Level two, act with approval for each consequential step. Level three, act autonomously inside a sandbox or budget with review afterwards. Level four, act autonomously in production. Most business deployments today sit at levels two and three, and you move up only as evaluation and monitoring earn it. The lesson's hands-on code gives you a real loop with the Claude API: an approval gate for sending emails or refunds, detection of repeated identical calls, a token budget, and error results returned to the model instead of crashing.

5:48 Common mistakes

Common mistakes when building agent loops. No step limit, so a confused agent keeps going. Tools that return vague errors, so the agent can't recover. Asking for a plan but never letting it be revised. Treating a model's claim of done as proof, instead of checking in code. And jumping straight to high autonomy because the demo looked good. Every one of these shows up in real incident reports.

6:18 How you'll know it's working

How will you know your agent loop is healthy? Success rate against a checkable definition of done, measured over repeated runs. Median steps and tokens per task, which should be stable, not creeping upward. The number of loop-detection or step-limit stops, which should be rare. And the escalation rate: some escalation is healthy, because it means the agent knows when it's stuck.

6:45 Watch me do it: run_agent()

Watch me do it. I open run agent. First, the system prompt asks for a three to five line plan and to stop when done or explain the blocker. Next, inside the loop, I call the API, add input and output tokens to a running total, and append the assistant content. If the stop reason isn't tool use, I return done with the answer, steps and tokens. If the token budget is exceeded, I stop with reason budget. For each tool call, I build a key from the tool name and sorted JSON input. If I've seen that exact key, I return an error saying change approach. If the tool needs approval and the approver says no, I return a declined error. Otherwise I run the handler and catch any exception as an error result. I test it with a fake send email tool and an approver that always says no. The trace shows the agent drafting instead, and the run ends cleanly in three steps.

7:57 Recap

To recap: an agent lets the model choose its next step in a loop; a workflow fixes the steps. The loop is plan, act, observe, with informative feedback, and it always needs step limits, budgets, a checkable definition of done and escalation rules. Your next step is to design one agent on paper: goal, definition of done, tools, step limit, budget and two escalation rules. Then compare it with a simple workflow and ask honestly which one you need. For a deep build, see the Building Production AI Agents course.

8:36 Try this now (15 minutes)

Try this now. Pick one open-ended task from your work where the steps really do depend on what you discover, like researching a prospect or investigating a customer complaint. On one page, write the goal, a checkable definition of done, the tools it needs, a step limit, a budget and two escalation rules. Then ask honestly: could a fixed workflow do this? If yes, build that instead.