How an AI Agent Gets Work Done

Let us follow one request all the way through, from the moment it arrives to the moment something has actually happened. The agent is the travel assistant we have been building up since Chapter 1.

Let us follow one request all the way through, from the moment it arrives to the moment something has actually happened. The agent is the travel assistant we have been building up since Chapter 1. We will call it TravelBooker.

The request: “Book me a flight to New York on Monday morning, and set up a meeting with Sarah that day.”

Diagram of the agent loop: understand, reason and gather, execute, with feedback — Figure 10: One request, from arrival to action

Three stages

Real agents run a more tangled sequence than any diagram admits, but it compresses usefully into three stages:

Understand. Work out what the person actually wants.
Reason and gather. Plan the work and collect what is needed.
Act. Check with the person where it matters, then do it.

What is actually driving the loop

It is tempting to say that prompts drive an agent, because the model is the interesting part. That is not quite right, and the imprecision causes real confusion later.

An agent is a combination of things working together:

Model reasoning, which interprets the request and decides what to do next. This is the part prompts shape.
Ordinary software, written by a developer, which does everything that does not need judgement: parsing a date, validating a response, retrying a failed call, formatting a request.
Tool calls, which reach outside systems and bring results back.
Rules, which constrain what may happen regardless of what the model concludes.
Memory, which supplies context the model would not otherwise have.
Execution logic, which sequences all of it and handles what goes wrong.

So the model is consulted repeatedly, and its answers steer the loop. But a great deal of what makes an agent reliable is deterministic code that does the same thing every time. That is a feature, not a shortcoming: the parts you can make predictable, you should.

Stage one: understanding

Goal: identify the separate tasks inside the request.

Prompt

You are TravelBooker, an assistant for travel booking and schedule management. Identify and classify the tasks in the following user request.

What comes back:

Table 6-1: Tasks identified in the request

Task	Kind
Book a flight	Travel
Schedule a meeting	Calendar

Two tasks, not one. Getting that separation right early prevents the agent from conflating them later — for instance, booking a flight that lands after the meeting it is supposed to enable.

Stage two: reasoning and gathering

Goal: turn each task into steps, then collect what those steps need.

Prompt

For the following request, break each task into a step-by-step plan before retrieving anything or taking any action.

The instruction to plan before acting is deliberate, and it is one of the most useful habits in agent design. It is far easier to inspect a plan than to unpick a sequence of actions that has already run.

Table 6-2: The plan the agent produced

Step	What it uses
Recall the traveller's preferences	Memory
Search Monday morning flights	Flight service
Compare on price, timing and seat	Its own logic
Check Sarah's availability	Calendar
Pick a slot that works after the flight lands	Its own logic
Prepare both for confirmation	—

Only once the plan is clear does the agent retrieve anything. And notice the last line: the plan ends at prepare, not at book. That is on purpose.

Stage three: checking, then acting

Here is the step most walkthroughs get wrong, including a lot of real products.

Booking a flight spends money. It is hard to undo, it appears on somebody's card, and if the agent has misread “Monday” the cost of finding out afterwards is much higher than the cost of asking first. So the agent does all the work up to the irreversible action, and then stops.

1 The agent presents what it has chosen. “Airline A, Monday 7:00 am, window seat, £214. Meeting with Sarah at 2:00 pm, which leaves three hours after landing. Book both?”

2 You approve. Or you do not — you say the 7:00 am is too early, and the agent revises without having spent anything.

3 Now the agent acts. It books the flight, sends the calendar invitation, and confirms both.

You keep nearly all of the speed. The agent did the searching, the comparing, the availability check and the scheduling arithmetic — the parts that were tedious. You gave up almost none of the control, because the one moment that mattered came back to you.

Human Checkpoint The pattern to remember: let the agent work right up to the irreversible action, then present the result and ask. Spending money, sending a message somebody will read, changing a record, making a booking, issuing a refund. Each of those is a place where the checkpoint belongs before the action, not in a review afterwards. We will meet this pattern again in Part V, where it turns out to be one of the most important ways these systems are designed.

Table 6-3: The three stages

Stage	What happened
Understand	Two tasks identified: a flight and a meeting
Reason and gather	A plan built, then live data retrieved
Act	Options presented, approval given, both completed

Keeping track

Memory divides usefully into two kinds. Think of a whiteboard and a filing cabinet.

Within the session

Short-term memory keeps the agent oriented inside the current task. It holds what has been said so the conversation does not restart at every turn.

For TravelBooker, that means holding: destination New York, Monday morning, plus any preference mentioned along the way. Without it you would be asked for the destination four times.

It lives in the model's context window, and often in a session store alongside it. It is cleared when the session ends, unless something deliberately keeps it.

Across sessions

Long-term memory is what lets an agent become genuinely useful over time. It holds what is worth keeping between conversations.

Over months, TravelBooker learns that you prefer morning meetings, always pick a window seat and mostly fly to New York or San Francisco. So “book my usual” becomes a complete instruction. Chapter 8 covers where that gets stored and what the choices cost.

Worth Remembering An agent that gets better is not a model retraining itself. The model is fixed between releases. Improvement comes from the system around it: what gets written to memory and replayed into context, what retrieval surfaces, what feedback people give, revised instructions, changed tools, and new model versions shipped by the provider. Each of those is a decision somebody made. Nothing improves on its own.

How the parts fit together

From a design point of view, the important thing is that none of this is one large program. An agent is built as separate modules, each responsible for one function, and joined by a coordinating layer that decides how the agent reasons, remembers and acts.

Every piece is replaceable: swap the model, add a tool, change where memory lives, write new instructions. That modularity is what makes agents maintainable — and it is what makes the multi-agent designs in Part V possible at all.

Table 6-4: The modules of an agent

Module	What it does
Language model	Interprets the situation and decides the next step
Instruction manager	Stores and assembles what the model is told
Tool interfaces	Connections to outside systems
Memory store	Short-term and long-term state
Coordinating layer	Sequences the work and handles failures

These are usually wired together with a framework rather than written from scratch. Chapter 8 goes through the options.

Key takeaways

Agents follow a loop: understand, reason and gather, act.
Prompts shape the model's contribution. The agent as a whole also runs on ordinary software, tool calls, rules, memory and execution logic.
Planning before acting is what makes an agent's behaviour inspectable.
Put the human checkpoint before the irreversible action, not in a review afterwards.
Short-term memory holds the task; long-term memory holds the person.
Long-term memory is engineered, not emergent.
Agents are modular, joined by a coordinating layer. That is what lets them grow.

TravelBooker works because somebody decided what it was for, what it could touch, and where it had to stop. Those decisions came before any code. So before building anything, there is a harder question to answer: does this problem want an agent at all?