From Chatbots to Agents
Learning Objectives
- You understand the main difference between a chatbot and a tool-using agent.
- You know what bounded autonomy means in practice.
- You can identify when agent-like behavior is useful and when it adds unnecessary complexity.
A chatbot answers, an agent can also act
A basic chatbot receives text and produces text. It may be useful, but its capabilities are limited to the prompt and the model’s built-in knowledge.
When you ask a chatbot “What is the current time?”, it can only guess based on patterns in its training data. It cannot access the actual current time. The same holds when you ask e.g. about a technology — the model can only provide information that was present in its training data, which may be outdated or incomplete; even if information existed in the training data, the answer might also be incorrect.
A tool-using agent-like system is different. Depending on the tools that are made available to it, it can inspect external information, trigger deterministic operations, and sometimes carry out several steps before returning a final answer. Tool use matters because many tasks depend on information or actions that the model should not invent.
Examples include:
- looking up a value from a file,
- checking the current time,
- querying a database,
- or running a local deterministic function.
This does not mean that every useful tool-using system needs full autonomy. Many practical systems only need one or two carefully limited actions.
Without tool use, the model can only guess. With tool use, the model can delegate specific subproblems to software components that are better suited for them.
A spectrum, not a binary line
It is useful to think about agent-like behavior as a spectrum.
- At one end, a system only answers text questions.
- In the middle, it may choose between a few tools or ask follow-up questions.
- At the far end, it may plan several steps, call multiple tools, and decide how to continue based on intermediate results.
Most useful educational and professional systems stay closer to the middle. They are more reliable when the available tools, actions, and goals are narrow and explicit.
The label matters less than the workflow
Many current systems are described as “agents”, but that label can hide important engineering differences. Two applications may look similar from the outside while having very different internal behavior. One might only make a single tool call in a tightly controlled loop, while another might plan several steps and decide dynamically what to do next.
For software engineering, the important questions are therefore practical ones. What actions can the system take? What information can it access? Who approves consequential steps? How easy is it to inspect what happened after the fact? These questions are often more useful than arguing about whether a system is “really” an agent.
Bounded autonomy
The phrase bounded autonomy refers to a practical compromise:
- allow the model to choose between a controlled set of actions,
- but keep the surrounding system in charge of what those actions can do.
This is often a better design than either extreme:
- forcing the user to do every tiny step manually,
- or allowing the model to execute unrestricted actions.
The most important design choice in many agent-like systems is not “How autonomous is the model?” but “What is the maximum authority the system should have?”
When not to use an agent
If a task can be handled by a simple deterministic function, adding an LLM loop may only make the system slower, more expensive, and less predictable.
Agent-like patterns become more useful when:
- the task includes open-ended user language,
- the system must decide which tool or information source is relevant,
- or the next step depends on the result of the previous one.
If none of those conditions hold, a simpler design is often better.