Lesson 1.1: Chatbots, workflows and agents
Learn what separates a chatbot, a fixed workflow and an agent, how each handles the same request, and what the extra freedom of an agent costs.
By the end of this lesson you will be able to say, in plain words, what an agent is and how it differs from a chatbot and from a fixed workflow, sort real systems into those three groups, and predict what each design costs in model calls. You will follow one customer request through all three designs, count the model calls each makes, and see that the agent averages 5.85 calls per request where the chatbot makes 1 and the workflow makes 3. You will also build a small estimator for the daily volume of model work a design creates. No programming background is needed for the main text, though one short code example is included for readers who want to see the idea in running form. This is the first lesson of the course, so there is nothing to have read first. The mathematics is multiplication and an average.
"Agent" is one of the most used and least defined words in technology. Vendors apply it to anything from an autocomplete box to a system that runs for hours without help. This makes it hard to learn the subject, because every article seems to mean something different. This lesson fixes the vocabulary. Everything else in the course, tools, memory, sub-agents, safety and operations, builds on the three-way distinction you will learn here.
Three kinds of system
Start with one concrete job. A customer of a lending company writes: "I was charged a late fee on 3 October but I paid on 1 October. Please reverse it." A company wants software that handles messages like this. There are three broad ways to build it.
The chatbot: one question, one answer
A chatbot takes a message, passes it to a language model together with some instructions, and returns the model's reply. That is the whole system. If the model has been told the company's policies, it can write a sensible, polite answer: "I'm sorry about the fee. Late fees can be reversed if the payment reached us before the due date. Please share your loan number." But the chatbot cannot look up the loan, cannot check the payment date and cannot reverse anything. It talks. Whatever it says about the customer's account is a guess or a request for more information. A chatbot makes one model call per message and does nothing in the world.
Chatbots are useful for answering questions from a fixed body of knowledge, drafting text and explaining things. Their limit is that the model only has what is in the conversation.
The workflow: a fixed route through several steps
A workflow is a set of steps wired together in advance by a developer. A model is called at some steps, and ordinary code does the rest. For the fee complaint, a workflow might be:
1. Call the model to classify the message: fee dispute, payment query, address change or other.
2. If it is a fee dispute, call the model to extract the loan number, the fee date and the payment date from the message.
3. Run code that looks up the loan, finds the payment record and compares dates.
4. Call the model to write a reply based on the result.
The route is chosen by the developer. Every fee dispute follows the same four steps, in the same order, whatever the details. Here the workflow makes three model calls, and the lookup between them is a normal database query. The advantages are large. It is predictable: you can test every step, and you know its cost before it runs. It is also safe, because the model never decides what to do next. The disadvantage is rigidity. If a customer writes about a fee and a wrong address in the same message, or the payment record is missing and someone needs to look somewhere else, the fixed route has no way to adapt. A developer must anticipate every case.
The agent: the model chooses the next step
An agent is a system in which the model itself decides what to do next, repeatedly, until the job is done. It is given a goal, a set of tools it may use, such as "look up a loan", "check a payment" and "reverse a fee", and instructions about how to behave. It then works in a loop: look at the situation, decide on an action, take it, look at the result and decide again. The developer does not write the route. The agent works it out.
For the fee complaint, one run might go like this. The agent reads the message and decides to look up the loan. The result shows an active loan with a due date of 2 October. The agent decides to check the payment record. It finds a payment on 1 October, so the fee was wrongly applied. The agent decides to reverse the fee, which succeeds, and then writes the reply to the customer. Another run, on a different complaint, might take a different path, ask the customer a question, or give up and hand the case to a person. The sequence of steps was not written in advance.
This is the central idea of the whole course. The difference between a workflow and an agent is who controls the flow. In a workflow, the code does. In an agent, the model does.
· Chatbot · Workflow · AgentWho decides the steps · Nobody, there is one step · The developer, in advance · The model, as it goes
Can it act in the world? · No · Yes, at fixed points · Yes, whenever it chooses a tool
Number of model calls · One · Fixed · Varies from run to run
Predictability · High · High · Lower
Handles unexpected cases · Poorly · Poorly · Better, but not perfectly
Typical failure · Confident wrong answer · Case not covered · Wrong turn, loop or wasted work
Cost of a run · Lowest · Low and known · Higher and variable
Predict first: the same request goes to all three systems, 10,000 times. Which system will average the most model calls per request, and by roughly how much more than the workflow? Decide before reading on.
The agent, and by a lot. The chatbot makes one call and the workflow three, but an agent decides its own number of steps. Suppose that, over many fee complaints, 30 per cent are solved in 3 calls, 35 per cent in 5, 25 per cent in 8 and 10 per cent in 12 because the agent had to ask for clarification or retry. The average is 0.30 × 3 + 0.35 × 5 + 0.25 × 8 + 0.10 × 12 = 0.9 + 1.75 + 2.0 + 1.2 = 5.85 calls, nearly twice the workflow. The spread matters as much as the average: some runs take four times as many calls as others, so the bill and the response time are far less predictable.
A spectrum, not three boxes
Real systems rarely sit cleanly in one group. It helps to think of a spectrum of autonomy. At one end, code controls everything and a model is a helper inside one step. At the other, the model controls the flow and code only provides tools and limits. Most useful systems sit in the middle. A workflow with one step where the model chooses between three paths is partly an agent. An agent that must follow a mandatory first step, such as checking the customer's identity, is partly a workflow. Mixed designs are common and often best, and Lesson 1.3 returns to the question of how much freedom to give.
Several words appear around this topic, and it helps to know them.
LLM application: any software that calls a language model. A chatbot, a workflow and an agent are all LLM applications.
Tool (sometimes called a function or an action): something the model can ask the software to do, such as running a search or sending an email. The model does not run the tool itself. It asks, and the surrounding code runs it and returns the result.
Agentic: an adjective for any system with some agent-like behaviour. "More agentic" means more of the control sits with the model.
Sub-agent: an agent that another agent starts and directs to do part of a task. Module 5 covers these in depth.
Orchestrator: the agent or program that coordinates others.
A useful test for whether you are looking at an agent is to ask: if I ran this twice on the same input, could it take a different sequence of actions, chosen by the model, and still be allowed? If yes, it has agent-like freedom. If the sequence is fixed by code, it is a workflow.
What an agent adds, and what it costs
An agent earns its place when the path to the answer is not known in advance. Consider where each design fits.
Situation · Best fit · WhyAnswer questions from a handbook · Chatbot, perhaps with retrieval · One step, no actions
Process each invoice the same way · Workflow · The steps never change, so fix them
Investigate why a payment failed, where the cause could be in any of six systems · Agent · The next step depends on what the last one found
Draft a reply, then have a person approve it · Workflow · The approval point should be fixed
Research a topic across many sources and write up findings · Agent, or a team of them · The number of searches and the order are unknown
Convert a document to a fixed format · Workflow or plain code · Nothing needs deciding
The cost side has four parts, and a beginner often sees only the first.
1. Model calls. Each step is a call, so more freedom means more calls, as the chart showed.
2. Time. Calls happen one after another, so a run of eight steps may take many times longer than one call.
3. Variability. You can predict the cost of a workflow. You can only estimate the cost of an agent, and some runs will be far more expensive than the average.
4. Risk. A model that chooses actions can choose wrongly. The more it can do, the more a wrong choice can cost, an issue the safety lessons in Module 7 cover.
A sensible rule is a ladder of simplicity. Use plain code if it will do. If the task needs language understanding but not decisions about flow, use one model call. If it needs several steps but the steps are known, use a workflow. Only when the steps cannot be known in advance, should you reach for an agent, and even then give it as little freedom as the task needs.
Estimating the volume of work
Because an agent's number of steps varies, it is wise to estimate the load before you build. The calculation is plain. If a company receives 2,000 fee complaints a day and an agent averages 5.85 calls each, that is 2,000 × 5.85 = 11,700 model calls a day. If each call processes about 3,000 tokens of input and output, a rough unit that Lesson 1.4 explains, the daily volume is 35.1 million tokens. The same complaints through the workflow would be 6,000 calls and 18 million tokens. Neither figure is a price, because prices change and differ by model, but the ratio is stable: roughly twice the work for the agent in this example. Knowing the ratio early prevents the unpleasant surprise of an agent whose bill is double what the team planned.
Why the idea took off, and why it needs care
Language models became useful for agents when they became reliable enough at two things: following instructions precisely, and producing structured requests such as "call the tool named lookuploan with loan number 4471". Before that, a model's free-form text could not be turned into actions dependably. Today models can plan a few steps, read the results of a tool and adjust. That makes agents practical for a range of work, from support to research to software development. Yet the limits are as important as the capabilities. Models still make mistakes, can be misled by malicious text in the data they read, and can drift off task over a long run. An agent combines a model's flexibility with the model's fallibility, which is why most of this course is about structure: tools designed well, memory managed carefully, tasks split into manageable pieces, and checks around the loop.
The most useful habit to take from this first lesson is to ask, for any proposed system, where does the control sit, and does it need to? Many problems presented as agent problems are workflow problems, and a workflow is cheaper, faster and easier to trust. Many other problems, the open-ended ones, genuinely need an agent. Telling the two apart is the first skill of the field.
A small agent, in code
For readers who want to see the idea in running form, here is the whole concept in a few lines. It uses a stand-in for the model so that it runs anywhere; Lesson 3.4 builds a real one. Read it for its structure: a loop, a decision, an action and a stop condition.
python
# A stand-in "model": looks at what has happened so far and picks the next action.
def fakemodel(goal, history):
if not any(h["tool"] == "lookuploan" for h in history):
return {"tool": "lookuploan", "args": {"loanid": "4471"}}
if not any(h["tool"] == "checkpayment" for h in history):
return {"tool": "checkpayment", "args": {"loanid": "4471"}}
pay = next(h["result"] for h in history if h["tool"] == "checkpayment")
if pay["paidon"] <= pay["dueon"]:
if not any(h["tool"] == "reversefee" for h in history):
return {"tool": "reversefee", "args": {"loanid": "4471"}}
return {"tool": "finish", "args": {"reply": "The late fee has been reversed."}}
return {"tool": "finish", "args": {"reply": "The payment arrived after the due date."}}
The tools: ordinary functions the program runs on the model's behalf.
tools = {
"lookuploan": lambda loanid: {"loanid": loanid, "status": "active"},
"checkpayment": lambda loanid: {"paidon": "2026-10-01", "dueon": "2026-10-02"},
"reversefee": lambda loanid: {"reversed": True},
}
def runagent(goal, maxsteps=8):
history = []
for step in range(maxsteps): # a hard limit, so it cannot loop forever
action = fakemodel(goal, history) # the model decides
if action["tool"] == "finish":
return action["args"]["reply"], history
runtool = tools[action["tool"]]
result = runtool(action["args"]) # the program acts
history.append({"tool": action["tool"], "result": result})
return "Handing over to a person.", history # stop condition if it takes too long
reply, trace = runagent("Reverse the wrongly charged late fee")
print(reply, len(trace), "tool calls")
Notice that the program, not the model, runs the tools and enforces the step limit. That division of labour appears in every agent you will meet.
Common mistakes
Calling every model feature an agent. If one call produces one answer, it is a chatbot, however capable.
Using an agent where a workflow would do. If the steps are known, fix them. It is cheaper, faster and easier to test.
Judging cost by a single run. An agent's cost varies; estimate the average and the worst case.
Giving the model every possible tool at once. More choices mean more wrong turns. Give only what the task needs.
No stopping rule. Every agent loop needs a maximum number of steps and a way to hand over to a person.
Treating the chatbot's words as actions. A model that says "I have reversed the fee" has not done so unless a tool did it.
Ignoring variability. Plan for the slow and costly runs, not just the typical one.
Key takeaways
A chatbot answers in one call and acts on nothing. A workflow follows steps a developer fixed in advance. An agent chooses its own next step in a loop until the job is done.
The key difference is who controls the flow: the code in a workflow, the model in an agent.
Autonomy is a spectrum. Many good systems mix fixed steps with model-chosen ones.
An agent handles open-ended jobs where the path is unknown, but costs more calls, more time, more variability and more risk. In the example the agent averaged 5.85 calls against 3 for the workflow.
Climb the ladder only as far as needed: plain code, one call, a workflow, then an agent.
The program runs the tools and enforces limits. The model only chooses.
Check yourself
1. A system takes an email, asks a model to summarise it, and returns the summary. What is it?
A chatbot-style single call, not an agent. One call, no tools, no loop.
2. A system always does: classify the ticket, look up the customer, write a reply, in that order. Is it an agent?
No, it is a workflow. The developer fixed the order. The model does not choose the steps.
3. Over many runs, an agent takes 4 calls 50 per cent of the time, 6 calls 30 per cent and 10 calls 20 per cent. What is the average?
0.5 × 4 + 0.3 × 6 + 0.2 × 10 = 2 + 1.8 + 2 = 5.8 calls.
4. Why is the cost of an agent harder to forecast than the cost of a workflow?
The agent chooses how many steps to take, so the number of calls varies from run to run, and some runs are much longer than the average.
5. Name a task where a workflow is better than an agent, and say why.
For example, processing each invoice in the same way. The steps never change, so fixing them is cheaper, faster and easier to test.
Try this
Set aside thirty minutes and a notebook or document.
1. List five AI-based features you have used or seen. For each, decide whether it is a chatbot, a workflow or an agent, and write the test you applied.
2. Pick a task in your own work with several steps. Write the steps. Mark each as "always the same" or "depends on what I find".
3. If every step is always the same, sketch the workflow and count the model calls it needs. If some depend on findings, mark where an agent would choose.
4. Estimate the volume: how many times a day would the task run? Use the estimator to find calls and tokens a day for a workflow and for an agent averaging twice as many calls.
5. List three things that could go wrong if the model chose a wrong step, and who would be harmed.
6. Write one paragraph: would you build this as a chatbot, a workflow or an agent, and why?
A good result is a short note that names the design, justifies it with the "who controls the flow" test and states the expected number of model calls. The next lesson opens the loop itself: what happens inside each step of an agent, and why small errors add up.
Tags: Agentic AI AI agents Workflows Chatbots LLM applications