If a vendor says they have built you an agent, they usually have not. They have built a chat box, or a sequence of steps with a model sitting in one of them. Both can be useful. Neither is an agent.
The word got loose. Chat products, Zapier-style automations, and fully autonomous loops all arrived under the same label. The useful question is not which model sits inside. It is who decides what happens next, once the thing is running.
If a person, or a piece of code you wrote, picks the next step, you have a chatbot or a workflow. If the model picks the next step, and can keep picking, you have an agent. Most small teams do not need the model to hold the wheel.
Three machines under one word
A chatbot answers. You type, it replies, the turn ends. It might call a tool, but it is still a conversation. Nothing moves in your business unless a person copies the answer somewhere else.
A workflow is a path you designed in advance. A language model can sit in the middle: classify an email, extract a field, draft a reply. The path itself does not change at runtime. You already decided what happens if the answer is yes, and what happens if it is no.
An agent is different. The model holds the wheel. It chooses which tool to call, reads the result, decides whether to call another, and keeps going until it thinks the job is done. You gave it a goal and a set of tools. It writes the path as it goes.
Take an inbox. Summarise the unread mail: chatbot. Tag it as invoice or query, file it, put a draft in front of you: workflow. Read the inbox, decide what needs action, search the CRM, draft, perhaps send, and stop when it believes it is finished: agent. You never specified that sequence. That is the point, and also the risk.
Anthropic drew the line in December 2024, in Building effective agents. Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents are systems where LLMs dynamically direct their own processes and tool usage. We use that distinction. Everything else is a sales page.
The three shapes fail differently. A wrong chatbot is a bad answer on a screen. A wrong workflow is a bad step in a known sequence. A wrong agent can take a path you never reviewed, spend tokens you did not budget, and leave a trail that is hard to reconstruct.
The shape that actually shipped
Through 2025 and into 2026, the production lesson was not subtle. Fully autonomous agents looked good in demos. Workflows got into production.
The common shipped shape is an agentic workflow: a fixed path, with one or two places where the model chooses a branch. Classify this request, then follow the rule for that class. Draft this reply, then a person sends it. The model does the messy bit. The code does the rest. That is the version that holds up: you can test it, bound what it costs, and point at the step that broke.
A model that classifies, then a rule that acts, is enough for most of the work people bring us. If you are the person who signs, and there is no IT seat watching this thing, that is the shape you can live with.
We have been running the other end internally: agent-as-teammate experiments, Block and Goose style. Useful for us. We would not move a client onto that yet. The failures compound, and they are harder to see than a workflow that skipped a step.
This is also why so many things sold as agents in artificial intelligence disappoint after the pilot. The buyer was promised a colleague. They received a sequence with a model in the middle. Calling it an agent set the wrong expectation.
When the model should hold the wheel
Sometimes it should. Both parts of this test have to be true.
The number of steps cannot be known in advance. Not "there are a few branches". Cannot be known. Research that might take three lookups or thirty. A coding task that might touch one file or twelve.
And being wrong has to be cheap enough to catch. A draft nobody sends until a person reads it. A search you can re-run. A sandbox you can reset. If the model can email a client, book something, or write to a live system, being wrong is not cheap, and the model should not choose the next step.
If either part fails, stay on a workflow. Keep a person on the exceptions.
decision://who-picks-the-next-step
is this a conversation that ends on a screen?
yes -> chatbot
is the path drawn in code, with a model on one messy step?
yes -> workflow
does the model choose the tools and the order at runtime?
yes -> only if both hold:
number of steps cannot be known in advance
being wrong is cheap enough to catch
otherwise -> workflow, person on the exceptions
Agents cost more, take longer to get stable, and fail in ways that hide. Scaffolding is the work: logs of which tool it called, a stop condition (turns, budget, wall clock), and a named owner who gets the alert when it stalls. None of that is the model. All of it is what decides whether you can keep the system.
An agent without a stop condition is not finished, however good the demo was.
What to do first
Before you buy, or build, anything labelled an agent, write down who picks the next step at runtime.
If the answer is you, or a rule you can point at, you want a chatbot or a workflow. Build the smallest one that removes the friction. Put the model on the one messy step. Leave the rest as code. Keep a person on the exceptions.
If the answer is the model, and you can defend both parts of the test, then build an agent. Still start small. One goal, a short tool list, a hard stop, a person watching the first weeks, and a log you actually read.
We start there with every team that comes in asking about agents in artificial intelligence. Most of the time the useful system is a model that classifies and a rule that acts. That is allowed to be the answer. The interesting work is usually not giving the model the wheel. It is deciding, on purpose, when it should not have it.
