In August I ran an internal session for engineers with the title “What makes an agent, an agent?” The slide after the title said that it was a safe space not to know, and I meant it. The word is used so loosely at the moment that people who build these systems for a living will give you different answers, and people who buy them are often not sure which answer they have bought. This post is the written version of that session, minus the questions from the room, which were the best part.
I started with the model rather than the agent, because most of the confusion comes from treating the two as the same thing.
A brain in a jar
A large language model is a file. On my laptop there is a Qwen model that takes up a few gigabytes on disk and runs through Ollama, and when I ask it something the fans spin up, the processor climbs past ninety degrees, and a while later some text appears. Nothing leaves the machine. Nothing arrives at it either, and that second point is the one to hold on to.
The model knows what it was shown during training, up to a date, and after that date it knows nothing at all. If you drew its knowledge against time you would get a line rising to the cut-off and then running flat, and everything to the right of the cut-off is a gap that the model cannot see. It has no clock. It has no idea where it is. It cannot look anything up. It is, in the picture I used on the slide, a brain in a jar: capable of a great deal of reasoning, and entirely dependent on whatever was put in the jar with it.
This is not a criticism of the model, and it is not something a bigger or better model fixes. It is what a model is.
Four questions for a brain in a jar
The quickest way to make the point is to ask the model things it cannot know. I asked it the time, and it told me, politely, that it had no access to real-time data and suggested I check my phone. I asked it for the weather in Portsmouth, and it apologised and recommended the Met Office.
Those two are honest failures, and the model is right to decline. The next two are the ones that matter, because the model does not decline.
I asked it about the latest iPhone, and after nearly ninety seconds of thinking it told me, in some detail and with complete confidence, that the latest model was the iPhone 16, announced in September 2024. That was true on the day the model’s training stopped and it has not been true for some time, but nothing in the answer gives you any hint of that.
Then I asked for the last six UK prime ministers, with the instruction that anyone who served fewer than fifty days should be marked with a lettuce. The model listed Rishi Sunak as the current prime minister, which he had not been for two years, and gave Liz Truss a tenure of sixty-two days, which is wrong by a fortnight and denied the lettuce its moment. Watching the reasoning scroll past in the terminal was instructive in itself: “wait, but that’s only five”, “maybe I’m missing some”, and round it went, with the fan at four thousand revolutions a minute, thinking hard about a question it had no way of answering.
So the model was wrong about something after its cut-off, which is forgivable, and wrong about something well before it, which is less so, and it delivered both with the same fluency it uses when it is right. If you take one thing from the session, take that: fluency is not a signal. I have written before about treating a model’s confidence as noise, and this is the same point made with a lettuce.
Hosted, local, open weight
Everything above applies equally to the frontier models you reach over the internet. GPT, Claude, Gemini and the rest are the same kind of thing at a much larger scale, running in somebody else’s data centre, with their own cut-off dates and their own flat line to the right of it. The difference between a hosted model and a local one is where the jar sits, and for some conversations, particularly ones involving data you would rather did not leave the building, that difference is the whole decision.
One distinction is worth being precise about, because vendors are not. Open weight is not open source. When Meta, Alibaba, DeepSeek or Mistral release a model, what you get is the weights, the file I have been describing, and a licence to run it. You do not get the training data, and you do not get the recipe. You can run it, fine tune it and inspect its behaviour, but you cannot rebuild it or fully account for what went into it, and anyone doing supplier due diligence should know which of those they are getting.
So what is an agent?
The dictionary is a better starting point than most of the marketing. An agent is a person or thing that acts, or has the power to act. A brain in a jar cannot act. It can only produce text, and it produces that text once, in response to whatever it was given, and then stops. Whatever else it is, it is not an agent.
What turns it into one is three things, and I would encourage anyone evaluating a product with “agent” in the name to look for all three.
The first is the reasoning, which is the model. This is the part everyone talks about and, for the purposes of this post, the least interesting.
The second is tools: things the model can call rather than things it has to remember. A clock. A web search. A database query. A shell that will run code. An API into your order system. The model is given a description of each tool, decides when to use one, asks for it to be run, and receives the result back as text. Give the same Qwen model a clock and a search tool and the lettuce question stops being a memory test, because the model no longer has to know the answer. It can look. That is the entire difference between the failing session above and a useful one, and the model itself has not changed at all.
The third is the loop. A single call to a model with a tool is a lookup. An agent calls a tool, reads the result, decides what to do next, calls another, and carries on until it judges the task complete or something stops it. Each turn of that loop is a decision the model is making about what to do, and the number of turns it takes before a person sees anything is the practical measure of how autonomous the thing is.
Around those three sits what I called the harness in the session: the software that holds the tools, runs the loop, and keeps whatever memory the agent has. The model forgets everything the moment the conversation ends. If your agent appears to remember last week, that is the harness writing things down and reading them back, and the notes it keeps are data your organisation is now responsible for.
The last piece is what starts it. A prompt from a person is the obvious trigger, but it is only one. A scheduled task can start an agent. So can an incoming email, a change to a record in a database, a call to an API, or another agent finishing its own work. Once the trigger is something other than a person typing, you have a system that acts without anyone having asked it to on that occasion, and that is a different thing to govern from a chat window.
AI agent, or agentic AI?
The two terms get used interchangeably, and they should not be, because one is a noun and the other is an adjective, and the difference turns out to be useful.
An AI agent is a thing. It is a specific system, built from the parts above: a model, a defined set of tools, a loop, a trigger and, usually, some memory. You can count them. You can list what each one is allowed to touch, name the person who owns it, and switch it off. When somebody says “we have deployed an agent to triage support tickets”, that is the sense they mean, and the questions in the next section apply to it directly.
Agentic AI is a property, not a thing. It describes any system in which a model is allowed to decide what to do next and then act on that decision, rather than simply answering. A single agent is agentic. So is a workflow where a model chooses which of several fixed steps to run, or a pipeline in which several agents hand work to one another, or a coding assistant that will go and edit files if you let it. The word tells you that somewhere in the system a model has been given a degree of autonomy. It tells you nothing about how much.
That is why I find it more useful to treat “agentic” as a scale than a category. At one end is a model with a single tool, where a person approves every step and reads every result, and some people would not call that an agent at all. At the other end is a process that runs on a schedule, holds write access to production systems, takes as many turns of the loop as it needs, and reports afterwards, if at all. Both get described as agentic, and both may be built on the same model. The difference between them is the tools, the trigger, the number of turns, and who is watching, and those are the things that need writing down.
So when the term arrives in a proposal, translate it before you respond to it. “Agentic” means there is autonomy in here somewhere. The questions that follow are how many agents, doing what, with access to what, started by what, and watched by whom.
Why this matters for leaders
When a supplier or an internal team tells me they are deploying agents, the model they have chosen is the last thing I ask about. The questions that matter are all about the harness, and they map neatly onto the anatomy above.
What tools does it have? That is access. A tool is a capability the model can exercise on your behalf, and the list of tools is the list of things that can go wrong.
What triggers it? That is the difference between a system that acts when asked and one that acts on its own schedule, and it changes who is accountable for a given run.
How many turns of the loop happen before a person sees the result? That is autonomy, and it is a dial rather than a switch. Somebody should have set it deliberately.
What does it remember, and where? That is data, with everything that implies for retention, access and the regulators who take an interest in such things.
None of those questions is about artificial intelligence in any interesting sense. They are the questions you would ask about any system with credentials, a scheduler and a memory, and the fact that there is a model in the middle does not excuse anyone from asking them. If anything, it makes them more urgent, because the component in the middle is confident, fluent, and periodically wrong about Liz Truss.
What this means in practice
Separate the model from the agent when you evaluate anything. The model is the reasoning. Everything that lets it act is the harness, and the harness is where your risk and your governance live.
Assume the model is out of date and cannot check. Design so that anything time-sensitive or factual comes from a tool, not from memory, and test with questions you know the answer to.
Inventory the tools before you approve the agent. Each tool is an access grant. Treat the list the way you would treat a new service account’s permissions, because that is what it is.
Know what starts it. A prompt, a schedule, a message, a data change or another agent are different governance problems. Write down which apply.
Set the loop length on purpose. Decide how far the agent runs before a human sees the result, and make that decision visible rather than leaving it to a default in a framework.
Treat the memory as data. If the harness keeps notes, someone owns them, someone can read them, and someone will eventually be asked to delete them.
The question worth asking
The question is not which model to use. It is what you have plugged the model into, who decided, and whether they would recognise the list of tools and triggers if you read it back to them. If the answer is a clear one, you have an agent you can govern. If it is not, you have a brain in a jar with the lid off, and you should probably find out what it can reach.
Working out where agents fit? If you are trying to get from an enthusiastic pilot to something you can operate and account for, get in touch . I run sessions like the one above with engineering and leadership teams, and the questions from the room are still the best part.