You can already name the parts of an agent: model, instructions, tools, state, and a loop. You can tell chat from an agent, and a connector from an autonomous workflow. Now you need the skill that keeps all of that machinery honest — running the loop itself without letting it run away from you.

An agent without a loop is just a chatbot with extra tools attached. An agent without a stop condition is worse: it is a system that can keep calling, spending, and "making progress" long after a human would have paused and asked whether any of this is working.

The loop in plain language

Every agent run follows the same rhythm, no matter how fancy the model or how many tools it holds:

think / plan → act → observe → update state → decide: continue or stop

Say it in working terms:

1. Think / plan. Given the goal and the current state, what is the smallest useful next step? Not the whole grand plan — the next step. 2. Act. Call one tool, or produce one draft, using exact inputs. One action per turn keeps results inspectable. 3. Observe. Read what came back. Did the tool succeed? What did it actually return — evidence, or an error dressed up as progress? 4. Update state. Write down what happened: steps used, sources checked, errors seen, output location. This is the durable record from Class 28, not just conversation memory. 5. Decide. Continue to the next step, or stop. Stopping is a first-class decision, not a failure.

A chatbot ends when it produces an answer. An agent ends when its stop condition says the work is done, blocked, or out of budget. That difference is the whole lesson.

A research loop you can inspect

Take a concrete job: a source researcher watches five approved sources and produces one evidence packet per day. Here is its loop, written so every step leaves something you can check:

1. Inspect the source list. Load the approved list from state — say, five named feeds or documentation pages. No new sources are invented mid-run. 2. Choose an approved query. Pick the next unchecked source and the exact query or fetch for it. "Fetch source 3 of 5, items since yesterday" is inspectable. "Search the web for interesting stuff" is not. 3. Retrieve evidence. Call the read tool, save the raw result with timestamp and source name. Raw first, summary second. 4. Assess completeness. Compare what you have against the packet requirement: at least one item per source checked, duplicates flagged, confidence noted. Ask: do I have enough to write the packet, or am I missing something specific? 5. Save a draft or request review. Either write the packet to its output file, or stop with a missing-information note and hand it to the review queue. Both are legitimate endings.

Notice what the loop never does: it never re-queries the same failing source five times hoping for a different result, never widens the source list on its own, and never publishes. Those boundaries come from the agent card and the approval gates in the next lesson.

Four ways loops go wrong

Loops fail in predictable ways. Learn the four now and you will recognize them in every agent you operate:

1. Repeat-fail. The agent calls a failing tool again with the same inputs, gets the same error, and tries once more. Three identical failures is not persistence — it is a stuck loop. The fix is a retry limit plus a rule: same error twice means change inputs, switch sources, or escalate, never blindly retry.

2. Unbounded cost. Each loop turn burns model tokens and possibly paid tool calls. A loop with no step cap can turn a two-cent task into a twenty-dollar surprise. The fix is budgets — max steps, max tool calls, max spend — covered in Lesson 30.3.

3. Source drift. The agent starts with approved sources and quietly wanders: a suggested link leads to another link, which leads to an unvetted page, which becomes "evidence." The fix is a source lock. The run may only cite the approved list; anything else is flagged as unapproved, never silently absorbed.

4. False progress. The most dangerous failure, because it looks like success. The agent narrates confidently — "I have gathered comprehensive evidence" — while the logs show two empty retrievals and one duplicate. Fluent narration is not proof. The fix is evaluation against logs and schema, covered in Lesson 30.4: check what was retrieved, not what the agent claims.

Put together, the rule is simple: a loop you cannot inspect, count, and stop is not an agent workflow. It is an open tab with your credentials.

Practical exercise: draw a five-step loop plus three stops

Pick one small agent: a daily source watcher, a ticket classifier, or a freshness checker from Class 28.

1. Draw its loop in five steps using the think → act → observe → update → decide shape. Name the exact tool or output at each act step. 2. Write three explicit stop conditions beneath it:

• A success stop ("packet written with at least three sourced items, saved to packets/YYYY-MM-DD.md").
• A blocked stop ("same tool fails twice, or a required source is unreachable — stop and log the missing item").
• A budget stop ("max eight steps or five tool calls — stop and request review, even if incomplete").

Finish line: a one-page loop diagram plus three written stops you could hand to another person to operate.

Verify: run a mental dry-run. Feed your loop one failing tool and one missing source. If the diagram does not tell you exactly where it stops and what it writes down, the stops are not explicit enough.

Common failure mode: stops like "stop when done." Done how? Name the file, the field, the count. Vague stops never trigger.

Check your understanding

1. Recite the five loop stages in order. Which stage writes to durable state, and why does that matter? 2. In the research loop above, what exactly happens at the "assess completeness" step? 3. Give one example each of repeat-fail, cost overrun, source drift, and false progress. 4. Why is "stop" a decision the loop makes, rather than something that just happens? 5. Look at your own five-step loop: where could false progress hide, and what log would expose it?