What is an AI agent? A plain definition, and the three things that make one safe to run

An AI agent is software that takes a goal, works out the steps itself, and uses tools to carry them out. You give it a job, for example "check this invoice against the purchase order and flag anything that does not match". It chooses the order of the steps, calls the systems it needs, and reports back. That is what makes it an agent and not a script: a script has its steps written in advance by a developer, and an agent picks them while it runs.

The definition is short on purpose, so that a manager can repeat it in a meeting. The rest of this page covers what an agent is made of, where agents go wrong, and the three things that make one safe to run.

These four words get used for each other. One test sorts them: who decides the next step?

	Who decides the steps	What it can touch	Best at
Chatbot or assistant	You do, one message at a time	The conversation	Answering questions, drafting text
Automation script	A developer, written in advance	Only what the developer coded	Doing the same task the same way
Workflow tool	A person draws the steps once, the tool repeats them	The apps you connect to it	High volume "when this, then that"
AI agent	A model, while the job runs	The tools you allow it to use	Work where the steps change per case

Two notes. First, the categories mix in practice: a workflow tool can include an agent step, and an agent can be told to follow a fixed sequence. If you are comparing self-hosted workflow tools, we cover those in our post on self-hosted n8n alternatives. Second, "the model decides" is both the point and the risk: an agent handles cases nobody planned for, and it can also pick a step you would not have picked.

Four parts. If you cannot see all four, you are looking at something else.

• A model. The language model that reads the situation and picks the next step. It is replaceable: the same agent can run on a different model.
• Tools. Functions the agent may call: read a file, query a database, send an email, open a ticket. Tools are how an agent changes anything. Without them it can only talk.
• Memory and knowledge. What the agent can look at: your documents, the state of the current job, and earlier runs. This is what makes the output specific to your organisation.
• A runtime. The software that runs the agent: it holds the loop, calls the model, executes the tools, keeps the record, and stops the agent when it should stop. People discuss the first three and buy the fourth.

The line that separates an agent from everything else is the same in every serious definition: in a workflow the path is fixed in code before it runs, and in an agent the model directs the path while it runs.

Three failures come up again and again. None of them is a model problem.

The model's output is not the record. A model writes text that reads like a report of what it did. That is not evidence. The record has to come from the runtime: which tool ran, with what input, and what came back.

The human read moves. Teams start with a person checking every result. The agent is right most of the time, checking gets dull, and the check quietly stops. Nothing fails and nothing warns you: the control you designed is gone while the process looks unchanged on paper.

Tools reach real systems. An agent with a database tool can write to the database. The expensive mistake is rarely the model saying something wrong, it is a tool doing something real. Every tool you switch on widens what one wrong step can reach.

Safe here has a plain meaning: you can run the agent where mistakes cost money, and explain it afterwards to an auditor.

1. A record of every run. The runtime writes it, not the model. Keep the steps, the inputs, the outputs and the times, keep them as long as your own rules say, and be able to export them into your own systems. That is the difference between a claim and evidence.

2. A permission boundary on tools. Decide what each agent may call before it runs, not after something goes wrong. Give it the smallest set of tools that does the job, and give each tool its own limits: which folder, which account, which records. Start from nothing allowed.

3. A pause on the steps that are expensive to get wrong. Choose those steps by what a mistake costs, not by how often the step happens. Reading a document is cheap to get wrong; sending a payment instruction or a message to a customer is not. A pause you build in is more reliable than a review you hope people keep doing.

Those three answer what an auditor or a risk owner will ask: what did it do, what was it allowed to do, and who approved the parts that mattered.

An agent reads your documents, holds your credentials and touches your systems. So the deployment question comes with the technology: whose infrastructure it runs on, which model it calls, and who holds the record afterwards. If the record lives in a vendor's cloud, your account of what happened depends on that vendor. If you run the agent in your own environment, the three things above are yours to hold. We cover that side in what is sovereign AI.