AI agents in the enterprise: where the ROI is, and where it isn't

An AI agent demo almost always goes well. You ask a question, the agent answers fluently and convincingly, everyone in the room nods. Six months later that same agent is not in production — or it is, and nobody uses it. That is not a model problem. The demo was built around a task that looks good, not a task that works well.

The question is never "can AI do this". It almost always can, somehow. The question is whether it pays for it to do so, who carries the consequence when it is wrong, and whether it even has access to the data that would make the answer correct.

Three properties of work worth delegating to an agent

The processes where an agent genuinely cuts cost share three properties, and all three must hold at once.

• Frequency. The work repeats hundreds of times a month. Automating a task performed twice a year costs more than the task.
• Unstructured input. The work starts with text a human has to read — a customer email, a specification, a supplier quote, a complaint. Conventional software does not help there; a language model genuinely does.
• Verifiable output. There is a way to say whether the answer is right. Either a system checks it, or a human checks it in seconds, or a later outcome confirms it.

If the third property is missing, you are not building an agent — you are building a generator of claims nobody can refute. That is the most expensive possible outcome, because the error only surfaces once it has left the building.

The cost of an error decides the architecture

The most useful split is not by technology but by what happens when the agent is wrong. How much autonomy it may hold follows directly from that.

This sounds obvious until you look at how pilots are actually scoped. The agent is usually handed the most visible process, because the board needs to be impressed — and the most visible process is normally the one with the highest cost of error.

Why pilots never reach production

When a pilot stalls, the reason is rarely answer quality. It is almost always one of three.

The agent cannot reach the data. In the demo it answers from a handful of PDFs. In reality the answer depends on stock levels in the ERP, order history in the shop and the status of a complaint in the CRM. If the agent cannot read those three systems at the moment of the question, it guesses — fluently.

The agent cannot do anything. It answers the question but does not open the complaint, reserve the goods or send the quote. The user still opens three applications, so all they gained is a better-phrased question.

Nobody owns the outcome. The pilot belonged to IT while the process belongs to sales. When the first contested answer appears, there is no owner to decide whether it is acceptable, and the whole thing quietly dies.

All three reduce to the same thing: an agent without integration is a conversationalist, not a worker. That is why integrating with the systems you already run is not a phase that follows AI adoption — it is the precondition for the AI to have any work to do.

What "ROI" actually means here

Without a measurement taken before rollout there is no return on investment, only an impression. And the impression is always positive, because the thing is new.

Measurement does not have to be elaborate, but it must exist before the agent enters the process:

1. Measure the baseline. How many requests per month, how many minutes each, what share ends in escalation. Two weeks of sampling is enough.
2. Define the acceptance threshold. Not "accuracy", but: how many errors of which kind the business is prepared to absorb.
3. Run the agent in shadow mode. It proposes but does not send. Compare its proposal against what the human actually did.
4. Measure acceptance, not satisfaction. The share of proposals sent without edits is the only number that does not lie.
5. Only then compute the saving — the difference in minutes per request times the number of requests, minus the cost of the model and its upkeep.

This is the same procedure we follow when introducing NG Sara into sales or NG Nora onto a phone line: shadow first, then proposal, then autonomy — and only for the request types that cleared the threshold.

Explainability is not a luxury

If the agent tells a customer the goods arrive on Tuesday, someone in the company must be able to answer where that came from. "The model said so" is not an acceptable answer to a customer, and it is not one to an auditor.

In practice that means the agent must cite its source: which document, which row, which order status. Systems that answer from your data instead of from their own memory make that possible — and drastically reduce invention along the way. When an agent has no source, the correct behaviour is not to improvise but to admit it does not know and hand the case to a human.

Where an AI agent is not the answer

Some processes are the wrong fit, and it is worth saying so plainly.

• Deterministic decisions. If the rule can be written as "if the amount exceeds X and the customer is in segment Y", write the rule. A language model adds uncertainty and no advantage.
• Processes that are not defined. Automating chaos produces faster chaos. If three colleagues do the same job three ways, first agree which one is correct.
• Data that does not exist. An agent cannot know what is written nowhere. If customer agreements live in the heads of account managers, no model will recover them.

Who should own the project

The owner of an AI project is not IT. IT builds and maintains it, but the decision about what counts as an acceptable answer belongs to whoever was doing that work by hand until yesterday — the head of sales, of support, of purchasing. Without them nobody can say whether a proposal is good, so every doubt lands on the desk of a developer, who knows the least about the work.

In practice exactly three people are needed, and none of them may be nominal:

• The process owner. Defines what a correct answer is and accepts the risk of error. Has the right to stop the project.
• The engineer. Connects the agent to the systems, measures and maintains it. Does not decide on content.
• Someone allowed to say "this does not pay off". Usually finance. Without that role the project runs on enthusiasm, which lasts until the first shift in priorities.

The cost everyone overlooks

The per-call price of the model is the smallest line item and the only one anyone discusses. Three larger costs arrive later: evaluation (someone must review a sample of answers every week), keeping the context current (when the price list or the process changes, the agent does not find out on its own) and the human review time you have just created where none existed before.

So the saving cannot be computed as "minutes before minus minutes after". You must also subtract the time now spent checking proposals. If that difference stays positive, you have a project. If it does not, you have a more expensive version of the same work.

The sequence that works

Adoption that survives production almost always follows the same path: pick a process with high frequency and low cost of error, connect the agent to the systems where that process lives, run it in shadow mode until it clears the acceptance threshold, grant autonomy only for the slice of requests it has proven, and only then widen the scope.

None of those steps is about the model. All of them are about process, data and accountability — which is exactly why AI projects succeed or fail for reasons that have nothing to do with artificial intelligence.