A chatbot can explain how to update a spreadsheet. An agent may open the spreadsheet, find the relevant rows, make changes and check the result. The practical difference is what the software is allowed to do after producing an answer.
There is no universally enforced product label. A chat window can contain an agent, and something sold as an agent may follow a fixed sequence. To understand the product, follow one task from the request to the final action.
Who chooses the next step?
In Anthropic’s guide to building agents, a workflow follows predefined paths, while an agent dynamically directs its process and tool use. Both can involve language models. Both can retrieve documents or call an API.
Consider a support request. A fixed workflow might identify the order number, look up a shipment and draft a reply. It follows the same stages every time. An agent could decide that the shipment record is incomplete, inspect another system, compare the results and ask the customer a clarifying question.
That flexibility is useful when the next step genuinely depends on what the software discovers. It also creates more possible ways for a run to fail. The software might use the wrong record, keep searching after it has enough information or misunderstand a tool’s response.
Tools turn a conversation into an operation
The model itself does not acquire account access by sounding confident. The surrounding application supplies tools and permissions. A read-only search tool has different consequences from a tool that sends email, changes a price or deletes a file.
A useful product description should explain the boundaries. Which accounts can it reach? Can it read everything or only selected folders? Does a proposed change need approval? Can you inspect the action before it happens?
Imagine an assistant preparing an invoice. Reading a customer record, calculating a draft and issuing the invoice are three separate permissions. A system can automate the first two while asking you to approve the third. Calling the whole process autonomous tells you less than knowing where those boundaries sit.
Access also extends to data the agent encounters. A retrieved page or uploaded document can contain instructions that conflict with your request. The application needs to treat those words as content, rather than allowing an arbitrary document to redefine its permissions.
A finished answer is not proof of a finished task
A chatbot can be evaluated by reading its answer. An agent needs additional checks against the state of the system it changed.
If it says it updated ten records, inspect the records. If it says it ran tests, look for the actual result. If a tool failed halfway through, find out whether earlier changes remain. A polished summary can hide an incomplete operation.
Useful records include the inputs to consequential actions, their results and the final state. They need not expose private reasoning. For a user, the important evidence is whether the intended operation happened, on the intended objects, with the intended outcome.
Repeated runs matter too. A task that succeeds once may fail when a search result changes or a service responds slowly. Our guide to testing an AI tool describes a small evaluation set you can build before handing over recurring work.
More steps can mean more cost
An agent can make several model calls, run searches and use paid tools during one task. A cheap individual request can therefore become an expensive completed job. Retries and human review belong in that calculation.
Set a stopping condition that is visible to the user: a maximum spend, a maximum number of actions or a request for help when evidence is insufficient. A system that knows when to stop is often more useful than one that keeps attempting a task indefinitely.
Start with a narrow job whose result you can check. Expanding permissions is easier to justify after you have observed reliable behavior on that job.
