“Agent” is the most abused word in enterprise software right now. Gartner found that of thousands of vendors selling AI agents, only about 130 are verifiably agentic. Here is the difference, why it matters commercially, and a test you can apply in any demo.
There is a moment in a lot of software demos this year. The presenter types a question into a chat window, the product answers fluently, and the slide behind them says Agent. Everyone nods. And nothing, anywhere, has actually happened: no record changed, no email sent, no process moved one step forward.
That is a chatbot. It may be an excellent chatbot. It is not an agent, and the difference is not pedantry; it is the difference between a product that answers questions about work and a product that does work.
The industry has a name for this: agent washing, the rebranding of chatbots, workflow automations, and plain RPA as “AI agents” because the word commands premium pricing and executive attention. The scale of it is remarkable. Gartner examined the thousands of vendors marketing AI agents and found only around 130 whose products are verifiably agentic by any meaningful architectural standard.
So it is worth being precise. A chatbot is a system that reads and replies. Even a brilliant, model-powered one is reactive: text in, text out, human does the work. An agent is a system that pursues a goal: it reads the situation, decides what to do next, takes an action through a tool or another system, observes what happened, and decides again, looping until the goal is met or it escalates. The language model is one component inside that loop, not the loop itself.
Which yields a test you can apply in any demo, and we encourage clients to use it rudely: ask what the product just changed. If the answer is “it drafted text a human will act on,” you are looking at an assistant. If it processed the refund, created the work order, updated the record, booked the slot, or, just as importantly, declined to and told you why, you are looking at an agent.
The confusion is especially thick for Microsoft shops, because the word Copilot now spans the whole spectrum.
Microsoft 365 Copilot in Word or Teams is an assistant: superb at drafting, summarizing, and finding, and everything it produces waits for a human. A Copilot Studio bot built from topics and knowledge sources is a chatbot: it answers your staff's questions about the policy manual, which has genuine value, and does nothing. A Copilot Studio agent is different in kind, not degree: it has actions. Through connectors it can read the record in Dataverse or SQL, apply logic, call the workflow, write the result, and post the confirmation, triggered by a schedule or an event rather than only by someone typing at it.
Same product family, same chat surface in the demo, radically different things. When someone shows you “a Copilot agent,” the demo looks identical for the first two minutes. The test is the third minute.
Getting this wrong costs money in both directions.
Call a chatbot an agent, and you buy question-answering while budgeting for headcount-level work reduction. The ROI never arrives, and the disappointment gets blamed on “AI” rather than on the category error. Gartner expects a large share of agentic AI projects to be cancelled within a couple of years for exactly this kind of mismatch between promise and architecture.
But treat a real agent like a chatbot, and you miss the risk. A chatbot's worst failure is a wrong answer a human can ignore. An agent's worst failure happens in the real world: the wrong record updated, the wrong email sent, at machine speed. An agent is not a chat feature; it is an actor inside your systems, and it needs what any actor needs: narrowly scoped permissions, approval gates on consequential actions, complete logging of what it did and why, and testing against the cases where it should refuse to act. If a vendor selling you an “agent” cannot show you its audit log and its permission model, apply the test again, because either it is a chatbot, or it is an agent you should not deploy.
The pattern that works is unglamorous: pick one process with a clear goal, bounded actions, and an obvious escalation path. Give the agent the narrowest permissions that let it succeed. Put a human approval on anything irreversible, and loosen the gates as the logs earn trust. That first agent teaches your organization more than any vendor briefing, including whether the vendor's definition of “agent” survives contact with your test.
Building agents that act inside governed Microsoft environments, with the permissions, gates, and logs to deserve it, is what we do. If you are being sold an agent and want to know which kind it is, talk to us.
Working through something like this? We talk shop without a pitch. Bring the problem and we will bring what we have learned in the field.
