02 Agent 15 min of exploration Accessible

When does an LLM become an Agent?

The question

What is the difference between asking a model a question and giving a machine a goal?

02 / 05Agent

A helpful answer where nothing happens

The previous chapter ended on one line: a model generates, it does not act. Here is what that means in practice.

Connect a tool

Request

Book a meeting with Sarah tomorrow afternoon.

Model

Sure. You could propose a slot around 2 pm, then send Sarah an invitation… There is a free slot tomorrow at 2:30 pm. Creating the invitation.

Calendar tool

World

Nothing has changed. Meeting created · tomorrow 2:30 pm · Sarah invited

Generation became action.

Flip the switch: same request, same model, one more link in the chain.

Text version

With no tool connected, the model answers “Sure, you could propose a slot around 2 pm…” and nothing changes in the world. Once the calendar tool is connected, the same request produces a call that actually creates the meeting. The difference is not in the model: it is in what was put around it.

The first answer is helpful. It is also completely inert: no calendar moved. The second changed something outside the conversation, and that is a difference in kind, not in quality.

Assembling an agent

An agent is not a cleverer model. It is a model placed inside an execution system. Add the parts one at a time and watch for the point where the word changes.

Assembly

Add parts

Model

Model Model + tools Agent

Tick the parts. The verdict below is derived from the assembly — you cannot tick “agent”.

Text version

A model on its own stays a model. With tools it can reach outside itself, but it still waits to be prompted at every step. The loop is what tips it over: from there, the system pursues a goal without being asked between steps.

Two thresholds, not one. Tools give reach: the system can affect something other than its own output. The loop gives persistence: it continues without being restarted. The second is what earns the word “agent”, and it is also the one crossed most casually.

The loop

Observe, decide, act, observe the result — then start again. Follow a real goal step by step.

Execution loop

Goal Find the cheapest train to Paris on Thursday and prepare the booking.

  1. Observe
  2. Decide
  3. Act
  4. Result
  1. Observe The goal names Thursday, but no time and no departure station. context: work calendar, usual departure Nice
  2. Decide Search the timetable first, before asking a question that may already have an answer.
  3. Act Call the timetable search tool. search_trains(from="Nice", to="Paris", date="Thursday")
  4. Result Eleven journeys, from €39 to €154. The cheapest leaves at 5:42 am. 11 results · min €39 · max €154
  5. Observe The cheapest requires leaving before 6 am. The calendar shows a meeting the previous evening.
  6. Decide The “cheapest” criterion conflicts with a constraint nobody stated.
  7. Act Prepare both options rather than decide alone, and ask for confirmation. prepare_booking(...) — not confirmed
  8. Result Two bookings ready, none confirmed. The decision goes back to a human.

Step through it. On the left, the current phase; on the right, what the system actually did.

Text version

The system observes that the goal is under-specified, decides to search before asking, calls the timetable tool, gets eleven journeys, notices that the cheapest option conflicts with a meeting the previous evening, and prepares two bookings without confirming either.

Notice where the system stopped. It did not run out of capability: it ran out of authority. Confirming a purchase was not among the things it had been allowed to do, and that is a property of the execution system, not of the model.

A fixed path and a chosen one

Workflow and agent are often set against each other as two species. It is more useful to read them as two ends of one axis.

Workflow and agent

Workflow

  1. Receive
  2. Extract
  3. Verify
  4. Classify

The sequence is written in advance. It is predictable, testable, and it fails in known ways.

Agent

Decide
  • Search
  • Call a tool
  • Ask
  • Conclude

The sequence is chosen at run time, from what has been observed. More adaptable, less predictable.

All decided up front All decided in flight

Most useful systems sit between the two: a fixed skeleton, with points where the decision is delegated.

On the left, the sequence is written in advance. On the right, it is decided at run time.

Text version

A workflow chains steps written in advance: receive, extract, verify, classify. An agent passes through a decision point from which several continuations are possible: search, call a tool, ask, conclude. Between the two lies a continuum, and most useful systems are somewhere along it.

The autonomy dial

Here is the question that actually matters, and it is not about the model.

Autonomy dial

Assistant Autonomous agent
  1. Suggests
  2. Prepares
  3. Acts on approval
  4. Acts within bounds
  5. Pursues a goal

The system executes, but every action that touches the world goes through an explicit approval.

What the architecture must then provide

  • An identity: who requests, who approves
  • A record of the human decision, not only of the outcome
  • A definition of what requires approval in the first place

Move the dial. What changes on the right is not what the system can do — it is what the architecture has to provide.

Text version

Five levels, from a system that suggests to one that pursues a goal over a long horizon. At each notch it is not the model’s competence that grows: it is the demands on what surrounds it — identity, recorded decisions, declared limits, interruption, a policy that outlives the prompt.

This is the most important moment of the journey, and it fits in one sentence: moving this dial does not change the model, it changes what the surrounding system has to guarantee.

When plausible inference is enough to do damage

An ordinary task, phrased the way you would phrase it to a colleague.

A plausible chain

Goal Free up some space: delete the old temporary files.

  1. Observe
  2. Decide
  3. Act
  4. Result
  1. Observe The disk is 94% full. Several directories hold old files.
  2. Decide “Old temporary files” is undefined. Adopt: not modified for 90 days.
  3. Act Walk the known temporary locations. list_files("/tmp", "/var/tmp", older_than=90d)
  4. Result 2,314 files, 12 GB. Frees space, but not enough to drop below 80%.
  5. Observe A directory named exports_temp_2024 holds 47 GB, untouched for eleven months.
  6. Decide The name contains “temp” and the age matches the criterion: this directory is probably temporary. The system made no reasoning error. It filled a gap in the request, and nothing in how it works distinguishes filling a gap from knowing.

Every step defends itself. That is exactly why the scenario is worth reading to the end.

Text version

The system observes a full disk, adopts a reasonable definition of “old”, cleans the known temporary locations, finds that insufficient, then reaches a directory named exports_temp_2024 holding 47 GB and concludes it is “probably temporary”. The reasoning is plausible at every step. The word “probably” is the only signal, and it appears nowhere in the tool call that would follow.

How much autonomy would you give this system? The question is not rhetorical: depending on the answer, the same chain of reasoning ends in a request for confirmation or in a delete call.

What can go wrong

What the loop adds — and what it costs

Errors compound. In a conversation, a wrong answer is a wrong answer. In a loop, it becomes the observation the next decision rests on. A shaky inference at step 3 is an established fact by step 7.

Intent is never fully in the request. A useful goal is always under-specified — that is what makes it worth stating. The system will fill the gaps, because it cannot do otherwise, and nothing in how it works separates an assumption from knowledge.

Plausibility is not a guarantee. A chain whose every step defends itself can still arrive at an action no informed person would have authorised. That is the failure mode specific to agents, and it is not fixed by improving the model.

Instructions are not barriers. Writing “never delete anything without asking” in a prompt states a wish in the same channel as the data the system processes. What holds is what is enforced outside the text the model reads.

An agent can act.

It has tools, state, a loop. It pursues a goal, chooses its steps, and changes things outside the conversation.

But go back to the first example. It could create the meeting because the calendar was connected. Now ask it whether your travel policy allows that journey, and it has nothing to consult: it knows neither your procedures, nor your contracts, nor what your organisation decided last month.

It knows how to act. It knows nothing about you.

An agent

  • Tools
  • Loop
  • Policies

Documents

Retrieval

An informed agent

  • Tools
  • Loop
  • Policies
  • Documents
  • Retrieval

It knows how to act, and nothing about you. Ask it for your travel policy: it has nothing to consult.

You are here

  1. 01 Model
  2. 02 Agent
  3. 03 Knowledge
  4. 04 Action
  5. 05 Control

An agent can act. But what does it know about your organisation?