The distinction that matters
A chatbot is a conversational interface. It can answer questions and, with integrations and permission checks, look up orders, create records or trigger actions. An AI workflow uses a model within predefined steps. An AI agent lets a model choose some next steps or tools towards a goal, within explicit limits. These categories can overlap: a chatbot may front either a fixed workflow or an agent.
Choose by the decisions the system must make, its permissions and the consequences of error, not by the label. A fixed booking flow can act without being an agent; an internal research agent may only read information. Start with the least complex design that meets the need and test the whole workflow.
What agents are genuinely good at
Narrow, repetitive jobs where the information exists and the action is well defined.
- Qualifying enquiries. Asking the questions your sales process needs — requirement, quantity, location, timeline, rough budget — and creating a structured record before a person joins.
- Answering from your own material. Retrieving the relevant passage from your price lists, policies or specifications and answering from it.
- Routing. Classifying a request and putting it in front of the right person with the details already gathered.
- Status lookups. Checking an order, booking or ticket in a connected system and reporting back.
- Internal knowledge. Answering staff questions from documentation that exists but nobody can find quickly.
- Draft preparation. Assembling a quotation or a summary for a person to check and approve.
Notice that several of these end with a human. That is not a limitation of current technology so much as a sensible design choice about where commitment happens.
What agents are bad at
Equally important, and less often stated by people selling them.
- Open-ended goals. An agent told to "grow the business" will produce activity, not results. Scope is everything.
- Long chains of dependent steps. Reliability compounds downward. A sequence can fail when any dependency fails; test end-to-end completion, not only individual model answers.
- Judgement calls with real consequences. Pricing negotiation, credit decisions, medical or legal matters, anything irreversible.
- Situations not covered by their material. A well-built agent says so. A badly built one invents something plausible.
- Emotional situations. An upset customer wants acknowledgement from a person. Offer a person promptly instead of forcing the customer through repeated automated replies.
How answers stay accurate
Grounding retrieves relevant information from approved sources before an answer is generated. It reduces hallucination risk; it does not eliminate it. Retrieval can miss the right passage, documents can be outdated, and a model can misread an accurate source.
Test missing information, conflicting documents, misleading instructions in retrieved text and requests outside scope. Require the assistant to acknowledge uncertainty and provide a human route. Keep source ownership and revision dates clear; validate consequential details against the system of record before acting.
Guardrails worth insisting on
If you commission an agent, these should be in the specification rather than discussed after something goes wrong.
- An explicit job description. What it handles, and what it must never attempt.
- Escalation topics agreed in writing. Complaints, refunds, negotiation, medical, legal, financial, and anything involving sensitive personal data.
- Scoped action permissions. The agent can only do what you have granted, and high-impact actions require human approval.
- Proportionate logging with sensitive-data masking, restricted access and agreed retention.
- Disclosure that customers are dealing with an automated assistant, with a human route always visible.
- An off switch you can operate without contacting your provider.
A provider reluctant to commit to any of these is telling you something useful.
A worked example
Hypothetical example, not a client case study: an industrial supplier receives requests containing product names, quantities and delivery dates. A fixed form may cover structured requests; a language model may help extract details from free text. An agent is worth considering only if requests require different permitted lookup steps.
- Capture a request ID and validate the extracted specification with the buyer.
- Retrieve current catalogue information using read-only permissions.
- Prepare a draft enquiry record, flag missing details and route it to the responsible salesperson.
- Require approval for prices, delivery commitments and any message that creates a commercial obligation.
Measure extraction errors, human correction time, duplicate records and response time against a manual baseline. Faster acknowledgement does not establish that more sales resulted.
Do you need one?
Work through this honestly.
- Is your enquiry volume high enough? Compare frequency, effort per request, build and operating cost, and failure risk. Low volume alone does not decide value.
- Are the questions repetitive? If every enquiry is genuinely different, an agent has little to work with.
- Is your information documented? If not, that is the first project. An agent cannot answer from material that does not exist.
- Would plain automation be enough? Often yes. If the workflow follows fixed rules, you do not need a language model. See what AI automation involves.
- Would a chatbot be enough? A chatbot with a fixed workflow may be sufficient. Risk depends on the connected actions and data, not whether the interface is called a chatbot. See what an AI chatbot is.
Our general advice is to start with the simplest thing that could work. A narrow agent doing three things reliably is worth considerably more to a business than a broad one attempting anything.
Reliable actions and proportionate records
Plan for timeouts, rate limits and unavailable integrations. Use bounded retries for temporary failures, and a unique request or operation ID to prevent duplicate records, messages or bookings. A timeout can occur after an action succeeds: check its status before retrying. Alert a named owner after retries are exhausted, preserve a recoverable queue and offer human escalation. Test cancellation, duplicate delivery and partial failure before expanding access.
Log enough to diagnose failures: event IDs, timestamps, action status, approval decisions and a limited sample of interactions where justified. Mask sensitive data, exclude credentials, restrict access by role and agree a retention and deletion period. Do not keep every conversation indefinitely. Use redacted examples for testing and explain the collection to users.
For a fixed integration, compare AI automation services before commissioning model-directed tools.
Sources and further reading
- Anthropic: workflows and agents
- OWASP: secure application logging
- AWS: making retries safe with idempotent APIs
These sources explain platform guidance or engineering principles, not evidence of PresenticAI client results. Guidance checked on 14 October 2026.
Thinking about an AI agent?
PresenticAI builds narrowly scoped agents with grounded answers, defined permissions, logged conversations and human escalation — and will tell you when simpler automation would serve you better.