What is an agent?

An agent is a language model running in a loop: it is given a goal, it chooses an action, it sees the result of that action, and then it decides again, until it judges the goal met or a stopping rule fires. The model on its own is not the agent. The agent is the loop, plus the tools the model is allowed to call, plus the code that decides when to stop.

Written by Derek Wonk · last updated August 2026

What is an agent and how does it work?

Strip the word of its marketing and an agent is a control loop. Your program sends the model a goal and a list of tools it may use. The model replies with either an answer or a request to call one of those tools. Your program runs the tool, appends the result to the conversation, and sends the whole thing back. That round trip repeats until the model stops asking for tools, a budget runs out, or a guard rejects what it wants to do.

The important consequence is that nothing in that loop is autonomous in the way the word suggests. The model cannot reach anything you did not hand it, cannot remember anything you did not resend, and cannot continue after your code stops calling it. Every capability an agent appears to have is a capability your program granted it, one tool definition at a time.

Anthropic's own engineering guidance draws the line in terms of who controls the path: in a workflow, the sequence of steps is decided in advance by your code, while in an agent the model decides at each step which step comes next. That is the whole distinction, and it is the reason agents are harder to test than workflows: the execution path is data, not code.

Agent vs workflow vs chatbot: what is the difference?

A chatbot is a single turn, repeated: one request in, one answer out, with a person deciding what happens next. A workflow is your code driving the model through a fixed path, calling it once per step, where the branching lives in your if statements. An agent moves that branching into the model.

The trade is predictability for reach. A workflow you can unit test, cost out in advance and reason about on a whiteboard. An agent can handle inputs you did not enumerate, and in exchange every run costs a different amount, takes a different number of steps and can fail in a way you have not seen before. Most production systems that call themselves agents are actually workflows with one agentic step in the middle, and that is usually the right design.

What makes agents hard in production?

Four things, in roughly this order of pain. Cost compounds, because every iteration resends the whole conversation, so the tenth step of a run is far more expensive than the first. Errors compound, because a wrong action becomes an input to the next decision, and the model will reason confidently from it. Side effects are real, because unlike a chat reply, a tool call can write to a database or push a commit. And observability is not optional: when a run goes wrong you need the full trace of what was sent and returned, or you are guessing.

These are operational problems rather than modelling problems, which is why agent infrastructure keeps converging on things continuous delivery already has: isolated environments per run, scoped credentials, a hard budget, and logs you can read afterwards.

A four-step agent run, as the loop actually sees it

goal    : "find why the build broke and open an issue"
step 1  -> model: call read_file("ci.log")            <- decided by the model
          your code runs it, appends 4 KB of log text
step 2  -> model: call search_repo("OOMKilled")
          your code runs it, appends 3 matches
step 3  -> model: call create_issue(title=..., body=...)
          your code runs it, appends the issue URL
step 4  -> model: final answer, no tool call  -> loop exits

request size at step 1: ~1 K tokens
request size at step 4: ~9 K tokens   (everything above is resent)

Each step resends every earlier message and result, because the model keeps nothing between calls. That growth is the single biggest cost driver in an agent.

Common questions

AI agents: frequently asked

Is an agent just a for loop around a model?

Structurally, yes, and saying so out loud helps. The loop sends a request, inspects the reply for a tool call, executes it, appends the result and repeats. What separates a usable agent from a toy is everything around that loop: which tools exist, how their errors are reported back, what the step and token budgets are, and what the stopping condition is. None of that is provided by the model.

Do I need a framework to build an agent?

No. The loop is short enough to write by hand, and doing it once is the fastest way to understand where your tokens go. Frameworks earn their place when you need many tools, retries, streaming, tracing and evaluation, not because the loop itself is hard. Starting with a hand-written loop also means the framework you eventually pick is a decision rather than a default.

How many steps should an agent be allowed to take?

Fewer than you think, and always a hard number rather than a hope. Because each step resends the whole conversation, cost grows faster than step count, and a model that has already gone wrong rarely recovers by iterating more. A step cap plus a token cap turns a runaway run into a failed run, which is the outcome you want.

Sources

Where these facts come from

Anthropic: Building effective agents: the workflow versus agent distinction and when each is appropriate
Anthropic docs: tool use overview: the request and reply shape that makes the loop possible
ReAct: Synergizing Reasoning and Acting in Language Models: the 2022 paper that established the interleaved reason and act loop