The central theme of this year’s technology events is the same everywhere: AI agents. No longer assistants that answer — processes that decide and act on their own, inside the company’s systems.

The discussion being had is about what the agent can do. The discussion that is missing is about where it will do it.

Because an autonomous agent does not arrive in a new environment. It arrives in the one the company already has — with the queues nobody watches, the integrations that answer twice and the roles nobody can explain. And it fixes none of that.

What an agent inherits

This is not an abstraction. It is three concrete things, and we found them in real environments before any agent existed.

It inherits the queue nobody sees. In an environment we support, invoices stopped going out. No error, no log entry, no alert — because nothing had failed: nothing had even tried. The work dispatcher pointed at an address that did not exist, and more than a hundred thousand units sat queued, stuck for weeks. The system passed any availability check. It was up, and it was not working.

An agent placed there would have done exactly what it was asked, precisely, and the result would have landed in the same queue. The whole case is here — including the wrong hypothesis that cost two days.

It inherits the integration that answers twice. No transport guarantees exactly-once delivery: the timeout fires on the other side, the queue resends, somebody reprocesses. A deterministic process repeated produces a duplicate. A process with AI repeated can produce a different duplicate, because nothing guarantees the second pass decides like the first — and at that point the defect stops being recognisable. How the same message arrives twice.

It inherits the permission nobody can explain. When a process starts acting on its own, somebody has to answer which identity signs the posting. In the pilot it runs with the account of whoever demonstrated it — usually broad, because that is who built it. In production, an automated process with a person’s permissions is an audit finding waiting for a date. And the conversation stops being about AI: it becomes role design, with catalog, space and activity kept apart.

Why this is not an argument against agents

It is an argument about order, and the difference matters.

Autonomy trades supervision for trust. While a person runs the process, they act as a sensor nobody asked for: they notice the number looks odd, the document did not arrive, things are slow today. Nobody documented that vigilance because it was free — and it disappears the moment the process starts running alone.

Granting autonomy means removing the last human sensor from an environment that may have no other. That is why the question before any agent is not what it can do, but: what, in this environment, would tell us if it did the wrong thing?

Where that answer exists, an agent is a direct, measurable gain. Where it does not, an agent is speed without brakes — and the problem shows up in reconciliation, in stock, or in a call from the customer.

The four checks before granting autonomy

None of them is about the model. All are about the environment, and all are answerable in days, not months.

1. What is queued right now? Count what should have been processed and was not. Do not look for errors — look for absence. A process that should produce a result and produces neither success nor failure is the most expensive symptom there is, because it triggers nothing.

2. What happens if the same thing arrives twice? If the answer is “that does not happen”, it means nobody checked — not that it does not happen.

3. Which identity will the process act with, and who answers for it? If the answer is “a technical account that already exists”, it is worth checking what that account can do. The answer usually surprises.

4. Who finds the error, how, and how fast? If the answer is “we would notice eventually”, the environment is not ready for autonomy — no matter how good the agent is.

What goes wrong, by name

Choosing the process by how easy it is to demonstrate. The first agent tends to be the one that looked best in the presentation, not the one that hurt most. It works, it impresses, and it creates no pressure to fix anything — because nobody misses it.

Measuring by accuracy rate. That is a laboratory metric. In production what matters is cost per transaction, time to detect an error, and the size of the exception queue.

Leaving identity and permissions for last. When they come up after the pilot is finished, the result is redoing the design — or going live with too much permission, which is worse.

Promising there will be no exceptions. It buys approval and loses credibility in the first month. The exception queue is not failure: it is the difference between an honest system and one that hides the problem until reconciliation.

Confusing “it is up” with “it is working”. That is the mistake all the others come from.

The honest limit

An observed environment does not guarantee the agent is worth it. An automated process built well on top of a bad business process delivers the same bad result, faster — and the question before all others, should this process exist this way at all?, stays with people.

And there is a scheduling consequence that changes planning: fixing the environment usually takes more work than the pilot. Planning production as “two weeks after the proof of concept” is planning the pilot, not the entry.

We are also not selling the opposite exaggeration. A perfect environment is not required to start — an observed one is, and that is far cheaper than it sounds: the four checks above take days.

If the starting point is finding what is stuck with nobody knowing, that is exactly what the IT diagnostic looks for. For the architecture overview, the challenge is not the model, it is the architecture. And to see AI applied to a real process with the limit stated plainly, read the XML and post inside SAP.

Frequently asked questions