AI agents in a company: what actually runs

What an agent does that an assistant does not

The difference fits in one word: acting. An assistant produces text someone reviews and then uses. An agent chains steps and triggers actions in your systems, without going back through a human at every step.

That last line often surprises. An agent that searches, corrects itself and retries consumes several times what a single answer costs, and the bill follows the number of tasks and their difficulty rather than the number of users.

The third line decides everything else. With an assistant, control comes after: someone reads before sending. With an agent, it has to come before, as a list of permitted actions. That shift is the whole subject here.

The four decisions to take before going live

They are taken in a meeting, not in development, and none requires technical skill. Yet they are what determines whether the agent still runs three months later.

1. The scope. One named process, with a beginning and an end. An agent meant to "help the sales team" has no scope, therefore no success criterion and no moment when you stop it.
2. The permitted actions. The written list of what it may do alone, and what waits for human approval. Reading, searching and drafting usually pass without approval. Sending, writing into a business tool and committing money do not.
3. The cost ceiling. A monthly amount past which the agent stops. Without it, a loop going wrong on a Friday evening is discovered on Monday, on an invoice.
4. The owner. A named person who receives the alerts, reads the traces and decides on fixes. Not a team, a person.

The fourth is the one most often skipped, and it also explains most agents abandoned after a quarter. A system with no owner does not die of an incident, it goes quiet for want of someone to restart it.

None of these four decisions depends on the technology chosen. They are identical whether you deploy an open project, buy a platform or have something built.

Where to place human validation

The temptation is to have everything approved, which amounts to paying an agent to produce drafts. The other extreme, letting everything through, turns the first mistake into a customer incident. The useful rule places validation at the boundaries, not inside the flow.

A boundary is a place where the effect becomes visible outside the system. As long as the agent works for itself, there is nothing to approve. As soon as its output becomes the reference for a colleague or a customer, there is.

This grid has a useful side effect: it makes the trace readable. When approval is requested at boundaries, each one corresponds to an identifiable moment, and post-incident audit becomes possible.

What it costs, and why nobody can price it in advance

A figure given before scoping is a made-up figure. What can honestly be said is the structure of the bill and what moves it.

• The model. Billed per token, at your provider. It dominates as soon as the agent runs continuously, and it follows context length as much as task count.
• Hosting. A few tens of euros a month for a running service, more if high availability is needed.
• Setup. Scoping, connectors, the action policy, the guardrails. A starting cost, not a recurring one.
• Operations. Monitoring, updates, fixes. A few hours a month even when nothing goes wrong, and it is the line quotes forget.

Two factors multiply everything else. How many exceptions the real process has, because each edge case adds code and rework. And the quality of the input data, because an agent fed incomplete records produces errors faster than a human would.

Which is why a twenty to forty minute scoping session on one precise process beats a quote written from a general description. The generic quote turns out wrong at the first edge case.

Three cases where an agent is the wrong tool

Saying no to an agent is more useful than deploying one in these three situations, and it shows before the first line is written.

The process is fully predictable. If the rules can be written down, a classic automation does the job without a model, cheaper and without variability. Adding a probabilistic call to a deterministic chain adds a failure source and a moving bill, for nothing.

Nobody can say what the process does today. An agent does not discover your implicit business rules, it inherits them from the prompt someone writes. If the procedure lives in the heads of three people who disagree, the work to do is to write it down, not to automate it.

The volume does not justify the maintenance. An agent handling ten requests a month costs more to operate than it saves. The threshold depends on the time actually spent per request, and it is calculated beforehand, not after.

These three cases share one thing: none is a technical problem. They are settled during scoping, and that is where the difference lies between an agent that holds and an abandoned project.