AI agents in business: what works, what fails

An agent is a program that decides to chain calls to tools in order to reach a goal stated in natural language. The definition already contains the risk: what makes an agent useful — its latitude — is also what makes its behaviour hard to guarantee. The whole job consists of narrowing that latitude to the point where the service becomes predictable, without making it useless.

What works

The successes differ in what they do and resemble each other in how they were prepared. A few traits keep coming back, and none of them is about the choice of model.

A narrow, measurable scope

The projects that land start from a task you can describe in one sentence, with a success criterion written before the first line of code: the request is filed in the right queue, the reply contains the case reference, the document is extracted without anyone stepping in. A narrow scope lets you observe progress; a wide one only lets you argue about it.

Data that is already clean

An agent wired to an up-to-date database, whose fields mean something stable, produces usable answers from the first attempts. Wired to a shared folder where four versions of the same price list sit side by side, it produces wrong answers with exactly the same confidence. The model does not arbitrate between two contradictory truths: it picks one. When the data is not ready, putting it back in order is the project — the agent comes afterwards.

An explicit human takeover

Agents that last know how to stop. A confidence threshold, escalation triggers, a takeover button: the conversation passes to a person, with the history and a summary, without the user having to repeat themselves. Takeover is not an admission of failure, it is what makes the automation acceptable to the people who will have to live with it.

Logs from day one

Without traces, there is no way to know why an answer was produced, and therefore no way to improve it. From the very first version we record the input received, the tools called, their parameters, their results and the final decision. It is also what makes it possible to answer the question that always follows an incident: how many times has this happened, and since when?

A use case where an error costs little

For a first agent, a task whose errors can be undone in a minute beats a task that commits the company. Sorting, summarising, preparing a draft, proposing a classification: the final act stays human. Trust gets built on that ground, and then the scope widens. Never the other way round.

An owner on the client side

An agent without an owner drifts: the instructions age, the data changes shape, unforeseen cases pile up with nobody looking at them. The projects that hold have, at the client, an identified person who reads the logs back, settles the edge cases and decides when to widen the scope. The role takes little time; that does not make it optional.

What fails

The failures resemble each other far more, and they are rarely technical. Five patterns keep returning.

• The agent that “does everything”. An assistant meant to answer customers, write quotes, chase unpaid invoices and feed the CRM fails everywhere at once, and nobody can say where.
• Wiring to data nobody maintains. A connector does not repair an abandoned reference dataset: it spreads its errors faster and further.
• No success criterion. With no threshold set in advance, evaluation comes down to impressions, and the project stops at the first disagreement.
• The demo that never reaches production. A prototype approved in a meeting, then set aside for want of an owner, an operating budget or real access to the systems.
• Confusing an impressive demo with a reliable service. Ten hand-picked cases always succeed; it is the cases nobody picked that decide the project’s fate.

These five failures share one root: the latitude left to the agent was never bounded — not by the scope, not by the data, not by a criterion. That is not a model defect, and a newer model does not fix it.

One last pattern, quieter, deserves a mention: the agent delivered with no operating budget. A service that calls a model has a recurring cost, versions that change underneath it, and instructions to revise. Treating it as a project that ends, rather than as a service that gets operated, amounts to scheduling its abandonment.

The guardrails that hold

1. A restricted tool set. The agent reaches only the functions its task needs, read-only by default, with writes authorised by name.
2. Human approval before any irreversible action: sending something outside, writing to a database, committing commercially, deleting. The agent prepares, a person confirms.
3. Admitting ignorance made possible, and even rewarded. An agent has to be able to say it does not have the information and hand over; without that exit, it will fill the gap.
4. Execution limits: number of steps, duration, cost per task. A loop that runs away must stop by itself, not be discovered on an invoice.
5. A frozen set of test cases, replayed on every change of instruction, tool or model. It is the only way to know an improvement has not broken something else.

None of these guardrails is specific to AI: they are the ones any service that writes into production systems already needs. It is precisely because an agent appears to converse that people forget to apply them to it.

Start small, and mean it

The right first iteration rarely looks like what was imagined in a meeting. It takes a real task, often a thankless one, chosen because it comes back every day and because its result can be checked. It is put into its users’ hands for a few weeks, with its logs, its human takeover and its success criterion.

Three outcomes are possible, and all three are useful: the service holds and the scope widens; the service holds but usage does not follow, so the need was somewhere else; the service does not hold, and you know at which link — the data, the instructions, the tooling or the scoping. A project stopped after three weeks for an identified reason costs far less than one defended on principle for six months.

An agent is not a product you install, it is a service you operate.

That is why we always start by looking at what is already there: the data actually available, the tools already in place, the person who will take over, and what happens on the day the answer is wrong. The technology comes afterwards, and it is rarely the hard part.