What an Agent Is

The tool calling lesson ended on a loop. The model asks for a lookup, your code runs it, the result goes back, and the model may ask for another. Cap the rounds, it said, because nothing in the model stops it asking.

An agent is that loop taken seriously. You do not script the steps. You give the model a goal, a set of tools and a stopping condition, and it decides what to do next each time round. That is the whole definition, and it is smaller than the word suggests.

What changes is not the mechanism but who chose the order of operations. In everything so far, you did. In an agent, the model does, at runtime, differently each time. Every property in this lesson — the useful ones and the alarming ones — follows from that single shift.

MAX_STEPS = 8
MAX_TOKENS = 20_000
MAX_SECONDS = 60

def run_agent(goal: str, caller: User) -> AgentRun:
    transcript = [
        {"role": "system", "content": AGENT_SYSTEM_PROMPT},
        {"role": "user", "content": goal},
    ]
    run = AgentRun(caller=caller.id, goal=goal)
    started = time.monotonic()

    for step in range(1, MAX_STEPS + 1):
        if run.tokens_used > MAX_TOKENS:
            return run.stopped("token budget exhausted")
        if time.monotonic() - started > MAX_SECONDS:
            return run.stopped("time limit reached")

        reply = chat(model=CHAT_MODEL, temperature=0, messages=transcript, tools=TOOL_SCHEMAS)
        run.record(step=step, reply=reply)          # tokens, tool names, latency
        transcript.append(reply.message)

        if not reply.tool_calls:
            return run.finished(answer=reply.text)

        for call in reply.tool_calls:
            result = run_tool_call(call, caller)     # allow-list, schema, permissions
            transcript.append(
                {"role": "tool", "tool_call_id": call.id, "content": json.dumps(result)}
            )

    return run.stopped("step limit reached")

• The for loop with MAX_STEPS is the difference between an agent and a runaway process. A while loop waiting for the model to decide it is finished has no upper bound, and a model that keeps finding one more thing to check will keep going until something external stops it.
• Three independent limits, because they fail in different ways. Steps catch a model cycling between two tools. Tokens catch a single step that retrieves something enormous. Time catches a slow provider. Any one of them alone leaves a gap.
• The token check reads accumulated usage from previous turns, so it is measuring the whole run rather than one call. This matters because the transcript is resent every turn — eight steps is not eight times the cost of one call, it is closer to the sum of a growing prompt, and the later steps are the expensive ones.
• run_tool_call is unchanged from the tool calling lesson, deliberately. Autonomy over which tool to call does not relax any check on whether the call is permitted. If anything the checks matter more, because you are no longer able to predict the sequence.
• Every stopping path returns a run object rather than raising. "Stopped at the step limit" is an outcome your interface has to handle and show honestly — a partial result presented as a finished answer is worse than saying the assistant gave up.
• run.record on every step is what makes this debuggable at all. Without a per-step log of tool names, arguments, tokens and latency, a bad run is unreproducible, because the next run will take a different path.

That last figure is worth sitting with, because it is arithmetic rather than pessimism. Chain enough steps and per-step reliability that sounds excellent becomes an unreliable whole. It is also why longer runs are not better runs — each additional step adds cost and subtracts from the probability that the answer is sound.

The practical consequence is to keep runs short by design, verify intermediate results in code where you can, and put a human in front of anything the run is about to do rather than say.