When an agent is worth it
Lesson 1 of 6
1When an agent is worth it
The big pictureAn "agent" is a model that decides by itself which tool to call and how many times, in a loop until it is done. That freedom is expensive: more tokens, more time, and behaviour that is harder to predict and test. Most things called agents are really one call and an if, or a fixed chain of steps, and that is usually better.
What the picture shows: One call is 1.5 thousand tokens, and a twenty-five-step agent is 150 thousand. The bars do not grow in a straight line because every step carries the history of all earlier steps, and that is the price of letting the model choose the route itself.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
An agent is like an employee you give a goal who decides the steps alone. That helps when you do not know the steps in advance. But most tasks have known steps: "read the request, classify it, route it". There an ordinary program with one model call is enough, cheaper, clearer and less error-prone.
An agent is a loop where the model picks the next tool, and every step adds latency, cost and a chance of error. It suits open-ended, multi-step tasks with a checkable result. Short of that, a fixed workflow of set calls and if conditions is enough.
Before You Start
📞Calling a model
You know how to send messages to a model and read its reply, and that every call is priced in tokens.
🧱Context engineering
You know that a good template with clear instructions solves most tasks in a single call.
The Core Idea
Every system sits on one of three rungs: one call, a fixed chain, or an agent. In this lesson you see each rung and when it is enough, then you count the price of freedom.
1Rung one: a single call
Most tasks are one transformation: classify, summarise, extract or translate. A good template and one call solve them, and that is the cheapest, fastest and easiest to test.
Look at the picture: the message comes in, the model is called once, and then your code decides what to do with the result using a plain if.
The model chooses no step here. It turns text into text, and your code owns everything after that.
2Rung two: a fixed chain
When you know the steps and their order in advance, write them as code. Each step is a call or plain code, and the chain itself is code you test step by step.
A task often built as an agent: "where is my order?". Its steps are always known, so we write them as code.
import re
def extract_order_id(message):
m = re.search(r"\b(\d{5})\b", message)
return m.group(1) if m else None
ORDERS = {"48213": {"status": "shipped", "eta": "Thursday"}}
def lookup(order_id):
return ORDERS.get(order_id)
def reply(message):
order_id = extract_order_id(message) # step 1: in production, one small model call
if not order_id:
return "Please send your 5-digit order number."
order = lookup(order_id) # step 2: plain code, no model
if not order:
return f"I could not find order {order_id}."
return f"Order {order_id} is {order['status']}, arriving {order['eta']}." # step 3: a template
for msg in ["where is my order 48213?", "where is my order?", "status of 11111 please"]:
print(f"{msg!r:32} -> {reply(msg)}")
Three fixed steps: extracting the number (in production one small model call, here a regular expression), a lookup in code, then a template. Every failure case has a clear reply, and every step is tested alone. A free agent for the same task would reach the same replies with many times the tokens, and sometimes decide to apologise instead of looking.
Ask yourself: can I draw a flowchart for this task? If you can, the flowchart is the code and you do not need an agent.
3Rung three: a real agent
An agent is a model that decides by itself which tool to call and how many times. You need it only when you do not know the number or order of steps, and each step depends on the last result.
Look at the picture: the model picks a tool, reads its result, then picks again. The cycle cannot be drawn in advance, because it changes with every case.
Examples are open research, fixing code, or investigating a problem. In each one you cannot know the third step before you see the result of the second.
4The price of freedom
Freedom has a price: more tokens, longer latency, behaviour that changes between runs, and much harder testing. Tokens are the easiest part to measure, so let us count them.
system_and_tools = 1200 # tokens sent with every call
per_step = 400 # each step adds a tool call and its result to the history
def agent_tokens(steps):
total, history = 0, 0
for _ in range(steps):
total += system_and_tools + history
history += per_step
return total
one_call = system_and_tools + 300
print(f"one call: {one_call:>7,} input tokens")
for steps in [3, 10, 25]:
print(f"agent, {steps:2} steps: {agent_tokens(steps):>7,} input tokens")
One call is 1,500 tokens. A ten-step agent is 30,000, twenty times more, and a twenty-five-step one 150,000. The growth is roughly quadratic because every step resends everything before it. Caching the repeated prefix softens the price but not the latency. That is what you pay for letting the model choose the route itself.
How It Works, Step by Step: how to choose between a call, a chain and an agent
Start with one call and a good template, and add an if in code if you need a decision.
If you know the steps and their order in advance, write them as a fixed chain your code controls, and test each step alone.
Move to an agent only when the number and order of steps change with every case, and each step depends on the last result.
Before you build it, count its tokens and latency at the expected number of steps, and compare it with the rung below.
Worked example
Before you build an agent, count its cost. At every step the agent sends the system message and tool descriptions, plus everything that happened in earlier steps. So the history grows with each step, and the cost grows faster than it.
Try it without code
Myth vs Reality
| Myth | Reality |
|---|---|
| An agent is always smarter than a fixed chain. | On tasks with known steps it usually reaches the same result, sometimes wanders or skips a step, and costs far more. |
| An agent costs in proportion to its steps. | It grows faster, because every step resends everything before it: ten steps cost 30,000 tokens, not 15,000. |
| The more tools an agent has, the more capable it is. | Every extra tool enlarges the system message at every step and raises the chance of picking the wrong tool. Start with the fewest that suffice. |
Try it yourself
Which task deserves a real agent?
You do not know in advance which files to read or how many commands to run, and each step depends on what the last found. The rest are single transformations.
Why do an agent's tokens grow faster than its steps?
The tenth step carries all nine before it. The sum 1 + 2 + ... + n grows with the square of n.
Quick review cards
if in code around the result if you need a decision.Check Your Understanding
Task: "read this invoice, extract the amount and date, and add them to a spreadsheet". Agent or chain?
A chain. The steps are known and fixed: one call extracting JSON with a schema, code validating it, code adding it to the sheet. No decision needs the model's freedom. An agent here adds cost and the risk that it "decides" to edit other rows.
Task: "read the customer message; if it is a complaint open a ticket, otherwise answer from the FAQ". Which rung of the ladder fits?
One call that classifies the message, then an if in code that routes it. Both branches are known in advance, so the model does not need to decide the route.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Done with this lesson?
Sign in to save your progress.