What makes an AI agent different from a chatbot?

A chatbot can explain how to reorder office supplies. A system connected to stock records, approved suppliers and a purchasing tool can help carry out the order. The interface may look identical, while the consequences of its output are very different.

“Agent” has no single universally applied product definition. Some tools use the label for a fixed sequence of actions; others let a model choose the next step as it observes results. The useful questions concern capability, discretion and authority.

The boundary is a spectrum. A conversational system can use tools, and an agent can present a chat interface. Tool access alone does not establish autonomy: the important distinction is how much discretion the system has over its next action and what it is authorised to do.

Follow an ordinary business task

Take a hypothetical company that wants to replenish printer paper. A conversational assistant might suggest quantities or write an email. An agent could inspect stock, check recent usage, compare approved suppliers and prepare a purchase request.

It needs tools to obtain current information and perform actions. Reading a spreadsheet, searching a catalogue and creating a purchase order are different capabilities. The model’s general knowledge cannot substitute for an actual stock check, and a convincing statement that an order was placed is not proof that the purchasing system accepted it.

After each tool call, the system needs to interpret the result. If a supplier has no stock, it might look for an approved alternative. If the price exceeds a limit, it should follow the company’s escalation rule. That interaction between action, observation and the next decision is a useful way to understand agent behaviour.

Anthropic distinguishes predefined workflows from systems in which a model dynamically directs tool use. The distinction helps describe architecture; it does not make one approach inherently better for every business task.

Access is different from permission to act

A system may be able to read supplier prices without being allowed to change bank details. It may draft an order but require approval before submission. These boundaries should exist in the connected software and credentials, rather than rely solely on an instruction in the conversation.

For the paper order, sensible controls might limit the agent to approved suppliers, a specified product category and a maximum value. A human could review the supplier, quantity, total and delivery date before the final order is sent. The example describes a possible design, not a purchasing policy suitable for every organisation.

Giving a system a payment tool introduces another boundary. It needs explicit authority for the particular payment and a reliable way to record the outcome. An agent does not need a crypto wallet to qualify as an agent; a wallet is simply one possible means of executing a transaction.

Our Commentary on AI agents, wallets and enterprise commerce explores the implications when those permissions extend into spending.

External content is evidence, not authority

A supplier’s web page might contain instructions aimed at the system reading it. A malicious document could tell an agent to ignore its spending limit or send account information elsewhere. The system needs to treat that content as untrusted input, rather than a new instruction from the business.

Even harmless data can cause trouble when it is stale or ambiguous. “Available” might mean available for back order, not immediate dispatch. A quoted price might exclude tax or delivery. Good automation checks the fields that determine the decision and surfaces material uncertainty before a consequential action.

More autonomy creates more verification work

An agent can make a sequence of individually plausible decisions that produces the wrong final outcome. Repeated retries can also create duplicate orders if the first request succeeded but its confirmation was lost.

The surrounding system therefore needs records of actions, stable transaction identifiers, limits on retries and a way to stop or hand over. A fixed workflow can be preferable where the process is well understood and consistency matters more than flexible interpretation. Agent discretion is useful when a task genuinely requires adapting to information that arrives along the way.

The hosting and data tools remain dependencies too, as our guide to centralised services behind decentralised applications illustrates in another setting.

To assess an agent demonstration, ask to see an observable business result: the correct order recorded once, within authority, with an audit trail. Fluent conversation can help operate the process; the completed, authorised task is what establishes that the process worked.