Skip to content
Agents: The Core LoopWhat an agent is

Mid · Core path · 7 chapters

What an agent is

A model, tools, a loop, and a termination condition. Nothing more

A minimal definition prevents architecture cargo cult; skipping an explicit stop condition creates runaway tool calls, latency, and cost.

Read these first

What you will know

  • Write the loop from memory: model, tools, iterate, stop

    Include the tool-call and tool-result handoff, persisted iteration state, and a bounded or otherwise enforceable exit path.

  • Run a minimal implementation containing only a model, one tool, a loop, and a stop condition

    A stubbed model and tool are enough to prove that no planner, memory layer, or multi-agent machinery is required for the core behavior.

  • Identify the termination condition in someone else's agent

    Trace every exit path, including tool errors and malformed model output, because an apparently successful loop can still continue indefinitely.

  • Compare a fixed chain and an agent on the same task, and mark where the agent chooses its next step

    The meaningful boundary is runtime control flow: a chain follows predetermined edges while the model selects among possible actions.

  • Write a two-sentence definition of an agent for a non-technical colleague

    Use an ordinary workflow example so the term remains a design option rather than implying autonomy, intent, or human-like reasoning.


Chapters

  1. 1

    A model, tools, a loop, and a condition that ends it

    Four parts, and the claim that nothing else is required: a model that can request actions, a set of tools it may request, a loop that feeds every result back, and a condition that ends it. You will write this from memory. The fourth part is the one teams leave implicit, and a loop with only three parts has an exit that somebody else controls.

  2. 2

    Between iterations, only the message list survives

    Something has to be carried from one turn to the next, and it is the whole message list: the user turn, the assistant turn holding the tool calls exactly as it arrived, and one result block matching each call id. Two bugs follow from getting this wrong — appending a result without the turn that requested it, and a call id with no matching result. Both produce an invalid request from a tool that worked.

  3. 3

    A stubbed model and one tool are enough to run an agent

    Remove the planner, the memory layer, the framework and the second model. What is left — a stub that returns a canned tool call, one real tool, a while loop and a counter — still shows the behaviour people credit to agent architecture. Building it takes an afternoon and settles which parts are load-bearing before any later chapter puts a piece back.

  4. 4

    A chain's edges are fixed in code; an agent picks at runtime

    Neither the presence of a model nor any claim about autonomy draws the line. Control flow does: a chain's edges exist before anyone runs it, while an agent lets the model choose among a fixed set of actions each iteration. Apply this to a nightly job that calls the model once per ticket and writes a label, decide whether it qualifies, and say why the name in the design doc matters.

  5. 5

    An exit the model controls is not a termination condition

    "It always stops because the model eventually stops calling tools" is the most common sentence here and the least defensible. A search returning nothing forever, a model re-requesting an identical call, a malformed response the loop reads as no-tool-calls — each removes the only exit. You will enumerate every path out, then add a bound and decide exactly what the twelfth iteration returns to the caller.

  6. 6

    Tracing every exit in an agent you did not write

    You are handed an agent and asked to approve it for production, with no access to the real systems it touches. From the code and a handful of recorded trajectories you trace each path out of the loop: the clean return, the except block that logs and continues, the early return that never reaches the framework's max_iterations default. What justifies refusing to sign off is covered here too.

  7. 7

    Describing an agent without implying intent or autonomy

    The word does work in a design document that it has not earned. Here you write the two-sentence version for a colleague in finance or operations: software that repeatedly asks a model which of a fixed set of actions to run next, and then stops. Anchored to an ordinary workflow they already know, it keeps the term a design option rather than a claim about reasoning or independence.

External resources