AI agent vs chatbot: what should your business actually build?

Teams often ask for “an AI” and then receive a chat window. Sometimes that is the right product. Often the work they described is a task: find the record, draft the reply, file the document, move the request to the next queue. A chatbot and an agent are different designs for those two situations.

What a chatbot is for

A chatbot holds a conversation. It answers from a defined set of knowledge, asks a clarifying question, and helps someone complete a form or find a page. It does not need permission to update a customer, a payment, or a system of record, because it should not be doing those things.

Choose a chatbot when the successful outcome is an answer or a guided step. Policy questions, product explanations, and “which of these three options applies to me?” are chatbot work. The engineering is still real: you need a source of truth, a way to refuse questions outside that source, and a route to a person when the conversation stalls. You do not need a loop that calls tools and decides the next action.

What an agent is for

An agent is built to move a task along. It reads context, chooses among the tools you have allowed, and produces a draft or a proposed change. The useful version is boringly specific. “Prepare a reply to this support ticket using the account and the last three orders” is an agent job. “Be our AI employee” is not a specification.

The moment the task can change a record, send a message, or spend money, the design needs a stop. Phigz treats that stop as part of the product. The agent gathers and proposes. A person commits. That pattern is what we mean by agentic AI solutions, and it is also the sensible shape of most AI automation work.

A practical way to choose

Write the task as a list of steps, the way a careful colleague would do it on a quiet afternoon. Then mark each step.

• Read: looking up a policy, an account, or a document.
• Draft: a reply, a summary, or a set of extracted fields that nobody has accepted yet.
• Commit: sending, updating a system of record, taking payment, or telling a customer the outcome is final.

If every step is a read and the user only wanted an explanation, build a chatbot or even a well-structured help page. If the value is a draft assembled from several systems, an agent or a fixed workflow will earn its place. If a step is a commit, do not let the model take it alone unless you have a separate, explicit reason and a way to undo it.

Fixed workflow or a choosing agent

Not every multi-step task needs an agent that decides what to do next. If the path is stable — classify the email, extract five fields, drop the draft in a queue — ordinary automation with a model at the language step is simpler to test and simpler to pause. Use an agent when the path branches and the next tool depends on what was just found.

Either way, keep the permissions smaller than the demo suggests. An agent that can read a CRM does not also need to edit every object in it. Start with the one workflow, the tools that workflow requires, and a log of what was read and what a person changed.

What to ignore in the sales language

“Autonomous” is usually a warning that the approval step was skipped in the pitch. “It learns your business” often means the prompt will be edited later by hand. Neither phrase tells you whether the first release has a source of truth, a failure path, or a person in the loop.

Ask instead: what is the task, which system does it read, what is it allowed to change, and who notices when it is wrong? If those answers are clear, you can brief a build. If they are not, the next piece of work is the brief, not the model.