The short answer: a chatbot answers, an assistant answers and drafts, an automation changes things along a path somebody drew, and an agent changes things along a path it picks itself. The two questions that place any product are can it change anything outside the conversation, and who decided the steps. How fluent it sounds is not one of them, which is why the marketing rarely leads with either.
Most comparisons of these words rank them by sophistication, as though an agent were a better chatbot. That framing is wrong in a way that costs money: an automation and an agent sit on opposite sides of the second question, and choosing between them is a real decision about how much unpredictability you want in exchange for handling cases you did not anticipate.
The two questions
Question one: can it write, or only read? A system that reads your data and produces text is a fundamentally different risk from one that creates a record, sends a message or moves money. Everything on the reading side fails by being unhelpful. Everything on the writing side fails by doing something you then have to undo. This is the single largest jump in the whole category and it is almost never the thing being advertised.
Question two: who decided the steps? This is the line Anthropic's engineering team draws between two kinds of system, and it is the most useful sentence written about this. It describes workflows and agents as follows: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." A workflow does what you configured. An agent decides.
Put the two together and the four words land in four different places.
| Can it change things? | Who decided the steps? | |
|---|---|---|
| Chatbot | No, it replies | The path is scripted or there is no path |
| Assistant | It drafts, you act | You do, one request at a time |
| Automation | Yes | You did, in advance, in a builder |
| Agent | Yes | It does, per situation |
What each one is actually good at
A chatbot is the right answer far more often than its reputation suggests. If the job is answering the same forty questions from a knowledge base, a system that cannot change anything is not a limitation, it is the safety property. Nothing it does needs reviewing because it did not do anything.
An assistant is a force multiplier on one person. It reads the thread and drafts the reply, and you decide whether that reply is sent. The work does not leave your desk, it just gets faster to do. This is the category most "AI executive assistant" products are in, and it is the reason people who wanted the work taken off their desk are often disappointed by one.
An automation is the right answer whenever the path is genuinely known. If the steps are the same every time, encoding them is cheaper, faster and more predictable than paying a model to rediscover them on each run. Google Cloud's own framing of the category is useful here, because it defines AI agents as systems that "show reasoning, planning, and memory and have a level of autonomy to make decisions, learn, and adapt". If the work needs none of that, you are buying reasoning you do not need and inheriting its failure modes for nothing.
An agent earns its unpredictability only where the path varies. The case for one is not that it is more advanced, it is that the situations are too varied to enumerate in a builder, and the cost of that is that it will sometimes do something you did not picture. A ten-step process that is 95% reliable per step is not 95% reliable overall, and an agent is precisely the shape that accumulates that error while sounding confident about it.
The trap in the middle
The expensive mistake is buying an agent for work an automation would have done. It is expensive twice: you pay for reasoning on every run that a configured path would have handled for free, and you take on a system that can surprise you in exchange for flexibility the work never needed.
The reverse mistake is cheaper but more common. Teams buy an automation platform for work whose shape varies, spend weeks building branches for cases they keep discovering, and end up maintaining a decision tree that a model would have handled. The tell is that the builder keeps growing and nobody can say when it will be finished.
A rough test: write down the last ten instances of the work. If you can describe all ten with one path and a couple of branches, that is an automation. If describing them needs ten descriptions, no builder is going to save you.
Where a hire sits
Sanaf is on the writing side of question one and the agent side of question two: it takes actions in the apps a business already runs, and it works out the steps rather than following a flow somebody drew. That is the shape that handles varied work, and it is also the shape with the failure modes above, so the interesting part is not the category but what happens at the edges of it.
Three things are doing that work. It starts in shadow mode and drafts rather than sends, so the first week is reviewable before anything leaves. Approvals are set per kind of action rather than per step somebody remembered to add, which means the rule survives the model choosing a path nobody predicted. And everything it did is on a record afterwards, so a surprise is something you can read rather than something you reconstruct.
That is the honest version of the trade. An agent is the right tool when the work varies, and the things worth comparing are not how it is described but what it does before it acts and what it leaves behind afterwards.