What is an AI agent, and how is it different from a chatbot?

An AI agent is a program built around a language model that decides its own next steps and uses tools, such as search, files, or other apps, to get a task done. A chatbot only answers in text. An agent can also act, and that difference is what changes the risk.

TL;DR

• A chatbot talks. An agent talks and then does things.
• An agent works in a loop: think, use a tool, look at the result, repeat.
• More freedom means more can go wrong, so agents need limits, a named identity, and a record of what they did.
• Many tasks do not need an agent at all. A fixed set of steps is cheaper and more predictable.

Definition box. Anthropic, the maker of Claude, draws a useful line in its engineering guide on building 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, maintaining control over how they accomplish tasks." In short, a workflow follows a script that people wrote. An agent writes its own script as it goes.

What does a chatbot do, and where does it stop?

A chatbot takes a message and returns a message. You type a question about a refund policy, and it replies with text. Even if the model behind it is very capable, the chatbot cannot change anything in the outside world. It cannot send an email, delete a file, or change a setting. The worst it can usually do is say something wrong or say something it should not.

That is still a real problem. Wrong answers from a public chatbot can cause real harm to a business. But the harm travels through a person who reads the answer and decides what to do. There is a human between the words and the action.

What makes something an agent?

An agent adds three things to a chatbot.

First, it has tools. A tool is a small action the model is allowed to ask for, such as "search the web," "read this file," "create a calendar event," or "run this command." The model does not do the action itself. It asks, and the software around it carries the request out and hands back the result.

Second, it has a loop. The model reads your goal, picks a tool, looks at what came back, and decides what to do next. It repeats this until it believes the goal is met, or until something stops it. Anthropic notes it is common to include stopping conditions, such as a maximum number of iterations, to keep control.

Third, it has freedom over the path. You say "get me ready for tomorrow's customer call." You do not say which calendar to open or which documents to read. The agent chooses.

How do the two compare side by side?

Note that the labels are not always clean. A product might be a chatbot on the surface and an agent underneath. A good test is simple. Ask, "Can it do anything besides write text?" If yes, treat it as an agent.

Why does the extra freedom matter for security?

Think of a new employee. A receptionist who can only answer questions on the phone has a small blast radius. A receptionist who can also issue refunds, edit the customer database, and send email on the company's behalf has a much bigger one. You would still hire that person, but you would give them a badge, a list of what they may do, and a manager who can check the work.

Agents are the same. The Model Context Protocol (MCP), an open standard for connecting AI applications to outside systems, makes it easy to hand an agent many tools at once. Its own introduction says that using MCP, applications like Claude or ChatGPT can connect to data sources, tools, and workflows, so they can access key information and perform tasks. That is useful. It also means the list of things an agent can touch grows quickly.

Anthropic also warns that the autonomous nature of agents "means higher costs, and the potential for compounding errors." A small mistake in step two can turn into a large one by step ten, because the agent keeps building on what it did before.

Worked example: a refund request, three ways

The numbers below are invented to show the idea. They are not data from any real company.

Suppose a store gets 200 refund questions a week.

1. As a chatbot. It answers "What is your refund policy?" in text. Customers still click a form to ask for a refund. Staff process the form. Nothing is automated, and nothing can go wrong in the systems.
2. As a workflow. A script checks the order number, confirms it is under 30 days old, and issues the refund if the amount is under 50 dollars. Every step was written by a person. If the script is wrong, the mistake is the same every time, which makes it easy to find.
3. As an agent. The model reads the customer message, looks up the order, decides whether the case is normal, may email the warehouse, may offer a coupon, and may issue the refund. It handles odd cases the script never covered. It might also be talked into a refund it should not issue by a cleverly worded message.

If 190 of the 200 weekly cases are plain, the workflow handles them cheaply and safely. The agent is worth considering only for the odd 10, and even then with a cap on the refund amount and a person approving large ones.

What should you ask before you let an agent act?

Use these steps as a starting checklist.

1. List the tools. Write down every action the agent can take. If you cannot list them, you cannot control them.
2. Cut to the minimum. Remove any tool the task does not need. OWASP, the security community that publishes the Top 10 for LLM applications, names excessive functionality, excessive permissions, and excessive autonomy as the usual root causes of damaging actions.
3. Give it its own identity. The agent should sign in as itself, not as a shared account or as you, so its actions can be told apart.
4. Add a person for big actions. Anything that spends money, deletes data, or sends messages outside the company should wait for a human yes.
5. Keep a record. Log each tool call, what went in, and what came back.
6. Start small. Test in a sandbox first, as Anthropic recommends.

For deeper reading on each step, see what is excessive agency in an AI coding agent and how much access should a coding agent have. If you are comparing approaches, prompt rules versus deterministic controls explains why a written instruction alone is not a safety limit.

Where does Safeguard fit?

Safeguard helps teams see and govern the agents they already have. It offers agent identity, which tracks which agent holds what access and at what level, and MCP Guardrail, which governs the traffic between agents and MCP servers. Safeguard's asset discovery can help find agents and MCP servers that people set up without telling anyone. The Safeguard CLI can also write code, so the same thinking about limits and records applies to work done there. You can try the free scan at gold.safeguard.sh/scan.

Try it yourself

Open the demo and watch an assistant connect to a security tool and answer questions about real findings. Notice that it is the tool connection, not the chat window, that lets it work with live data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Building effective agents (Anthropic)
• What is the Model Context Protocol (MCP)?
• OWASP LLM06 Excessive Agency

Last reviewed: 19 October 2026.