AI Agents, Workflows and Chatbots: Which Does the Job Need?

A customer asks for a refund on a damaged item. A conversational assistant can retrieve the returns policy and explain the next step. Its contribution is informational. The customer or a member of staff still completes the transaction.

A workflow can go further. It may collect the order number, verify required information, check a fixed eligibility rule and send the request to the appropriate queue. The route is largely specified in advance, even if AI helps interpret the message or draft a response.

An agent can be given a goal and some freedom to choose its next action. It might inspect the order, ask for evidence, check delivery history and select a tool to propose or issue a refund. The extent of that freedom depends on the implementation.

These categories can overlap. A workflow may contain an agentic step; a chat interface may sit in front of a conventional application. Anthropic's account of workflows and agents distinguishes predefined paths from systems that dynamically direct their own process and tool use.

For a buyer, the label is less revealing than the action list. Ask what the system can read, create, change and approve. The interface may remain a chat window while the business exposure changes completely.

A stable process with known branches often benefits from explicit control. If every approved refund requires the same information and follows the same rules, a predefined workflow can make the route easy to understand and inspect. AI may still help with unstructured messages without selecting the entire sequence.

Greater flexibility becomes more relevant when the route cannot be fully determined at the start. A research task may require several sources. A troubleshooting task may need different checks depending on what the first check reveals. Even then, the available actions and stopping conditions can remain tightly bounded.

The commercial question is whether flexible planning improves completion enough to justify additional complexity. More possible paths can mean more testing, longer processing and harder investigation when a result is wrong. A demonstration featuring an unusual case may hide these operating costs.

Ask a vendor to show a simple case, a difficult case and a case the system should refuse or escalate. Observe whether the additional autonomy changes the outcome or merely produces a longer sequence.

An architecture should fit the uncertainty in the task. It should also fit the organisation's ability to supervise it. A small team with limited operational support may be better served by a narrower system it can understand and maintain.

Reading a stock level is different from changing it. Preparing a purchase order is different from sending it to a supplier. Recommending a discount is different from granting one. These distinctions should exist in the system's permissions, rather than only in a written instruction telling the model to behave carefully.

Map the proposed actions into practical levels. Some can run automatically because they are low impact and easy to verify. Others can produce a draft for approval. Certain actions should remain unavailable, particularly when they fall outside the process the business has authorised.

Limits may include transaction value, record type, customer group or the period during which an action is valid. A system that can help arrange a service appointment does not necessarily need access to every customer record or permission to change payment details.

Anthropic's research on trustworthy agents discusses controls over agents' capabilities and permissions. The procurement implication is concrete: request evidence of how restrictions are enforced in the connected tools.

Approval should occur at the consequential point. Asking someone to approve a broad objective at the start may provide little control over a later commitment. Show the reviewer the exact proposed action, relevant evidence and expected consequence while there is still time to change it.

An agent may read documents, messages and web content while performing its task. Those materials can contain inaccurate information or instructions that were never authorised by the business. Access to a sentence does not make it a valid command.

Keep trusted operating rules separate from the material being processed. A customer's email can describe a requested refund; it cannot grant the assistant permission to bypass approval. A supplier document can provide product details; it cannot change who is authorised to place an order.

The same separation applies to the model's own output. NIST's Generative AI Profile discusses risks including confabulation. An agent should obtain transaction facts from the appropriate record and validate required conditions before taking a consequential action.

State also matters. If the system says it has completed a refund, there should be evidence from the payment or order system supporting that statement. A plan to act, an attempted action and a confirmed result are separate events.

For buyers, this suggests a straightforward demonstration request: show where the system gets a critical fact, what validates it and how the result of an action is confirmed. If those answers are vague, adding more autonomy would make the uncertainty harder to manage.

The visible cost may be a subscription or usage charge. The operating arrangement also includes integration work, review, access management, evaluation and support. When an agent takes several steps, both cost and completion time can vary with the path it follows.

Set limits on execution and define what happens when they are reached. A system should not continue indefinitely because it has failed to obtain an answer. It needs a way to stop with a clear account of completed actions and unresolved work.

Ask about recovery before launch. If a tool times out after creating a record, can the system establish whether the action succeeded? If two applications disagree, who reconciles them? If a member of staff intervenes, will the automation recognise the change?

Keep an activity history that is detailed enough to investigate important outcomes without indiscriminately retaining sensitive data. Operational staff need readable status; technical staff may need deeper records. Both should be able to identify the same request.

These requirements connect software development and cybersecurity to the automation project. An agent operating inside business systems is part of the organisation's application environment, with the same need for ownership, controlled access and maintenance.

A strong project brief describes a class of work the system should complete, the information available, permitted actions, approval requirements and a clear endpoint. It also states the cases that must return to a person.

Use that brief to compare proposals. One supplier may offer a conversational assistant that prepares high-quality drafts. Another may offer an integrated workflow. A third may propose an agent with more freedom. Their names tell you less than their coverage, controls and evidence from representative cases.

Test the smallest arrangement that can address the business problem. Expand authority only when the existing scope works reliably enough and the next permission produces a defensible benefit. Technical capability alone does not establish the case for a wider remit.

The resulting system may be called an agent, a workflow or an assistant. The business should still be able to explain its role in a sentence, identify who owns its failures and show which commitments it is allowed to make. That clarity is a better procurement standard than the ambition of the product label.

That explanation should remain accurate after the demonstration ends and ordinary staff take responsibility for the system.