AI agents for business — what they do, where they fail, how to stay in control
How an AI agent differs from a chat, what risks unsupervised action carries, and which control mechanisms a tool must have before you let it near company data.
In 2026 the category moved from "AI as a feature" to "AI that does work". Notion shipped external agents as team members, monday repositioned as an AI work platform, and the MCP protocol landed in the offering of all five leading players in the category.
At the same time, around 80% of organisations report risky agent behaviour (KPMG, 2026).
Those two facts together describe the situation precisely: agents started doing real work before anyone solved the problem of controlling them. This guide is about getting into agents without joining that second statistic.
How an agent differs from a chat
The difference is not the model. The same model can be either. Nor is an agent the same thing as an automation, which follows a route somebody wrote down in advance — an agent, an automation and a chatbot are three different things sold under one name.
A chat takes a question and returns text. Its worst possible failure is a bad answer, which you will see and discard.
An agent gets tools — the right to save a record, send a message, trigger a process — and a goal. It decides which tools to use and in what order. Its worst possible failure stays in the system or reaches a customer.
That moves all the attention from answer quality to control over consequences. A model that is wrong in 5% of chat answers is useful. The same model issuing invoices with a 5% error rate is a problem.
Where agents fail
Four recurring categories, most common first:
Acting on stale data. The agent reads a record, makes a decision, and meanwhile someone else changes the record. The agent finishes on a state five minutes out of date. That is not a model failure — it is a missing lock.
Permissions that are too broad. An agent launched by the owner inherits the owner's permissions and therefore sees everything. Asked something by a junior employee, it can surface data that employee has no access to. That is a permissions-architecture problem, not an AI problem.
Confidence without data. Asked about something absent from the data, a model is more likely to guess than to say "I don't know". In a chat that is irritating. In an agent that writes something based on that guess, it introduces an error into the system.
Cascade. An agent runs a sequence where step three builds on a wrong result from step one. With no way to stop mid-run, you find out at the end, once every step has executed.
Three mechanisms you should not start without
1. Approval of individual actions
The agent proposes an action, a human approves or rejects it — before execution, one at a time.
The key word is "one at a time". Bulk approval once a day is not control, it is ritual: nobody reads forty items on a list, everyone clicks "approve all". Control works when it concerns a single action at the moment it is about to happen.
It is also the mechanism that changes the conversation inside the company. "AI will be operating on our data" meets resistance. "AI will propose, you will click" does not.
2. Stop mid-run
An agent halfway through a sequence must be interruptible. Without that, your only option is to wait for the end and clean up afterwards.
3. Change log with revert
Every change — human and machine — recorded with who, what and when, and reversible.
This is the mechanism that most changes the character of a rollout. When every mistake can be undone in one click, it stops being an incident requiring a procedure and becomes a detail. A team that knows this tests more boldly and adopts faster.
We cover what a well-designed approval screen contains in the piece on human approval for AI actions.
How to start in a company of 11–200 people
Exactly which task goes first is worth deciding on purpose — there are five questions that pick an agent's first task, and reversibility is only the first of them.
Your first agent should only read. Answering questions about company data — "how many open jobs does this customer have", "when was the last visit" — carries no write risk and immediately shows whether your data is in order. If the agent answers badly, the problem is almost always the data, not the model.
Your second agent writes, but with approval. Status changes, notes, task creation — all through an approval screen. After two weeks you will see how many proposals you accept unchanged. That is your trust metric and simultaneously the signal for when to loosen up.
Your third agent acts externally — and that is the boundary worth stopping at. Customer messages, outbound documents, anything that cannot be undone on the other side. Here approval should stay permanently, no matter how well the agent performs.
Something to know in advance: cost
Language models bill by usage. An agent running a sequence of steps consumes many times more than a single chat question, because every step is a separate call carrying the accumulated context.
Practical consequences:
- Ask your vendor how AI is billed. Included in the subscription, credits, or pay-as-you-go — three different models with very different risk profiles as usage grows.
- Check whether you can see consumption. A tool that does not show what a given operation cost will not let you control the bill once your team genuinely adopts it.
- Watch automatically triggered agents. An agent reacting to every record change in an active database can generate cost out of all proportion to its value.
Model-agnosticism: why it matters
The model market shifts every quarter. A tool hard-wired to one vendor transfers that risk to you: a price change or a quality regression at the vendor becomes your problem, with no way out.
A practical criterion when choosing a tool: check whether you can switch models without rebuilding what you have already built. The standard that makes this possible is MCP — we cover it in the guide on connecting AI to company data.
Where to next
- Human approval for AI actions — what it looks like in practice
- AI adoption for companies with no IT department — the wider context
- Connecting AI to company data — plugging a model into your own information
Frequently asked questions
- How is an AI agent different from a regular chat with a model?
- A chat answers with text; an agent performs actions — it changes data, sends messages, triggers processes. The difference is not the model but whether it was given tools and the right to use them. That shifts the centre of gravity from answer quality to control over consequences.
- Can an AI agent work on company data unsupervised?
- Technically yes, practically it is not worth it. Around 80% of organisations report risky agent behaviour (KPMG, 2026). A sensible model is an agent that proposes actions and a human who approves them, with every change reversible.
- What does an AI agent need before it can be deployed safely?
- Three mechanisms — approval of individual actions before execution, the ability to stop the agent mid-run, and a change log that lets you reverse any write. Without any one of them the control is cosmetic.
- Will AI agents replace staff in a small company?
- In companies of 11–200 people, agents take away data retyping, document hunting and report assembly — work that develops nobody anyway. Work requiring judgement and customer contact stays with people, because that is exactly where the agent has to ask permission.
Read next
Which tasks to hand an agent first — a five-question test
The first task an agent gets decides whether anything survives. Five questions that pick it, examples that pass and fail, and the order worth working in.
AI agent permissions — what it may do and how to limit it
An agent inherits some account's permissions, and the whole question is whose. How to split read from write, handle irreversible actions, and what to check.
AI agent, automation and chatbot — three different things, one name
Automation follows a path someone wrote down, a chatbot answers, an agent picks its own steps. How they differ, which to choose, and what the wrong pick costs.