Ask a chatbot to help with an overdue invoice and it may write a persuasive reminder. Give an agent access to your billing system and email, and it might find the invoice, check whether it was paid and prepare that reminder itself. The language model can be similar. The surrounding software, permissions and feedback loop change the job.
“Agent” is used loosely, so a product label tells you less than a demonstration. The useful questions are whether the system can act, how it chooses its next step and where you can inspect or interrupt it.
From an answer to a sequence of actions
A basic chat interaction takes your message and produces a response. An agentic system can also call tools: search a database, read a document, edit a file or ask another service to do something. A tool result returns to the model, which can decide whether the task is finished or another step is needed.
Imagine asking for a report on unpaid invoices. The first database query might reveal inconsistent customer names. An agent could inspect those records, reconcile them and run the query again before writing the report. That adjustment is more useful than a fluent answer based on the first incomplete result.
It also creates more places for error. The model may misunderstand the request, choose the wrong tool or interpret a successful tool response as proof that the business objective was achieved.
A workflow can look like an agent
Some systems follow a fixed route: retrieve records, summarize them, format a document. Others let the model choose the route as it proceeds. Anthropic’s engineering guide distinguishes these predefined workflows from agents that dynamically direct their own tool use.
Neither design is inherently better. A fixed workflow is attractive when the steps are well understood and failures need to be predictable. A flexible agent can help when the next step depends on information discovered during the task.
For an invoice reminder, a workflow may be enough. For investigating why a customer’s payments keep being misallocated, the system may need more freedom to inspect evidence. A product can combine both: an agent investigates, while a deterministic payment service enforces the rules for any financial change.
Tools define the practical boundary
A model that describes a spreadsheet formula has not edited your workbook. An agent needs an actual connection to the workbook and a tool capable of making the change. The same distinction applies to sending messages, scheduling appointments and moving money.
That connection should have a clear scope. Reading a calendar, drafting an event and inviting attendees are separate capabilities. A product may put them behind one friendly interface, but their consequences differ.
When evaluating an agent, look for the boundary between preparation and commitment. Can it produce a draft you can review? Does it ask before an action with external consequences? Can permissions be narrowed to the files or services required for the task?
Memory is not the same as reliable state
A long conversation can help the model remember what you want, but it is a poor substitute for checking current records. An invoice described as unpaid yesterday may have been paid this morning.
Reliable systems use durable records for facts that can change. They track task status, save completed work and avoid repeating an action after a timeout. An agent that retries a read is usually inconvenient; one that retries a payment without checking the result can create a real problem.
A useful activity history should show what was requested, what tools ran and what changed. A polished final message cannot establish those facts on its own.
Autonomy has a cost
Each extra step can add model usage, tool charges and waiting time. A task that looks small in the chat box may involve many searches or repeated attempts. Anthropic’s guide explicitly describes the tradeoff between agent flexibility, latency and cost.
That makes the right test fairly ordinary: choose several representative tasks, define what success looks like and compare the result with the way you work now. Include an awkward case with missing information, a failed connection and a task that should stop for review.
For the invoice example, success means the correct invoice was identified and the right reminder was prepared or sent with authorization. Counting tool calls or reading an impressive explanation is less useful.
The change from chatbot to agent is therefore a change in responsibility. Once software can act on your behalf, the quality of its permissions, state management and evidence matters as much as the quality of its sentences.
