What is an AI agent?

“Agent” might be the most overused word in AI right now. Every product seems to have one, and it is often hard to tell whether that means something genuinely new or just a chatbot with a new name. The difference matters, because a real agent can take actions in your systems, and that brings both much bigger opportunities and much bigger risks.

In this post I’ll explain what an AI agent actually is, how it differs from a chatbot, the simple loop that sits underneath almost every agent, and the questions I’d ask before letting one loose on anything important.

From answering to acting

The idea of an “agent” is much older than today’s chatbots. The standard AI textbook, Russell and Norvig’s Artificial Intelligence: A Modern Approach, frames the whole field around agents: an agent is anything that can be viewed as perceiving its environment and acting upon that environment.^[1] A thermostat is a very simple agent. A self-driving car is a very complicated one.

When people talk about AI agents today, they usually mean a large language model that has been given the ability to do things, not just write things. Here is the difference in practice:

Tools: how a language model gets hands

On its own, a language model can only produce text. What turns it into an agent is tools — connections to other software that it can call. A tool might be a search engine, a calculator, your CRM, a calendar, a database query or an email system. The model writes a structured request (“call the calendar tool with these details”), the surrounding software runs it, and the result is fed back to the model.

Researchers showed early on why this matters. The 2023 Toolformer paper pointed out a paradox: language models can solve impressive new tasks, yet struggle with basic things like arithmetic or looking up facts, where much simpler tools excel. Teaching a model to decide when to call tools such as a calculator, a search engine, a translation system and a calendar substantially improved its performance.^[3]

Connecting models to tools used to require custom work for every single integration. That is changing. The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems such as files, databases and tools — its own documentation describes it as a kind of USB-C port for AI applications.^[5] For businesses, standards like this make it much easier to plug an agent into the systems you already use.

The agent loop

Almost every agent, however sophisticated, runs some version of the same loop:

1. Goal — it receives a task, such as “find last quarter’s overdue invoices and draft reminder emails”.
2. Think — it works out what to do next.
3. Act — it calls a tool, such as a query against the accounting system.
4. Observe — it reads the result.
5. Repeat — it decides the next step, until the goal is met or it needs help.

This pattern was described in an influential 2022 paper called ReAct, short for “reasoning and acting”. The authors showed that letting a model alternate between writing out its reasoning and taking actions — like looking something up — worked better than doing either alone, and that the reasoning steps also made the model’s behaviour easier for humans to interpret.^[2]

Workflows vs agents: start simple

One of the most useful distinctions I’ve come across is from Anthropic’s guide Building effective agents. It separates two kinds of system:^[4]

• Workflows — the AI and tools follow predefined code paths. A developer has decided the steps in advance: first classify the email, then look up the customer, then draft a reply.
• Agents — the model dynamically directs its own process and tool use, deciding which steps to take and in what order.

The same guide recommends finding the simplest solution possible and only adding complexity when it is needed.^[4] I strongly agree. A lot of what gets marketed as an “agent” is better built as a workflow: it is more predictable, cheaper to run and far easier to test. Save true agents for open-ended tasks where you genuinely can’t map out the steps in advance.

The risks, and keeping a human in the loop

When a chatbot gets something wrong, you get a bad paragraph. When an agent gets something wrong, it might send the wrong email, update the wrong record or approve the wrong payment. Everything I covered earlier in this series about hallucinations still applies — the difference is that mistakes now turn into actions.

The practical safeguards I recommend:

• Least privilege. Give the agent access only to the tools and data it truly needs. Read-only access where possible.
• Approval checkpoints. Require a human to confirm anything irreversible or external — payments, emails to customers, deletions. Anthropic’s guide notes that agents can pause for human feedback at checkpoints or when they hit blockers.^[4]
• Limits. Cap the number of steps, the time and the spend for each task.
• Logs. Record every action so you can see what happened and why.

What I want you to take away

1. An agent acts; a chatbot answers. The defining feature is that the AI takes actions in real systems.
2. Tools give language models hands. Search, calculators, calendars and business systems are what make agents useful, and standards like MCP make connecting them easier.
3. Underneath, it is a simple loop. Goal, think, act, observe, repeat.
4. Prefer workflows when the steps are known. Use true agents only for genuinely open-ended tasks.
5. Mistakes become actions. Limit access, add human approval for anything that matters, and log everything.