What is an AI agent? (and how it differs from a chatbot)

Everyone says "agent" now. Often it is just a chatbot with a fancier label. Yet the difference is not cosmetic: a chatbot answers, an agent acts. Here is what you need to tell them apart, in plain words, and to decide whether your need actually calls for an agent.

The one-sentence definition

An AI agent is software that takes a goal, decides the steps to reach it, uses tools to perform real actions, then checks the result and corrects itself. A chatbot stops at the first step: it produces text. An agent goes all the way to the action, and it loops until the goal is met or it hands back to a human.

Chatbot or agent: one example, two behaviours

Take an ordinary support request: "cancel order 4837 and refund me". A chatbot explains how to do it, or drafts a polite reply. It touches nothing. An agent finds the order in your system, checks it is still cancellable, triggers the refund, sends the confirmation, and logs everything in the customer record. Same question, two different worlds.

• The chatbot produces an answer. You, or a human agent, then run the actions by hand.
• The agent runs the actions itself, inside your tools, and reports what it did.
• On a support desk the gap is real: a chatbot deflects the FAQ; a well-scoped agent runs support 24/7 with 50% fewer tickets escalated to a human.

The four building blocks: perceive, decide, act, correct

Under the hood, an agent runs a loop of four moves. That loop, not the model itself, is what separates it from a chatbot. The fourth move, self-correction, is the one people underestimate most: a chatbot that gets it wrong hands you a wrong answer and stops, while an agent that gets it wrong can notice and recover. That same loop is what makes an agent harder to frame: a loop that fixes itself needs clear limits, or it wanders.

• Perceive: it reads the request and gathers the context that matters (the customer record, a stock level, the content of a document).
• Decide: it picks the next step, which tool to call, with which parameters.
• Act: it runs the action in a real system and reads back the result.
• Correct: it looks at what happened. If it failed, or the goal is not met, it tries another way instead of stopping.

Tools, and the link with MCP

An agent without tools is a brain with no hands: it reasons but can do nothing. Tools are its connections into your systems: read an order, open a ticket, query a database, send an email. The better described and more reliable the tools, the more useful the agent. This is where the MCP standard comes in: instead of hand-wiring every connection, MCP gives a common plug between the AI and your software. It went from curiosity to standard in under two years, adopted by Anthropic, OpenAI, Google and Microsoft, then handed to the Linux Foundation in late 2025. In practice that means agents that are cheaper to connect and less locked to a single vendor.

One agent, or several orchestrated agents

Most real needs fit a single well-scoped agent on a narrow perimeter. You move to several orchestrated agents when the task splits naturally into distinct jobs: one agent that searches, one that drafts, one that checks, coordinated by a conductor. It is more powerful, but every agent you add is one more source of error and one more cost. My rule: I always start with a single agent, and I only orchestrate when that single agent hits a real wall, not for the elegance of the architecture.

An agent is not a smarter model. It is a model given a loop, tools and the right to act. The whole game is in how tightly you frame those three things.

What an agent still does not do well

• Guarantee zero errors: it still gets things wrong, especially on rare cases. On irreversible actions (a payment, a deletion, a message to a customer) I keep a human in the loop.
• Explain everything by default: it can justify its steps, but full traceability has to be built, it is not free. That is the whole point of measuring an agent in production.
• Hold a fuzzy goal: the vaguer the instruction, the more the agent drifts. It needs a clear target and clear limits.
• Guess your unwritten context: what "everyone knows" inside your company is invisible to it until you hand it over.

Agent or plain workflow: how to decide

Many needs framed as "we need an agent" are better served by a plain workflow: a fixed, predictable sequence of steps with no AI deciding anything. If the path is always the same, a workflow is simpler, cheaper and more reliable. An agent earns its place when the path changes every time and something has to be decided along the way.

• Fixed path, clear rules, few exceptions: that is a workflow. See automate without breaking things.
• Path that changes case by case, lots of judgement, constant exceptions: that is an agent.
• In between: start with the workflow, add AI only where the workflow stalls.

So the agent is never the goal: it is a means, and often not the first one to reach for. The honest starting question is not "how do we build an agent", it is "does this path decide, or does it just run": answer that, and the choice between an agent, a workflow and a better prompt usually makes itself.