Agents
An agent is not a different kind of model. It is the same model called in a loop, allowed to use tools, and given somewhere to keep what it has learned along the way.
A Model Answers. An Agent Works.
The difference is the loop around the model, not the weights inside it
One shot, then done
You send a prompt, the model produces text, the call ends. It cannot look anything up, check its work, or act on the world. Whatever it did not know at that moment, it guesses.
Decide, act, look, repeat
The same model is called repeatedly. Each turn it may ask for a tool to be run; the runtime executes it and feeds the result back. The loop ends when the model answers instead of acting.
The Agent Loop
Three moves, repeated until the goal is met or a limit is hit
Think
Given the goal and everything observed so far, the model decides what would help next.
Act
It emits a structured tool call — a name and arguments. The runtime, not the model, executes it.
Observe
The result is appended to the conversation, so the next turn sees what actually happened.
↺ The whole transcript is resent each turn — the loop is what carries state, the model itself remembers nothing
What an Agent Is Made Of
Four parts, only one of which is the model
Planning
Breaking a vague goal into ordered steps. Sometimes an explicit plan written up front, sometimes just the next action chosen fresh each turn.
Memory
Anything carried between turns: the running transcript, a scratchpad of notes, or a store searched on demand when the context window cannot hold it all.
Tools
Functions the model may request: search, a database query, a file write, an HTTP call. Each is described by a name, a purpose and a schema for its arguments.
Reflection
Checking the result before continuing: did the tool error, does the output answer the question, should the approach change? Without it, one bad step poisons everything after.
Anatomy of a Single Tool Call
What actually crosses the wire when an agent looks something up
The model only ever produces text. "Calling a tool" means producing text in an agreed shape that the runtime recognises, executes, and answers. Every safety boundary lives in that runtime.
Where an Agent Keeps Things
The model is stateless, so memory is something the loop provides
The context window
The transcript resent on every call. Simple and exact, but bounded — and every added token costs time, money and KV cache memory.
Scratchpad and plan
Notes the agent writes for itself: the plan, findings so far, what has been ruled out. Kept compact and re-injected each turn so progress survives summarisation.
Retrieved store
Documents or past sessions held outside the window in a database, searched when relevant and pulled in on demand. Unbounded in size, but only as good as the search.
Common Patterns
Different shapes of loop, suited to different work
| Pattern | How it runs | Suits |
|---|---|---|
| ReAct | Interleaves reasoning and acting: think a little, call one tool, look at the result, think again. | Open-ended tasks where the next step genuinely depends on what was just found. |
| Plan & Execute | Writes the full plan first, then works through the steps, replanning only when a step fails. | Long tasks with a predictable shape, where wandering is expensive. |
| Reflection | Produces a draft, then critiques it against the goal and revises before returning anything. | Writing, code and analysis, where a second pass reliably beats the first. |
| Router | A cheap first call classifies the request and dispatches it to the right specialised handler. | Mixed traffic where most requests are simple and a few need the expensive path. |
| Supervisor | One agent decomposes the goal and delegates pieces to sub-agents, then merges their results. | Work that splits cleanly into parts that do not need to see each other's context. |
Multi-Agent Systems
Each worker gets its own context window, its own tools and its own instructions
Supervisor
Splits the goal, routes each piece, reviews and combines what comes back
Researcher
Search and read-only tools. Gathers sources and summarises them.
Writer
No external tools. Turns the gathered material into the deliverable.
Reviewer
Checks the draft against the original goal and sends back corrections.
The gain is focus: a narrow window and a small toolset beat one agent holding everything. The cost is coordination — every handoff is a chance to lose detail, and every sub-agent multiplies the token bill.
Why Agents Are Hard
The loop that gives them power is also what makes them fail
Compounding errors
A step that is 95% reliable is only about 60% reliable ten steps in. Small mistakes early are read as fact later.
Loops that do not end
Without a step budget an agent can retry the same failing call forever, or ping-pong between two approaches. Hard limits are not optional.
Context exhaustion
Every observation is appended, so the window fills with tool output. Once truncation starts, the agent quietly forgets its own goal.
Cost and latency
One task becomes many calls, each resending a growing transcript. Token use rises faster than the number of steps.
Unsafe actions
A model that can write files or call APIs can do damage. The runtime must enforce permissions — asking the model to behave is not a control.
Untrusted input
Fetched pages and documents enter the same context as your instructions, so text inside them can attempt to redirect the agent. Treat tool output as data, never as orders.