What Is an AI Agent? Chatbot and Workflow Differences
What is an AI agent? It is defined by who decides the next step: chatbot, workflow, or agent. Covers its four parts, failure cases, and cost control.
What is an AI agent? In one sentence: an AI system that decides for itself what to do next and actually does it.
The difference is in that last half of the sentence. ChatGPT can tell you how to change a config file, which makes it an assistant; an agent will open the config file itself, make the change, run it once to confirm nothing broke, and then report the result, with no one pressing "next" in between. It has tools it can use (reading and writing files, calling APIs, running commands, searching the web), it has a goal, and it runs in a loop of "observe → decide → act → check the result" until the goal is reached or it judges that it is stuck.
This article takes apart the term "AI agent," which has been talked about to death: how it differs from a chatbot, how it actually works, which situations justify using one, which situations backfire, and what the shortest path is if you want to build one yourself.
The Line Between Chatbot, Workflow, and Agent
Three things that are often confused can be separated with one question: "who decides the next step?"
| Who decides the next step | Example | |
|---|---|---|
| Chatbot | A person. You have to ask again every turn | A typical chat window |
| Workflow | The developer. Steps are hard-coded in the program | Automation that goes: receive email → summarize → save to database |
| Agent | The model itself. The path is not decided in advance | "Fix this bug for me" |
This line matters, because most products that claim to be agents are actually workflows, and that is usually the right choice. For work with fixed steps and predictable inputs, hard-coding is faster, cheaper, and easier to debug than letting a model decide each time.
There is only one real signal that you need an agent: you don't know in advance how many steps there will be or which steps they are. Fixing a bug might require reading three files or thirty; you can't hard-code that flow. In that case, letting the model decide the path is worth it.
What an Agent Is Actually Made Of
Broken down, there are only four parts:
1. The model (the brain) — handles reasoning and decisions. This is the part that is easiest to swap out, and it is also the main source of cost.
2. Tools (the hands and feet) — functions the model can call: reading files, writing files, running commands, querying databases, calling APIs. The quality of the tools sets the ceiling for the agent: if the tool descriptions are vague, the model picks the wrong tool; if the tool's error messages are vague, the model can't correct itself.
3. The loop (the rhythm) — the model outputs "I want to call tool X," the system runs it and feeds the result back, and the model decides the next step. This repeats until it outputs "done."
4. Memory and context (the workbench) — what it can see in this turn. Too much context makes it dumber; too little makes it forget. This is the part that takes the most thought in implementation.
A real request looks like this (OpenAI-compatible format; most frameworks are built on this shape underneath):
from openai import OpenAI
client = OpenAI(
api_key="sk-bl-your-key",
base_url="https://api.bazaarlink.ai/v1",
)
tools = [{
"type": "function",
"function": {
"name": "read_file",
"description": "Read the full contents of one file in the project",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string", "description": "Path relative to the project root"}},
"required": ["path"],
},
},
}]
resp = client.chat.completions.create(
model="anthropic/claude-sonnet-4.6",
messages=[{"role": "user", "content": "Take a look at what src/index.ts does"}],
tools=tools,
)
# resp.choices[0].message.tool_calls → the model decides to call read_file
The model doesn't return an answer; it returns "please run read_file(path="src/index.ts") for me." You run it, add the result back to messages, and call the model again. That is the loop. The core of an agent is about this much code; everything else is engineering.
Ready-Made Agents You Already Use
You don't have to build one from scratch. In the coding context, for example, mature terminal agents are already everyday tools:
- Claude Code — opened in a project directory, it reads the structure on its own, edits multiple files, and runs tests. For getting started, see the Claude Code tutorial.
- Codex CLI — a similar tool, with especially detailed permission and sandbox settings. See the Codex tutorial.
Other common types: customer service agents (look up orders, change addresses, open refund requests), research agents (run multiple rounds of search and produce a report), and operations agents (read logs, compare against monitoring, and recommend remedies).
If you want to assemble your own, the Python world commonly uses LangChain / LlamaIndex / CrewAI, while the TypeScript world mostly uses the OpenAI SDK plus its own loop. As shown above, the loop itself takes little code; the value of a framework lies mainly in memory and tool management.
Where Agents Fail
More important than "what it can do" is knowing these first:
Fixed-step tasks. If you can hard-code it, do so. Having the model re-decide every time costs you extra money and extra uncertainty.
Tasks where mistakes are unacceptable. Agents make mistakes; this is normal, not a bug. So dangerous actions must keep a human in the loop: transfers, sending emails, deleting data, deploying all stop and wait for approval. The design principle is allow read-only and reversible actions through; do not allow anything that affects the outside world.
Tasks with no feedback signal. An agent corrects itself through "act → check the result." The reason coding scenarios work especially well is that tests and compilers act as the judge. A task without a judge (for example, "write a good ad copy") won't get better after ten rounds than after the first; it will just take longer.
Long tasks where the context blows up. As a run goes on, the context fills with old information and quality actually drops. In practice, you need to clean up or compress the context on a regular basis.
Cost: Agents Are More Expensive Than You Think
A single chat is one call; an agent task is dozens of calls, each carrying an ever-longer context. Give an agent the same sentence and the token count may be 20–50 times that of asking directly.
Three controls that are actually useful:
- Layer your models. Use a strong model for decisions and planning, and send routine work like summarizing, classifying, and format conversion to cheaper models. This step alone usually cuts a large share of the cost.
- Set limits. Set the maximum number of loop iterations, the maximum tokens, and a budget per task, so it can't burn money on a problem it can't solve.
- Use caching well. The system prompt and tool definitions are resent every turn. Services that hit prompt caching can save a considerable amount on this repeated cost.
The Shortest Path to Trying It Yourself
Don't start with a framework. Start with one tool:
- Get an OpenAI-compatible API key.
- Write a loop with just one tool (the code above is the skeleton).
- Give it a real but small task, for example "read this folder and tell me which files are not imported anywhere."
- Watch what it is thinking at each step, and print the
messagesfrom every turn. This is the fastest way to understand an agent; seeing it once beats reading ten articles. - When it gets stuck, the cause is usually not a dumb model but unclear tool descriptions. Fix the descriptions, not the model.
You can get a key at bazaarlink.ai/free, and the free tier is enough to get the whole loop running. BazaarLink is an OpenAI-compatible relay, so with the same code you can swap the model string to compare how different models perform and cost on your task. For the list of available models, see the model list.
Summary
An AI agent is not a smarter chatbot; it is more tools, more loops, and fewer people in the loop at each step. These three things bring capability, along with risk and cost.
To decide whether to use an agent, go back to the one question: do you know in advance which steps need to be done? If you do, write a workflow; only when you don't does the agent come into play. If you want to feel directly how far it can go, starting with an existing coding agent is much faster than building one yourself.
FAQ
How is an AI agent different from a chatbot?
It comes down to who decides the next step. A chatbot needs a person to ask again every turn. An agent has a goal and callable tools, and it keeps going on its own through a loop of observing, deciding, acting, and checking results, until the task is done or it judges that it is stuck.
How is an AI agent different from an automated workflow?
In a workflow, the developer hard-codes the steps in the program; in an agent, the model decides the path at runtime. For fixed steps and predictable inputs, a workflow is faster and easier to debug. An agent only pays off when you don't know in advance how many steps there will be or which steps they are.
What parts make up an AI agent?
Four parts: the model handles reasoning and decisions, tools are its hands and feet, the loop feeds tool results back so it can decide the next step, and memory and context determine what it can see in each turn. In practice, the quality of the tool descriptions sets the ceiling on how well the agent can perform.
When should you not use an AI agent?
For tasks with fixed steps (hard-coding is cheaper), tasks where mistakes are unacceptable (dangerous actions need a human to approve them), and tasks with no feedback signal (without tests or a judge, running more rounds won't make it better). Long tasks also need attention, since quality drops once the context fills up.
Why are AI agents more expensive to run?
A single chat is one call; an agent task is dozens of calls, and the context keeps growing. Practical controls are layering models (a strong model for planning, a cheap model for routine work), setting a maximum loop count and budget cap, and making good use of prompt caching.
What is the shortest path for a beginner to try building one?
Don't start with a framework. Get an OpenAI-compatible key, write a loop with just one tool, give it a real but small task, and print the messages from each turn to see what it is thinking. When it gets stuck, the cause is usually unclear tool descriptions, not a dumb model.
TWD billing · Taiwan invoices · leading AI models · OpenAI-compatible API