What an AI agent really is

For a few years now, the word “agent” has been stuck on almost anything that touches a language model: an assistant that drafts emails, a support bot, a script that calls an API. Marketing keeps the confusion alive, and it makes a serious discussion harder, both about what these systems can do and about what they should not be allowed to do.

Here is a deliberately dry working definition. An agent is a program that repeats a loop: a language model decides the next action, a tool runs it, the result is handed back to the model, and the cycle starts again until the task is done or a limit is hit. Everything else, memory, planning, “teams of agents”, is organisation built around that loop.

How it differs from a plain chatbot

A chatbot receives a question and produces text. It changes nothing in the world: if the answer is wrong, the user reads it, fixes it or ignores it. An agent produces actions. It reads a file, queries a database, sends an HTTP request, edits a draft. Text is no longer the end product, it is a way of choosing the next action.

That changes the nature of the risk. A wording mistake in a chatbot is an annoyance. A wrong action by an agent can delete a page, send a message to the wrong person or start an expensive job. This is why the interesting part of an agent is not the model, it is what you decided to let it do.

The four beats of the loop

Every turn follows the same pattern, whatever framework you use.

1. Observe. The model receives a context: the initial instruction, the history of earlier actions and the list of available tools, each described by a name, an explanation and a parameter schema.
2. Decide. The model answers either with a final text or with a request to call a tool, with structured arguments.
3. Act. The program hosting the agent, not the model, runs the requested tool. The model only phrases the request.
4. Check. The tool’s result, errors included, is appended to the context. The program decides whether to stop: task finished, turn limit exceeded, budget spent.

This split has an important consequence: the model never holds any direct power. It can only act through the tools the program has plugged in, and only when the program agrees to run them. The whole security of an agent is decided in that gap between the model’s request and the execution.

The model proposes, the program disposes.

Tools: functions described with care

A tool is an ordinary function: “search the articles”, “read a page”, “create a draft”. What matters is its description. The model does not see the code, only a name, a sentence of explanation and the shape of the parameters. A badly described tool gets badly used, just like a badly documented API.

A few habits that save a lot of grief:

• Few tools, well named. The longer the list, the more the model hesitates or picks the wrong one.
• Strict parameters. An identifier, an enumeration, a date: the program validates the arguments before running anything, as it would for a public form.
• Short, readable results. Returning ten thousand lines of log fills the context and drowns the useful part.
• Explicit errors. A message saying what failed and what to try next helps the model correct itself on the following turn.

Context is the memory

A model remembers nothing from one call to the next. What we call an agent’s memory is simply the text sent back on every turn. That text is bounded by the size of the context window, and the longer it gets, the more cost and latency go up.

So context is managed like a resource: old steps get summarised, useful facts are kept in an external store the agent can query when needed, and whole documents are not dumped into it. An agent that “forgets” what it did twenty turns ago is not buggy, it has simply lost those lines from its context.

Permissions: what an agent may do

The base rule is least privilege, applied to a new actor we do not fully understand. An agent does not have to inherit the rights of the person who starts it. It gets an explicit, narrower set of permissions, and the program checks every call before running it.

Two points are worth settling at design time. First, the check lives in the host program, not in the tool and even less in the prompt: writing “never delete anything” in a prompt is not a permission, it is a wish. Second, read tools, which have no consequences, are kept apart from write tools, each of which has to be justified.

The guardrails that make the difference

A reliable agent in production is not the one with the cleverest model, it is the one whose limits are best enforced. Here is what you find in systems that hold up over time.

• A ceiling on turns, duration and cost. A loop that never stops always ends up running, usually on a Friday evening.
• A log of every action, with arguments, result and the agent’s identity, so you can understand afterwards what happened.
• The ability to undo. A tool that changes something should know how to revert its change, or be clearly marked as irreversible.
• Human approval for serious side effects. Publishing, deleting, spending, writing to a third party: the agent prepares, a person confirms.
• Explicit autonomy levels. Report only, propose, or act: the level is a setting chosen by a human, not a property of the model.

That is the choice I made in Cogenta, the CMS I build: agents go through the same tools, declared with their permissions, as any other integration, and the ones with side effects are logged and reversible. There is nothing original in it, it is hygiene.

Why it fails, in practice

Agent failures have mundane causes. A misreading at step two spreads to the following steps: over a long chain, even a small error rate per step ends up giving an unreliable result. An ambiguous tool result is read the wrong way. The context fills with noise and the model loses the thread. Or, more insidiously, the agent technically succeeds at a task that was not the one you wanted, for lack of a precise description of the expected outcome.

The remedy is not a bigger model, or not only that. It is shorter chains, results verified by code rather than by the same model, and a clean stop when something falls outside the frame.

When an agent is the right tool

If the steps of a task are known in advance, a classic pipeline, possibly with a model call at one precise spot, is almost always simpler, faster and more predictable. Letting a model pick its own path pays off when the path depends on what you discover along the way: investigating an anomaly, gathering scattered information, fixing a problem whose cause is unknown.

The useful question is therefore not “can we make this an agent?” but “what do we gain by letting the model decide, and what do we risk?”. If the answer to the second half is “not much, and everything is reversible”, go ahead. Otherwise start with an assistant that proposes, and watch what it proposes for a few weeks before entrusting it with anything.