AI Agents — the loop, demystified

Everything converges here, and the demystification is total:

An agent is a while-loop around tool calling. Model thinks, picks an action, your code executes it, the result joins the context, repeat — until the model decides the goal is met or a guard says stop.

And in code — the twenty lines I promised, which are also, structurally, the core of Claude Code, Deep Research, and every agent product you've used:

def agent(goal, tools, max_steps=15, budget_tokens=200_000):
    history = [{"role": "user", "content": goal}]
    for step in range(max_steps):                          # guard 1
        resp = client.messages.create(model=..., tools=tools,
                                      messages=history, system=SYSTEM)
        history.append(assistant_turn(resp))
        if resp.stop_reason != "tool_use":                 # model says: done
            return resp.text                               # final answer
        for call in tool_calls(resp):                      # act (maybe parallel)
            if call.name in CONSEQUENTIAL:                 # guard 2
                confirm_with_human(call)
            result = execute(call)                         # your hands
            history.append(tool_result_turn(call.id, result))   # observe
        if tokens_used(history) > budget_tokens:           # guard 3
            history = compact(history)                     # see below
    return "stopped: step budget exhausted"                # guard 1 fires

That's the whole species. The lineage name you'll see cited is ReAct ("reason + act") — the 2022 formalization of interleaving thinking and tool use — but the loop predates and outlives any acronym. What makes the difference between a demo and a product is not the loop; it's four disciplines, each of which this course has already armed you for:

1. The compounding constraint is the design center. Topic 38's math returns as the module's gravitational force: 0.95¹⁰ ≈ 60%. Ten steps of 95%-reliable behavior yields a coin flip. Agents don't fail exotically — they fail by ordinary error accumulation. Every mitigation follows from taking the exponent seriously: raise the base (better tools, teaching error messages from Topic 57 so steps self-correct, tighter tool scopes), lower the exponent (smaller task scopes, decomposition — next lesson's workflows), insert verification steps (have the agent check its work — run the tests, re-read the output against the goal), and add recovery points (human gates at consequential moments; checkpoints so a step-9 failure doesn't vaporize steps 1–8).

2. Context engineering — Module 6, cashed per-step. Topic 53's closing truth ("all memory is prompt assembly") is now a per-iteration job: each loop turn, the model sees system prompt + goal + accumulated history — and long trajectories bloat, cost (Topic 5: whole whiteboard, every step), and degrade attention. Production agents compact: summarize old steps into a running digest (rolling summarization), keep recent turns verbatim (working memory), stash large artifacts outside context and retrieve on demand (episodic — often literally "write findings to a file, read back what's needed," the MemGPT paging pattern with a filesystem as disk). An agent's quality over long tasks is mostly the quality of its context curation.

3. Verification asymmetry decides where agents work. Agents shine where results are checkable: code runs or doesn't, tests pass or don't, the JSON validates or doesn't. Cheap verification converts "95% per step" into "95% per attempt, retried until verified" — a categorically better reliability regime. This is why coding agents got good first (the compiler is a free verifier), why Topic 27's RLVR trains reasoning on math and code, and why, when you design agent tasks, the highest-leverage question is: what can be verified here, and how do I make the agent verify it? Open-ended tasks with no check ("write a great strategy") stay hard for exactly this reason.

4. Reach for an agent last, not first. The loop's power is that the model chooses the control flow — which is also its cost: nondeterminism, compounding, unpredictable latency and spend. The field's hard-won guidance (Anthropic's "Building Effective Agents" essay is the canonical statement): use the simplest structure that works. A single prompt, then a fixed chain of prompts, then a workflow where your code decides the steps — and the full autonomous loop only when the task genuinely can't be pre-decomposed because the path depends on what's discovered along the way. That workflow-vs-agent spectrum is precisely where the next lesson begins.

Summary

Agent = while-loop of think → act → observe with guards. Products differ from demos via: fighting the compounding exponent, per-step context curation, building around verifiable outcomes, and choosing the least autonomy that solves the task.

Mental model

A capable junior colleague on a long assignment: works in cycles, keeps notes because their desk (context) is small, checks their own work when checking is possible, asks before doing anything irreversible — and whose ten-step projects succeed only if each step is very reliable, because errors compound silently.

Mistakes to avoid

Shipping the loop without guards. An unguarded agent that gets confused will happily burn 400 steps and your API budget re-reading the same file. Max-steps, max-cost, and gates are not polish — they're the difference between a tool and an incident.
Blaming "the model isn't smart enough" when an agent fails at step 8. Autopsy the trajectory first: nine times out of ten the failure is a vague tool description, a bloated context, an uninformative error return, or a missing verification — all fixable without touching the model.

Exercise · the lesson's capstone

Upgrade your Topic 56 build into a real agent: give it three tools — search_docs over your Module 6 pgvector index (agentic RAG, live), a calculator, and read_file — wrap the twenty-line loop with max_steps=10, and set it a goal requiring 3+ steps ("find what our docs say about X, compute Y from it, and summarize both"). Then run it five times and read all five trajectories. Count: how many steps did each take? Did any loop redundantly? Did errors self-correct? You've just done agent-trajectory analysis — the actual daily work of agent engineering, and the skill Lesson 12 builds on.

Lesson 11 complete. The control surface is fully in your hands: prompts as distribution-shaping, system prompts as tested constitutions, function calling as a four-beat text protocol, tool craft with its security teeth, and the agent revealed as a guarded while-loop whose real challenges — compounding, context, verification — are ones you've been training for since Topic 5.

Lesson 12 finishes Module 7: agentic workflows (the pattern library between "one prompt" and "full agent" — chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer), multi-agent systems (when many loops beat one, and the coordination tax nobody mentions), and browser agents (the hardest tool environment there is — where every lesson from this module gets stress-tested at once).