Building AI agentsMiddleLesson 2045 min read

When not to build an agent

Agents are powerful but slow, costly and less predictable. Often a single prompt or a fixed workflow does the job better. Here is how to choose.

✦ Ask the tutor 🧪 Lab · 20 min 📝 Lesson test

Speed

Lesson in motion

In 60 seconds

When not to build an agent

Agents are powerful but slow, costly and less predictable. Often a single prompt or a fixed workflow does the job better. Here is how to choose.

1/5

In simple words

You don't need to hire a driver to cross the road. You don't need a bicycle to walk to the next room. Picking the smallest tool that does the job well is a sign of skill, not laziness.

It is tempting to make everything an agent. But each extra model call adds cost, delay and a chance of error. Many problems are better solved with something simpler. Think of a ladder, and climb only as high as you need.

The ladder of options

Option	What it is	Best when
Normal code	No model at all.	The rules are clear: calculating GST, sorting by date, checking a format.
Single prompt	One model call, maybe with examples.	Summarise, classify, translate, extract fields from one document.
Fixed workflow	Several model calls in an order your code decides: step A, then B, then C.	The steps are known in advance, like: extract, then check, then draft a reply.
Single agent	The model decides which tools to call and when to stop.	The steps depend on what it finds, and you cannot list them in advance.
Multiple agents	Several agents, coordinated.	Large tasks that split into independent parts.

Workflow or agent?

A fixed workflow

Your code decides the order of steps
Predictable cost and time
Easy to test each step
Fails in known places

An agent

The model decides the next step
Cost and time vary from run to run
Harder to test: many possible paths
Can handle surprises a workflow cannot

Example: a company receives invoices by email and needs the amount, date and vendor in a spreadsheet. The steps are always the same: read the PDF, extract fields, validate them, save them. That is a workflow, and possibly just a single prompt with validation (lesson 3). An agent here would add cost and new ways to fail, with no benefit.

Now compare: "Find out why this customer's payment failed and fix it if it's our side." The steps depend on what you find in the logs. That may justify an agent, with careful limits.

Cost and reliability add up

Agents chain many steps. If each step has some chance of going wrong, the chance that at least one step fails grows with the number of steps. That is simple arithmetic, not a fact about one model. Short, fixed paths are easier to make reliable. Every model call also costs money and time, so a 20-step agent can cost many times more than a single prompt for the same result.

Decision checklist

Can normal code do it with clear rules? Then do that.
Can one well-written prompt do it, with validation? Try that first and measure.
Are the steps known in advance? Build a fixed workflow.
Do the steps really depend on what is found along the way? Then consider an agent.
Can you limit its tools, budget and risk, and test it with real scenarios? If not, don't ship it yet.
Is a mistake cheap and easy to undo? If not, keep a person in the loop, or choose a simpler design.

Note

You can mix levels. A workflow can include one agent step for the part that needs judgement. An agent can call a fixed workflow as a single tool. Choose per step, not per project.

Do this

Starting simple is not a dead end. If the single prompt fails on real cases, you now have a test set and a baseline to prove the agent is better.

Try this. Name three AI ideas from your work or college. For each, choose a rung on the ladder and write one sentence explaining why not a lower one.

Watch and read more

Lab

A decision table placing five real tasks on the ladder, with reasons and a test plan.

~20 min

The problem

Use the decision checklist on five tasks. Use these or your own:

Reply to customer WhatsApp messages about shop timings.
Sort 500 scanned forms into 6 categories.
Find and fix a failing test in a code repository.
Draft weekly social media posts from a product list.
Book the cheapest train ticket that fits a family's plans.

For each, fill in: the rung you choose (code, prompt, workflow, agent, multi-agent), why not the rung below, the biggest risk, and one metric you would measure.

You are done when

Each choice is justified against the simpler option below it
At least two tasks end up on a rung lower than "agent"
Risks are specific to the task, not generic
Each task has a measurable success metric

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1The train booking task seems to need an agent. Which parts could still be fixed workflow steps or normal code?Reveal

Normal code can filter trains by date, time and budget once the data is fetched, and can compare prices exactly. Fetching train data can be a fixed tool call to an allowed source. Only the fuzzy parts, like understanding the family's preferences from a message, need the model. Payment should stay with the person. The "agent" part may shrink to understanding the request and suggesting options.

Q2An agent prototype impresses everyone in a demo. Why might it still be the wrong choice for production?Reveal

A demo shows one good run on a chosen example. Production needs good results across many real cases, at a cost and speed people accept, with safe failures. Without an evaluation set and cost measurements, you don't know the success rate or the cost per task. A simpler design may do almost as well for a fraction of the cost and risk.

Please sign in to continue.

Questions people ask

Isn't an agent always more flexible and therefore better?

More flexible, yes. Better, not always. Flexibility costs money, speed and predictability. If your task doesn't need that flexibility, you pay for nothing and gain new failure modes.

How do I show my manager that a simpler solution is enough?

Build a small test set of real examples and measure. Compare the simple approach and the agent on success rate, cost per task and time per task. Numbers from your own data are more convincing than opinions.

What if the task changes later?

Then revisit the choice. A good design keeps the pieces, such as validated extraction and tools, reusable, so moving from a workflow to an agent later is not a rewrite.

Are there tasks where agents are clearly a good fit?

Tasks where the path depends on what is discovered: debugging, open-ended research, some coding tasks, and investigations across several systems. Even then, the agent should have limits, good tools and evaluation.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.