A chatbot is a way to interact through conversation. A workflow defines the steps and branches a task can follow. An AI agent uses a model to select its next steps from the information it gathers. These describe different parts of a system, so one application can use all three.
For a business task, make two decisions: how people should interact with the application, and who should choose the next action. Use chat when conversation helps, a workflow when the paths are known, and a bounded agent when the investigation must adapt to new evidence.
The panels compare roles, not mandatory stages. A chat window can start a fixed workflow or expose an agent; it does not tell you how the work behind it is controlled.
Separate conversation from control flow
A chatbot accepts conversational input and responds through text or speech. It may use rules, an AI model, or both. IBM’s chatbot overview describes conversational interfaces that can also retrieve information and complete actions. Calling a tool does not, by itself, make a chatbot an agent.
A workflow specifies how work moves between steps. A branch such as “if an incident is active, use the incident response; otherwise check the error code” is still a workflow. It need not be a single straight line. A workflow can also call a large language model, or LLM, to classify a request or draft an explanation.
An AI agent, as used here, lets a model choose what to do next based on observations: the results returned by tools. A tool is an application operation such as reading a ticket or looking up an incident. The application still controls permissions and stopping rules. Anthropic’s architecture guide makes this distinction between predefined paths and model-directed execution. Terminology varies between products, so inspect the actual control flow rather than relying on the label.
For example, “chatbot with an agent behind it” is a reasonable design. So is “workflow with one agent step for difficult investigations.” Neither requires giving a model unrestricted access.
Compare the same support request
Consider an illustrative software service. A customer writes:
My export failed. Can you help me get the report?
The support application may read the customer’s assigned ticket, check a service-incident feed, and search an approved troubleshooting guide. Its goal is to prepare a supported response or hand the case to a person. It cannot change account settings, send a reply, or issue a refund automatically.
Assume the incident feed reports an active export outage. The guide contains a separate timeout workaround: try a smaller date range. During an active outage, the team wants the incident response rather than that generic workaround.
These assumptions matter. The comparison below changes how the same evidence is gathered and used, not which application has better data or more permission.
Chatbot: make the interaction conversational
In a simple chat-led version, the assistant asks for the failed export’s ticket reference. The application verifies that the customer can access it, then looks up the incident and presents a response:
An export incident is active. The team is investigating. Your case can be passed to support if you need further help.
The customer can ask a follow-up question or clarify what they need. That interaction is useful when the initial request is incomplete.
This tells us little about the underlying execution. Code could require the incident check, or a model could choose it. To make the example concrete, assume this chatbot uses the fixed workflow described next. Its trace is therefore the same workflow trace, with a conversation around it.
A chat interface adds the work of maintaining conversation context, handling clarification, and recovering when the user changes the subject. It also adds a risk: a fluent answer can make an unsupported conclusion sound settled. Show the evidence that supports the response.
Workflow: make the required path explicit
The team defines this sequence:
- Validate the ticket reference and customer access.
- Check the service-incident feed.
- If an export incident is active, prepare the approved incident draft.
- Otherwise, read the error code and look up its approved response.
- If evidence is missing or a lookup fails, create a human handoff.
For the example input, the observable trace is:
validate ticket: allowed
check incident: export outage active
select branch: incident response
result: draft for review
These are illustrative process traces, not logs from a live service. The workflow stops after selecting the incident branch; it does not need the timeout guide. An unknown error code on the other branch would lead to handoff.
The advantage is control: every case follows an allowed path, and the team can test each branch. The disadvantage is maintenance. A new diagnostic path requires someone to define and review it. A fixed path can also do unnecessary work, such as checking a feed for a request that clearly concerns billing.
“Deterministic” here describes the example’s routing for the same supplied inputs. It does not mean a production run will always produce identical results. External data changes, calls can fail, and any model-written prose can vary.
Agent: choose the investigation as evidence arrives
An agent receives the same request, goal, and tool permissions. Suppose the model first chooses to read the ticket, then finds a timeout code. It searches the guide and sees the smaller-date-range suggestion. It next checks the incident feed and discovers the outage.
One possible trace is:
read ticket: export timeout
search guide: smaller date range suggested
check incident: export outage active
revise draft: prefer the incident response
result: draft for review
Another model run might check the incident first. This is a hypothetical trace, not a claim that a particular model will reliably make either choice. The flexibility is useful when a request’s next lookup cannot be decided easily in advance.
It also introduces a failure mode: the agent could stop after reading the generic timeout advice and miss the outage. If an incident check is mandatory before any export recommendation, enforce that requirement in application code. Do not make compliance depend on whether the model happens to choose the right tool.
In the example, allow at most four tool calls and require a draft or handoff after that. A repeated or irrelevant lookup consumes that budget too. Real systems also need call timeouts, output limits, and a spending limit; a tool-count limit alone cannot bound all costs.
What changes in operation?
| Question | Chat interface | Fixed workflow | Agent execution |
|---|---|---|---|
| Who chooses the next step? | Depends on the system behind the conversation. | Code selects from defined paths. | Model proposes steps; application enforces limits. |
| Can it use tools? | Yes, if the application exposes them. | Yes, at specified stages. | Yes, from an allowed set. |
| What is predictable? | The interface, not necessarily the execution. | Allowed paths; outside data and model outputs can still vary. | Available actions and budgets; chosen paths can vary. |
| What needs testing? | Clarifications, context changes, and backend behavior. | Every branch, input validation, and failure recovery. | Outcomes across repeated runs, tool choices, and boundary violations. |
The number of model calls is not determined by the product label. A rule-based chatbot may make none. A workflow might call a model once to classify and again to draft. An agent might need several decisions, or finish quickly. Tool calls, model input/output size, retries, and human review all affect operating cost.
Measure completed, useful work rather than the cost of one response. For this support task, track whether the response uses the current incident evidence, how long the customer waits, the model and tool usage, and how often a person must repair the result. Do not assume an agent is cheaper because it runs without supervision, or a workflow is faster regardless of its steps.
Combine the approaches deliberately
A practical support design could use chat to collect the ticket reference, a workflow to validate access and check incidents, and an agent only for unresolved diagnostic cases. Every path ends in a reviewed draft or a staffed handoff queue.
This preserves predictable checks while allowing flexible investigation where it helps. It also adds integration work: the workflow and agent need an agreed format for evidence, outcomes, and handoff reasons. Someone must own cases that stop midway.
Regardless of execution style, a model’s request to call a tool is not proof that the action is allowed. OpenAI’s function-calling guide separates model requests from application-side execution and returning the result. Check access in application code. Treat customer messages and retrieved documents as data, including text that asks the model to ignore its rules.
For a related conversational example, see the older shop support chatbot article. Its pricing-question scenario shows a narrower interaction; its historical SDK snippets are not current integration instructions for this article.
Choose with a small evaluation
Start with the workflow above as a baseline. Build a small set of synthetic or safely anonymized tickets, including these cases:
| Case | Required observable result |
|---|---|
| Active export outage | Draft cites incident evidence and avoids presenting the generic workaround as the resolution. |
| No incident, recognized timeout | Draft includes the approved guide advice. |
| Unknown error or failed incident lookup | Handoff includes the missing evidence or failure reason. |
| Another customer’s ticket reference | Access denied before ticket data is returned. |
| Request to send a reply or issue a refund | No action occurs; the request goes to the appropriate review path. |
| Repeated agent lookups | Budget stops execution and records an unfinished investigation. |
Run fixed paths against controlled inputs, and repeat model-driven runs because one good trace does not establish reliability. Review what evidence was collected and why the system stopped. Compare quality, waiting time, usage cost, and human review effort on the same cases.
Use a form or direct API instead of chat when users already have structured inputs and conversation adds no value. Keep a workflow when the branches are known and dependable. Add an agent for cases that require adapting the investigation, provided that the improvement justifies more evaluation and operating controls.
The next step is to choose one representative business task, write its required checks and stopping conditions, and test the simplest design first. You can change the execution later without pretending that “chatbot,” “workflow,” and “agent” are three incompatible products.
Topics: AI agents, chatbots, workflows, control flow, support automation, evaluation, human handoff.