A service team wants help answering customers, but proposals labelled “chatbot” and “AI agent” may describe very different capabilities. First decide whether the system should answer from approved information, retrieve current customer data, or choose and perform several steps. Each creates different operating and review needs.
The terms are not mutually exclusive. A chatbot is a conversational interface; the process behind it can follow fixed rules or let a model choose its next action. Evaluate the behaviour rather than the product label.
Task one: answer from approved information
Questions about services, contact routes or required documents can often begin with retrieval from information the team has approved. The challenge is finding the relevant answer and recognising missing context. Every exchange does not need autonomous planning or several tools.
In an illustrative case, a customer asks whether their location is covered. If coverage depends on the service type, the system should ask which service they need before answering. If the location is absent from the approved source, it should hand over the question rather than assuming nearby locations share the same policy.
Acceptance here means using the correct information, clarifying ambiguous requests and avoiding invented conditions. Customers also need a direct route to a person without having to repeat an unsuccessful conversation to prove they need help.
Task two: retrieve this customer's status
“What is happening with my request?” cannot be answered from a general manual. The system needs to establish that the requester may view the record and then read its current status from the appropriate source.
A predefined workflow may be sufficient: verify the requester, collect a reference, retrieve the status and explain it clearly. There is little reason to let a model independently explore several systems when the correct path is already known.
If the source system is unavailable, say that the latest status cannot be checked. Do not present an older value as current. Keep the retrieved facts distinguishable from the wording generated to explain them, so staff can verify that the meaning has not changed.
Begin the trial with read-only tools and a record of which item was consulted and what was returned. Granting write access is a separate decision from establishing a working connection.
Task three: investigate a problem across several sources
Some requests have no single route. A customer reports inconsistent information, for example, and the team must examine the original request, attachments and earlier conversations before identifying what is missing. Selecting tools and adapting the next step to the evidence may be useful here.
An agent approach could fit this task, but it needs limits on available tools, retries and conditions for stopping. Without those boundaries, more searching can consume resources without resolving the uncertainty.
Anthropic's Building effective agents distinguishes predefined workflows from systems in which a model directs its process and tool use, and recommends matching complexity to the task. That distinction is useful even when vendors use different terminology.
Separate proposing a resolution from executing it. A system might assemble evidence and prepare a recommendation for staff. Changing customer records, issuing refunds, confirming prices or making delivery commitments should require approval from an authorised person, with the exact record and conditions checked before action.
Choose for the hardest task that is actually required
| Work required | Starting approach to consider | Evidence needed |
|---|---|---|
| General answers from approved sources | Bounded retrieval and conversation | Supported answers and appropriate clarification |
| Status lookup using a reference | A predefined connected workflow | Correct access checks and record retrieval |
| Investigation across several sources | An agent with restricted tools and human handover | Traceable evidence, stopping behaviour and permission boundaries |
This is a way to select a trial, not a ranking of sophistication. More freedom can offer flexibility, but it also introduces more possible failure paths and monitoring work. Measure response time and cost against representative tasks too.
What to look for in a demonstration
Ask the provider to demonstrate incomplete information, conflicting sources and an unavailable connected system. Observe what the customer sees, how much context reaches the employee and whether tool activity can be reviewed. A demonstration consisting only of prepared questions does not establish those behaviours.
Evaluate correctly completed work and the effort left for staff, rather than only the volume of conversations handled. If almost every conversation is transferred with an inaccurate summary, employees may need to start again despite an impressive-looking interface.
The first system should complete the required work in a way the team can inspect. Add capability when recurring limitations show where it is needed. A clearly defined starting task makes it easier to tell whether the next improvement should be better information, a revised process or more freedom to choose the steps.
For a question-answering pilot, start by preparing company documents for AI before expanding autonomy. Source quality and access remain essential whichever approach you choose.
Choose the right AI workflow, then build it for your team
Talvyn Labs builds AI chatbots and agents around the questions and service tasks you want to support. We define data connections, action permissions and human handovers with you. Bring anonymised conversation examples to start a practical discussion about scope.
Discuss service AI