Choose the right system
AI agent vs chatbot: which one does your business actually need?
A chatbot describes a way to interact with a system through conversation. An AI agent describes how a system chooses steps while pursuing a goal. They can overlap: a chatbot can be the front door to an agent. Choose by the job you want completed and the authority you are prepared to give the system.
Decide whether someone needs an answer, a fixed action or a system that chooses its next step; the chat interface can sit in front of any of them.
Compare what happens after the question
| Question | Chatbot interface | Agent behaviour |
|---|---|---|
| How does a person interact? | They send a message and receive a response. | It may use chat, a form or a background trigger. |
| What happens inside? | It may answer, retrieve information or start a workflow. | A model selects permitted steps or tools towards a goal. |
| Does it change a system? | It can, if connected to an action. | It can, if its permissions allow that action. |
| Who determines the route? | The interface does not tell you. | The model has some responsibility for choosing the route. |
Product labels are inconsistent. Ask a supplier to show the route the work takes, including tool calls, permission checks and exceptions. A system named “agent” may still follow a fixed series of steps, while a chat product may have meaningful authority over records.
The technical distinction between fixed workflows and model-directed agents is explained in Anthropic’s agent design article. Your business choice still needs a concrete job and a reviewable result.
Work through three versions of the same request
Suppose a client asks about a report. “What does this metric mean?” may need a sourced answer. “Prepare the agreed report for this period” may need a fixed workflow that retrieves the right inputs. “Investigate what changed and decide which source to inspect next” may justify agent behaviour.
Each version needs authorised client context. The investigation also needs clear limits on which tools it can use and how long it can continue. None of these choices removes the need to establish the metric definition or report a missing source.
In our current build, Said describes provenance travelling with the information so a human can inspect the answer. If the required evidence cannot be queried or quoted for review, the system must say it does not know. That requirement applies whether the person begins in chat or elsewhere.
Choose the system that can finish the agreed job
If people need consistent answers from current documents, begin by testing retrieval and source accuracy. If they need a known action, inspect whether existing software can carry it out after approval. Give a model control over the route when choosing that route is a real part of the work.
Separate read access from action access. A system that can explain a client agreement does not automatically need authority to edit it. State which person approves a change and what evidence they receive.
Compare complete-job effort. Include reviewing answers, resolving gaps and maintaining source information. A more capable demonstration may create a more expensive system to run and support.
Write down the job and its authority
Worked example
Three client-reporting requests
Invented teaching example. No client outcome is claimed.
ANSWER
Explain an agreed metric using its current definition and source.
FIXED ACTION
Prepare the standard report from approved inputs, then pass it to the reviewer.
SELECTED ROUTE
Investigate a change by selecting authorised sources, then present observations for expert review.
BOUNDARY
No version has authority to change the client agreement or campaign budget.
The investigation is a proposed design, not a delivered result.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.