Agents

An agent is not a chatbot with a longer memory and it is not a script with better language. It sits between the two: something that reads an incoming request, decides what it means, does something about it, and says what it did.

Four parts make that possible, and the rest of this chapter describes them one at a time.

What is an AI agent?

An AI agent is software that carries out a task on your behalf from start to finish: it notices something needs doing, decides what it means, acts in one of your systems, and reports back. The distinction that matters is between answering and acting. A chatbot answers. An agent acts, and that is why it needs a boundary.

How do AI agents work?

Four parts, and the rest of this page takes them one at a time: a trigger that starts it, rules that decide what it does, tools it is permitted to call, and a boundary that says how far it may go alone.

How do AI agents learn?

Less than the word suggests, and that is deliberate. An agent here does not silently adjust its own behaviour: the rules are written, versioned and changed by people. What accumulates is agentic data, the record of what actually happened, and that feeds the next version of the rules through a decision rather than automatically. An agent that rewrites its own boundary is one nobody can audit.

The trigger

Something has to start an agent. An email arriving, a form being submitted, a record changing status, a scheduled moment. That sounds trivial and it decides a lot: an agent triggered by “any incoming mail” behaves very differently from one triggered by “mail to the invoices address containing an attachment”.

Narrow triggers produce agents that are easy to reason about. Broad triggers produce agents that need to decide whether they should be involved at all, which is a decision they are bad at.

The rules

The rules are the written version of how the work is done today. Not a summary, the actual conditions: what makes a case straightforward, what makes it an exception, what happens in each situation.

This is the part of the build that takes longest and it happens on paper, before any software. Most automation projects that fail, fail here rather than in the technology, because the rules turned out to live in someone’s head and nobody wrote them down before promising a date.

The tools

An agent that can only talk is of limited use. What makes it act is a set of tools it is permitted to call: read a record, update a field, send a message, create a task. Those are described on the agentic tools page.

Every tool is granted explicitly. An agent has no ambient access to anything; it can do exactly what it has been given and nothing beside it.

The boundary

The boundary says which actions the agent performs alone, which it prepares for a person to approve, and which it never touches. It is agreed in writing and signed off before the build starts, and widening it later requires the same.

This is the single most important artefact in an engagement. An agent that may do anything creates checking work instead of removing it, and an agent whose limits are undocumented cannot be audited when something goes wrong. How that gets tested is covered under governance, and where the person sits in the resulting process is under interfaces.

Why one agent per process

The tempting design is one agent that handles everything, because it demos well. It is the wrong shape: its boundary becomes the union of every set of rules, nobody can hold that in their head, and a change to one process risks the others.

One agent per process keeps the boundary readable in one sitting and lets you stop one without stopping the rest. That matters more than it sounds on the Friday afternoon when something goes wrong.