What an agent is

Why it matters

Agent is the most overloaded word in the field: teams call a prompt with two tools an agent, and a scheduler with retries as well. The definition has now settled: a language model calling tools in a loop, observing the results, until a stop condition. Interviewers ask for it because the definition decides where the cost goes, where failures hide, what to log, and when a plain pipeline would have done.

The idea

An agent is a model, a set of tools, and a loop that runs them. The model executes nothing (the Function calling lesson covers that gap); it proposes an action, and the code around it, the runtime, carries the action out and reports back. The loop continues, and the model decides what happens next on every lap.

One lap

Every lap has the same four parts. First, the model reads the whole context so far and picks an action: a tool call with arguments, or a final answer. Second, the runtime executes it: runs the function, applies permissions and timeouts, catches errors. Third, the result enters the context as a tool-result message, so the next model call can see it. Fourth, the runtime checks the stop condition: the model said it is done, a step or token budget is spent, an error count is exceeded, or a human stepped in. If none fires, the loop goes round again.

lap 1  tool_use  search_tickets(query="login 500s")   -> 3 ticket ids
lap 2  tool_use  read_ticket(id="T-4821")             -> trace names auth-svc
lap 3  end_turn  "The 500s come from auth-svc after the 14:02 deploy."

Three laps, three model calls, two tool executions, one stop on end of turn; nothing in that trace was scripted.

Everything else decorates the loop

The patterns that fill agent frameworks answer one of four questions about the loop. Planning decides which call comes next; the Planning lesson compares the styles. Memory decides what the context holds at the start of each lap: the whole transcript, a summary, or facts fetched from a store. Guardrails decide which calls the runtime is allowed to execute, and which need a human first. Evals decide, after the fact, whether the loop reached the right place. None of them changes the loop's shape; they change what flows round it and when it is permitted to continue.

What is not an agent

A single model call with tools is not an agent, even when it returns a tool-use block: there is no second lap, so the model never observes a result. A fixed pipeline that calls the model at steps two and five of a path decided in advance is a workflow: the model fills in boxes, it does not choose the next one. Both are often the right design; the next lesson is about choosing. The word agent means the model directs the path.

The cost model

Each lap is a full model call carrying the entire context: system prompt, tool definitions, every earlier call and every earlier result. Input tokens grow with each lap, so total input cost grows roughly with the square of the lap count. A ten-lap task whose context ends at 40,000 tokens has sent something like 200,000 input tokens in total, not 40,000. Prompt caching cuts the price of the repeated prefix and the Memory and state lessons keep the context short, but laps remain the unit of cost and latency, and every design decision about agents is a decision about how many laps to allow.

Where it came from

The first agents were prompting tricks: the model wrote a thought and an action in a fixed text format, and the runtime parsed the action with a regular expression and pasted the observation back. Native tool use moved the action into a trained, schema-checked block, which removed most parse failures. Reasoning models then moved much of the thinking into hidden tokens, so a lap can hold long deliberation without any of it appearing as prompt text. The loop has not changed; what changed is how much of each lap the model does for you.

Trade-offs

Autonomy is the point and the cost. Two runs of the same task can take different routes, which makes behaviour hard to reproduce and tests hard to write. Each lap adds latency and tokens, so a task a workflow finishes in two calls can take an agent eight. A wrong observation on lap three poisons every lap after it. And the loop runs until something stops it, so the stop condition is part of the definition; an agent without one is an outage.

In an interview

Define it in one breath: "An agent is a model calling tools in a loop, observing results and choosing the next action until a stop condition; the runtime executes, the model only proposes." At junior depth, name the four parts of a lap and say what is not an agent. At mid depth, explain the cost model, that each lap resends the context, and place planning, memory and guardrails as decorations on the loop. At senior depth, argue for or against the loop for a given task and describe the stop conditions and logging you would build. Expect the follow-up: "Why not give one call all the tools?" Because without a second lap the model never sees a result, so it cannot correct, chain or stop on evidence.