"Agent" now describes everything from a customer service chatbot to a system that opens pull requests unsupervised. When a word covers that much ground it has stopped carrying information, and you cannot evaluate a claim made with it.
There is a real distinction underneath. It is worth having, because it predicts what a thing can do and what it will cost you when it is wrong.
Three things, in increasing order of what they can break
A chatbot takes your text and returns text. That is the whole loop. It cannot affect anything. Being wrong costs you a bad answer you can see.
A workflow is a fixed sequence with a model inside it. Read the mail, summarize it, put the summary in the sheet. A person decided the steps and their order in advance; the model does one job at one point. This is most useful automation, and it is not an agent however it is marketed.
An agent decides its own steps. Given a goal and a set of tools, it chooses what to do next, does it, looks at the result, and chooses again, looping until it decides it is done.
The line is not intelligence, autonomy or how impressive the demo is. It is one question: who chose the order of the steps? If a person did, it is a workflow. If the model does, at runtime, it is an agent.
That definition is unglamorous and it does real work. It tells you exactly which claims to be suspicious of, because most things sold as agents are workflows, and the ones that genuinely are agents are riskier than their marketing admits.
Why tools change everything
An agent is a model plus tools: functions it can call. Search the web. Read a file. Send a request. Run a command.
The moment you add the first one, three things change at once, and they compound.
Its mistakes leave the chat. A wrong answer becomes a wrong action. Text you can ignore; a sent mail, a deleted row and a spent dollar you cannot. Everything you already knew about confident wrong answers now applies to things that happen rather than things that are said.
Errors compound instead of ending. A chatbot's mistake is one bad reply. An agent's mistake at step three is the input to steps four through twenty, and because each step's output conditions the next, a small early error can be elaborated into a confidently wrong sequence. It does not notice, because nothing in the loop is checking against the world.
Untrusted text becomes instructions. This is the one people underestimate, and it is the genuinely hard problem. If your agent reads a web page, that page is now in its context, and the model does not have a reliable boundary between "content I was asked to read" and "instructions I should follow". A page can contain text addressed to your agent. So can an email it reads, a document it opens, a code comment.
The practical consequence: an agent's permissions are its blast radius. An agent with read-only access to your calendar and one with your credentials are not the same product with different settings; they are different risk categories.
Where they reliably fall over
Consistently, across tools, in ways worth expecting:
Long horizons. Performance degrades as the number of steps grows. Twenty steps is not twice as hard as ten; the chance of at least one derailment accumulates, and there is usually nothing pulling it back on track.
Knowing when to stop. Agents overrun. They keep going when the job is done, declare victory when it is not, or loop between two approaches. "Am I finished?" is a genuinely hard judgment and it is one they make about their own work.
Recovering from failure. A tool call fails, and instead of stopping the agent tries a variation, then another. Sometimes that is resourceful. Often it is a slow-motion pileup where each attempt makes less sense than the last.
Accumulated context. A long run fills the window with its own output. Context is everything, and by step thirty a lot of it is the agent's own earlier reasoning, some of which was wrong.
Silent success. The most expensive one: it reports that it finished, and what it produced is subtly not the thing you asked for. Nothing in the loop verifies against reality, so its confidence about completion is as unreliable as its confidence about anything else.
What people do about it
The workarounds in real systems are unglamorous and mostly amount to limiting scope:
- Narrow the tools. Give it four, not forty. Every tool is surface area.
- Cap the loop. A hard limit on steps, time and spend. Not because the limit is correct, but because unbounded is definitely wrong.
- Checkpoint before anything irreversible. Same rule as any automation: the human goes in front of what cannot be undone.
- Make actions reversible where you can. Draft rather than send, branch rather than commit, stage rather than apply. Reversible actions can be autonomous; irreversible ones should not be.
- Verify outside the loop. Something that is not the agent should check the result, because the agent's opinion of its own work is generated by the same process that did the work.
- Prefer a workflow. If you can specify the steps, specify them. Agentic flexibility is a cost you pay for not knowing the sequence in advance, and most tasks do know it.
So are they worth it?
Yes, in a narrow and real band: tasks where the steps genuinely cannot be known in advance, where the actions are reversible or cheap, and where a human sees the result before it matters. Exploratory work, research over many sources, codebase changes that land in a branch a person reviews.
The band is narrower than the marketing and wider than the backlash. What makes it usable is not a better model, it is the scaffolding around it: the limits, the checkpoints, the outside verification.
The short version
If a person fixed the order of the steps, it is a workflow, not an agent, and that is usually the better tool. Adding tools turns wrong answers into wrong actions, makes errors compound, and means any text it reads can address it. Expect failure on long horizons, on stopping, on recovery, and expect confident reports of success. Narrow the tools, cap the loop, keep actions reversible, and verify from outside.