What Makes an AI Agent?

A language model, considered strictly on its own, does one thing: it turns text into text. It does not plan, act in the world, or use anything unless something is built around it that lets it.

That something is what an AI agent is. Not another model, but a system that uses a model inside a larger structure: one that breaks a task down, fetches what it needs, calls the tools it is permitted to call, and works through steps towards a goal while keeping track of where it has got to.

The formulation worth memorising, because the rest of this book leans on it:

A language model produces an answer. An AI agent uses a model inside a wider system that can plan, use tools, consult data, hold context, and take steps towards a goal.

Diagram of an agent inside its environment, with reasoning, planning, memory and tools — Figure 8: An agent and the world it acts on

What defines an agent

It adapts to the situation

An agent adjusts to the circumstances, the person and what it learns as it goes. Rather than treating each exchange as separate, it tracks the interaction and refines its approach.

Holding context across the steps of a task.
Noticing when inputs or conditions change, and responding.
Improving from feedback, where the surrounding system is built to capture and use it.

A support agent notices that a customer has raised the same billing problem three times, and passes it to a person instead of answering again.

It plans and decides

Rather than needing an instruction for every step, an agent works out the sequence itself: it examines the problem, breaks it into parts, and carries them out.

Goal directed: it works towards an outcome, not just a reply.
Multi-step: it orders the work before starting.
Selective: it weighs options against whatever criteria it was given.

A legal assistant does not only summarise a contract. It flags the clauses that carry risk, proposes alternative wording, and prepares a revision for a lawyer to review.

Worth Remembering You will see the word autonomous attached to these systems. Autonomy here is relative, not absolute. An agent works inside boundaries its designer drew: a specific set of tools it may call, permissions that constrain what those tools can change, and usually a checkpoint before anything consequential. Very few useful agents decide everything themselves, and the ones that appear to are usually operating somewhere that mistakes are cheap. Good design states plainly what the agent may do alone and what must come back to a person.

It acts on the world

An agent connects to outside systems, fetches live data and performs actions. That is what takes it beyond conversation.

Search and data: retrieving current information.
Software services: calendars, mail, databases, internal systems.
Devices: some agents drive equipment or robotics.

A home agent does not tell you it has started raining. It closes the windows, adjusts the thermostat and moves your gardening plans.

Chat window or agent

This distinction is usually explained badly, so it is worth doing carefully.

Start with what is not true. It is often said that chatbots cannot remember, cannot use tools and cannot act. That was a fair description some years ago. It is not a fair description of ChatGPT or Claude today, both of which search, retain memory across sessions and call tools. Stating it flatly would make this book wrong about the products you use daily.

The real distinction is not about capability. It is about what the two words describe.

A chat interface describes a way of interacting. You type, it replies, in turns. It is a surface.
An agent describes a system designed to pursue a goal: it holds state, chooses actions, calls tools and executes steps until the task is done. It is an architecture.

So you may well talk to an agent through a chat window, and a chat window may sit in front of nothing more than a single question and a single answer. The question is never what the interface looks like. It is whether there is a goal being pursued, state being kept, decisions being made and actions being taken.

The same request, two systems

A “What is the weather in New York today?” → “It is 24 degrees and sunny.” One turn, one answer.

B “Book me a flight to New York.” → the system searches flights, compares price and timing against your stated preferences, prepares the booking, shows you what it has chosen, and completes it once you confirm.

In B the system pursued a goal across several steps, used outside tools, and stopped to check with you before spending money. That is agentic behaviour, whatever the interface looked like.

Table 5-1: Answering a question, compared with pursuing a goal

	A single question and answer	An agentic system
What it is doing	Producing a response	Working towards an outcome
Task state	Not needed	Fundamental
Steps	One	As many as the goal requires
Tools	Not needed	Essential
What the term names	An interaction	An architecture

Read the table as describing two modes, not two products. The same interface can do either, and often does both within one conversation.

The four parts

An agent can plan, act and follow through because it is built from four things: memory, reasoning, tools and an execution system.

Memory

Memory gives an agent a sense of where it is. Without it, the agent restarts from nothing after every step and cannot track progress.

Working context: the details of the task in hand.
Longer-term knowledge: preferences and history across sessions.

Our travel assistant knows you prefer morning flights and a window seat, and stops offering you the red-eye.

Worth Remembering In most systems, long-term memory does not come from the language model. It comes from components around it: a database, a vector store, a memory service the agent reads from and writes to. The model does not remember you; the system stored something and supplied it again inside the context. That distinction matters for privacy, because it means memory is a thing somebody chose to keep, in a place you can point at.

Reasoning and planning

The language model can be thought of, by analogy, as the reasoning engine: the part that interprets the request and works out the next step. It analyses, compares options, forms a plan and selects an action.

Step-by-step reasoning before committing.
Reason-and-act loops, where the agent thinks, calls a tool, reads the result and thinks again. This loop is the heart of most working agents.
Multi-step planning, ordering the work before beginning.

Tools

An agent reaches the world through tools. One term worth defining precisely, because it recurs: an API, or application programming interface, is a structured way for one piece of software to ask another to do something. When we say an agent “calls the calendar API”, we mean it sends a structured request — create this event — and receives a structured answer telling it what happened.

Interfaces like that are what turn a system that talks into a system that does.

Search and databases, for current information.
Business systems, for scheduling, messaging and transactions.
Devices, for physical environments.

Execution

The execution system is what turns decisions into actions. It sequences the work, calls the tools, handles what comes back, and copes when something fails.

Sequencing the steps in order.
Acting: issuing requests, triggering functions, completing transactions.
Adapting: adjusting when input changes, and recovering when a tool errors rather than stopping dead.

A logistics agent does not propose a better route. It dispatches the driver, updates the estimates and notifies the customer.

Worth noticing: only one of these four is the model. The other three are ordinary software that somebody wrote. An agent is not a cleverer model. It is a model with scaffolding.

Key takeaways

An agent is not a model. It is a system that uses a model to pursue a goal.
Its defining traits: adapting to the situation, planning and deciding, acting on outside systems.
“Chat interface” names a surface; “agent” names an architecture. Modern chat products can be agentic.
The four parts are memory, reasoning, tools and execution — and three of them are ordinary software.
Long-term memory is built by the developer, not supplied by the model.
Autonomy is bounded by design. Say where the boundary is.

Knowing the parts is not the same as knowing how they move. What actually happens between a request arriving and something being done about it — and where, in that sequence, does a person get a say?