The question usually arrives as a technology choice: chatbot or AI agent. Put that way it has no answer, because it sounds like a question about which one is more modern. The question that does have an answer is a different one: does your process have decisions inside it, or only a path?
What a traditional chatbot does
A flow-based chatbot works through paths that were anticipated. Somebody drew the tree: if the customer says this, answer that; if they pick option 2, follow this branch. More recent versions use AI to recognize the intent behind a sentence, which improves the entry point. What comes after is still the flow that was drawn.
That is not a limitation, it is a characteristic, and sometimes it is exactly what you want. An anticipated flow is predictable, cheap, easy to audit and it does not invent answers. For order status, duplicate invoices and opening hours, it does the job and does it well.
The limit appears when the customer steps off the path. A flow-based chatbot does not improvise: it repeats the question, offers the menu again or hands over to a human. And the number of paths that have to be anticipated grows faster than any team can maintain.
What an AI agent does differently
An agent does not receive a flow. It receives a goal, a set of tools (look up the order in the ERP, open a ticket, calculate shipping) and rules about what it may and may not do. At each step it decides which tool to use, looks at the result and decides the next step.
That is the practical difference: in a chatbot the path was decided beforehand; in an agent it is decided in the moment. Everything you gain and everything you lose by switching comes from that single change.
You gain coverage. The agent handles the request nobody anticipated, because it does not depend on the case having been drawn. You lose absolute predictability. Two identical questions can follow different paths, which makes governance, logging and action limits a mandatory part of the project rather than an optional extra.
Side by side
| Flow-based chatbot | AI agent | |
|---|---|---|
| Who decides the next step | Whoever drew the flow, beforehand. | The agent, during the conversation. |
| An unanticipated case | Falls back to the menu or goes to a human. | Tries to resolve it with the tools it has. |
| Access to systems | Occasional lookups, usually read-only. | Reads and acts in the ERP, the CRM and the channels, within the rules. |
| Maintenance | Editing branches of the tree, one by one. | Adjusting instructions, tools and limits. |
| Predictability | Total. The same input gives the same output. | High with governance, never absolute. |
| Cost per conversation | Low and stable. | Variable, depending on the number of steps. |
| What the audit asks for | The design of the flow. | The trail of every execution and decision. |
When the chatbot is still the right choice
It is worth resisting the temptation to replace everything. A flow is still the right answer when:
- The questions are few and repetitive, and the menu covers most of the volume.
- The answer has to be identical every time, because of a regulatory or contractual requirement.
- There is no system to query. With no tools and no data, the agent becomes an expensive chatbot.
- What you have today works and the complaint is about the content, not the rigidity. Bad copy does not improve by changing the technology.
When the case calls for an agent
- Customer service has to query and act in systems, not just inform.
- Every request arrives different, and the exception queue is consistently larger than the main path.
- The bottleneck is time to first response, and it costs business.
- The process crosses teams: it starts in sales, passes through finance and comes back.
- You need an audit trail of what was decided, and not only of what was answered.
A quick test: look at the last fifty conversations that went to a human. If most of them landed there because the customer stepped off the menu, the problem is rigidity and an agent solves it. If they landed there because information is missing from some system, the agent will not guess what nobody recorded.
How to switch without breaking what works
The migration that goes wrong is the one that turns the flow off on a Saturday and turns the agent on come Monday. The one that works usually follows this order:
- Keep the flow on what it already resolves. A simple, high-volume lookup does not need an agent, and moving it only raises the cost.
- Start with the queue that goes to a human. That is where the case the flow does not cover lives, and where the gain shows up first and measured.
- Give it read access before write access. The agent queries and recommends; the action stays with the person. That builds trust at low risk.
- Open up writing one operation at a time, with limits. One action at a time, with human approval where the value or the risk demands it.
- Measure resolution, not conversations. Volume handled says nothing. What matters is how much was resolved without passing to a person.
What changes when it works
Three operations that made this switch, with the numbers they measured:
- Osten Group: a 30% rise in contact-to-visit conversion, with pre-sales going from 7 people to 2.
- PX Ativos Judiciais: first-contact conversion from 4% to 10%, roughly R$ 1.5 million converted over the year without growing the team.
- Vero: R$ 2 million saved on overtime.
The pattern that repeats in these operations: the gain appears when the agent starts acting in the process, not when it merely answers better. Acting in the process is precisely what a flow does not do.
Where to start
If this is the decision in front of you, the shortest path is not picking the technology: it is looking at the process. In the free assessment we look at the process you have today and tell you plainly whether the case calls for an agent or whether the tool you already use solves it. When the answer is the second one, we say so.
