A Chatbot only queries your knowledge base. A Workflow runs the steps in the order you laid out.
An Agent is a third kind: you hand it a set of tools, and it decides which to use, how many times, and when to stop.
That sounds powerful, and it is also the least predictable of the three app types. This article spells out what it suits and what it doesn't.
30-second overview
| Chatbot | Workflow | Agent | |
|---|---|---|---|
| Who decides the steps | Fixed | You | The model |
| Predictability | High | High | Low |
| Handling unfamiliar questions | Weak | Weak | Strong |
| Model cost | Low | Medium | High (multiple calls per turn) |
| Difficulty of debugging | Low | Medium | High |
| Best for | Q&A on a single topic | Tasks with a clear process | Questions you can't enumerate in advance |
What an Agent actually does
It runs a loop:
- Read the user's question
- Decide whether a tool is needed, and which one
- Call the tool and get a result
- Decide whether that's enough information; if not, go back to step 2
- If it is enough, turn it into an answer
Steps 2 and 4 are the crux — those decisions are made by the model, not by you. That is where its value comes from, and where its risk comes from.
Choosing between the two strategies
Function calling
Relies on the model's native tool-calling ability. Accurate and fast, but the model has to support it.
If your model supports it, use this one.
ReAct
Uses the prompt to steer the model through a "think → act → observe" loop. Broadly compatible — it runs on any model — but the reasoning consumes more tokens and it's more prone to taking detours.
It fits when your model has no native tool calling, or when you want to see the reasoning in order to debug.
Where the tools come from
Built-in tools
Search, calculation, image generation and the like. Easy to configure, and most need an API key for the corresponding service.
Custom tools
Describe your own API with an OpenAPI spec and the Agent can call it. This is what makes an Agent able to actually do things — order lookups, stock checks and ticket creation all come from here.
Workflows as tools
A workflow you've already built can be wrapped as a tool for the Agent to use. It's a very practical combination: the Agent decides what to do, and the workflow does it reliably.
Tool descriptions make or break it
An Agent decides whether to use a tool from its description. Write the description badly and it will pick the wrong tool or none at all.
| How it's written | Result |
|---|---|
| "Look up orders" | Too vague; it doesn't know when this applies |
| "Look up shipping status and estimated delivery date by order number. Requires an order number." | Clear: it knows when to use it and what it needs |
The principle: write it for a new colleague who has never seen your system. When they should use this tool, what they need to have ready, and what they'll get back.
Cap the number of iterations
An Agent can get stuck in a loop — the tool returns something unexpected, so it tries again, and again.
Every round is a model call, which means a charge. Always set an iteration limit; three to five is usually plenty. If it hits the limit without reaching a conclusion, the tool description is usually at fault, or the data it needs simply doesn't exist.
When you shouldn't use an Agent
Honestly, most requirements don't need one:
- The process is fixed — use a Workflow. Handing clearly defined steps to the model just makes something predictable unpredictable.
- You only need document-based answers — use a Chatbot; it's cheap and stable.
- You need consistent answers — ask an Agent the same question twice and it may take different paths.
- You're cost-sensitive — multi-round calls cost several times what a Chatbot does.
The situations that genuinely justify an Agent are narrow: you can't enumerate the shapes of user questions in advance, and answering requires pulling from several data sources.
A concrete example: an order support Agent
Abstract explanations are hard to judge, so here's a specific one:
The tools attached to it
- Order lookup — shipping status by order number
- Shipping cost lookup — calculates shipping by region and weight
- Knowledge base search — return policy and product descriptions
How it runs
The user asks: "When will the thing I bought last week arrive? And how was the shipping calculated?"
- The Agent works out that there are two questions here and it needs two tools
- It calls the order lookup first — but finds there's no order number, so it goes back and asks the user
- With the number in hand, it looks up the shipping status
- Then it calls the shipping cost tool
- It combines the two results into one answer
Step 2 is the biggest difference between an Agent and a Workflow: a Workflow fails outright when a parameter is missing; an Agent finds a way to fill it in.
How a Workflow would handle the same requirement
You lay it out yourself: ask for the order number → look up the order → check whether they also asked about shipping → if so, look up the shipping cost → assemble the answer. Fixed steps, predictable cost, and when something breaks you know which box it broke in.
Both can do it; the difference is who carries the burden of thinking the process through. Stable requirements, lay it out yourself; changeable requirements, hand it to an Agent.
FAQ
Q: My Agent keeps not using the tool I configured
Nine times out of ten the tool description is too vague. Rewrite it as "when to use this, what parameters it needs, what it returns" and test again.
Q: The cost is much higher than I expected
Look at the iteration count. Every round of an Agent is a full model call, and if it regularly runs to the limit, the real cost is several times a Chatbot's. First check whether a failing tool is making it retry.
Q: The same question gives inconsistent answers
That's inherent to an Agent, not a bug — the path is decided by the model on the fly. Scenarios that need consistency should use a Workflow.
Q: Can I restrict it to just a few tools?
Yes — tools are attached one by one. Start with as few tools as possible and add more once the behavior is stable. The more tools there are, the more likely it is to pick the wrong one.
Estimating cost
Agent costs are hard to predict because the number of rounds floats. A rough approach:
Cost per conversation ≈ average rounds × model cost per round. And every round sends the earlier conversation and tool results along with it, so later rounds are more expensive.
In practice, run twenty real questions before launch, record the average number of rounds, and multiply by your estimated daily conversation volume. That figure is usually higher than instinct suggests — many people assume an Agent just "makes one or two extra calls", when three or four rounds is the norm.
Sources and further reading
- Dify official documentation — Agent strategies and tool configuration
- Dify release notes
- OpenAI API documentation — which models support function calling
Further reading
- Dify workflow orchestration guide: from single-turn Q&A to multi-step processes
- Dify tutorial: build your first AI chatbot
- Troubleshooting Dify: from model settings to a knowledge base that stops working
- Dify plus n8n: AI does the understanding, n8n does the execution
- RoamerHost Dify hosting plans
Want someone to build it for you?
If you would rather not assemble these workflows yourself, or the scale is big enough that you want someone planning alongside you, Roamer Tech (RoamerHost's parent company) takes on business process automation and custom AI agent development:
