What an AI agent actually is.
Everyone is selling agents. Almost nobody explains the mechanism — which is simpler, stranger, and far more reassuring than the word suggests.
An agent cannot do anything. It can only write down the name of something it would like done.
That sentence is the entire article. Everything below just makes it concrete, because once you genuinely believe it, the fear goes away and the right questions arrive — what is it allowed to ask for, and who checks before it runs.
Start from what we established last time: a language model does exactly one thing, which is predict the next piece of text over and over. It has no hands. It cannot open your CRM any more than a book can open your CRM. If you have not read that one, start there — this piece builds directly on it.
So how does an “AI agent” book a meeting, search your database, or send an email? By exploiting the one thing it can do. It writes text. Somebody else reads that text and acts on it.
A “tool” is a menu, not a power.
When someone says they “gave the AI tools,” picture something far more boring than you are imagining. A list of tool names and one-line descriptions gets pasted into the transcript, above your message. That is it. That is the whole act of giving an agent tools.
The model does not receive abilities. It receives a menu, in text, the same way it receives everything else. Tick the boxes below and watch the menu change — and watch what the agent can and cannot do as a result.
This is the setup to start with: it can look things up and tell you what it found, and it cannot alter a single record.
Not powers. A menu, written in plain text, pasted above your message — exactly like the system prompt.
You may use the following tools. To use one, write its name and inputs.
- search_crm — Find clients, deals, and contact history. Returns rows. Changes nothing.
- read_email — Search and read messages in the shared inbox. Changes nothing.
- “Which clients have gone quiet since January?”It can ask for this tool, and your software will run it.
- “Summarise everything Vantage emailed us last month.”It can ask for this tool, and your software will run it.
- “Move Orbit Events to “proposal sent”.”No tool for this. It can ask all it likes — nothing will run it.
- “Send all three of them a follow-up email now.”No tool for this. It can ask all it likes — nothing will run it.
Notice where the power sits. Unticking a box does not persuade the model to behave — it removes the option from the menu and, more importantly, means your software will refuse to run it even if the model asks. That is a real lock, not a polite request.
Watch an agent answer a real question.
Here is a genuine DMC question — which clients have gone quiet — handled by an agent with CRM access. Step through it and keep your eye on one thing: who is doing what. The model writes. The software acts. They are never the same step.
You type a message
Which clients have gone quiet since January? Anything worth chasing before the season?
Normal question, typed into a normal-looking chat box. Everything after this is the part nobody shows you.
Which clients have gone quiet since January? Anything worth chasing before the season?
Every item here is plain text, and every pass re-reads all of it. A tool result is not stored anywhere special — it is just another line in the pile.
So the difference between a chat and an agent is not intelligence. It is permission to go around the loop more than once, and a menu of things it may ask for on the way. Same model. Same next-word prediction. More laps.
The whole shape, in one picture.
This is worth sitting with, because it answers the question every owner actually has: what stops it doing something stupid? Not the model’s judgement. The gate. Your software receives a request written in text and decides whether to honour it — against permissions you set, with a human in front of anything that matters.
An agent that “went rogue” is almost never a model that broke free. It is a gate somebody left open.
Four agent failures that suddenly make sense.
“It confidently told me it had updated the CRM. It had not.”
Writing “I have updated the record” is just text, and text is free. If the tool was never enabled, or the request failed, the model can still produce a satisfied-sounding sentence — because a sentence is all it ever produces. Never take the agent’s word for what it did. Look at the system it claims to have changed.
“It went in circles, searching the same thing over and over.”
Each lap it re-reads the whole transcript and decides what to do next. If the tool keeps returning nothing useful, the most plausible next move still looks like “search again” — so it does. Good agent software caps the number of laps for exactly this reason. If yours spirals, the fix is usually a sharper first instruction, not a smarter model.
“It picked completely the wrong tool.”
It chooses from names and one-line descriptions, the same way it chooses any other word: by what looks most plausible. Two similarly-named tools, or a vague description, and it will guess wrong. This is why agents with forty tools tend to be worse than agents with five. More options means more ways to be plausibly wrong.
“Someone put instructions in an email and the agent followed them.”
Real risk, and it follows directly from the mechanism. A tool result is pasted into the transcript as text — and the model cannot truly tell your instructions apart from text that arrived in a document. If an agent can read your inbox and also send email, a crafted message is an instruction. This is the honest argument for read-only first and a human between draft and send.
Judge an agent by its menu, not its demo.
Next time somebody demonstrates an AI agent for your business, the demo is the least interesting part. Ask what is on the menu: which tools can it request, which of those change data rather than just read it, what happens when it asks for something it should not get, where the human sits, and how you revoke the whole thing on a bad afternoon.
Those are not technical questions. They are the same questions you would ask about a new employee’s system access — and now you know enough to insist on the answers.