AI agents in CRM and ERP: why 4 in 10 projects will be cancelled

Every software vendor is selling agents this year. Your CRM offers one, your ERP has announced another, and half the tools you already pay for added the word to the menu without changing anything underneath.

The figures published over the last few months cut through a fair amount of that noise. Gartner projects that by the end of 2026, 40% of enterprise applications will include task-specific agents, up from under 5% a year earlier. That is very fast adoption.

The same body of research carries the other side: more than 40% of agent projects will be cancelled before the end of 2027. The projection comes from a survey of over 3,400 organisations already investing in the technology — so it is not about companies that never started. It is about the ones that did.

The three reasons given are runaway costs, business value that was never demonstrated, and inadequate risk controls. None of them is a model problem.

What “agent washing” means

It is the name given to relabelling something that already existed as an agent: an assistant, an RPA flow, a decision-tree chatbot. Of the thousands of vendors now presenting themselves as agentic, Gartner estimates around 130 are the real thing.

This is not an accusation of bad faith in every case. The word has no strict definition, and a feature that “uses AI” can be described as an agent without quite lying. But the practical difference is enormous, because what you are buying changes completely.

A chatbot answers. An agent decides and acts. If nobody can tell you what it decides and what it could break, it is neither: it is a demo.

Four questions that tell them apart

Before signing, these four usually settle it. They take one call, and the quality of the answer matters more than the answer itself.

What does it decide without asking me? A real agent has a bounded, explicit decision space: it can choose among these actions, using this data, within these limits. If the answer is “it learns from your operation” and nothing more, there is no defined decision space — there is a demo.

What happens when it gets it wrong? An agent that acts will make mistakes. The question is not whether, but what gets logged, who finds out, and how it is reversed. If there is no answer to all three, you are the one absorbing the risk.

Can I see why it did what it did? The model does not need to be explainable in the abstract. Every action needs to be recorded along with the data that triggered it. Without that you cannot audit an error or correct the rule that caused it.

What happens if I switch vendors next year? If your business logic lives inside the tool and cannot be exported, you did not buy an agent: you leased a dependency.

The three reasons they get cancelled

Costs that run away

An agent that acts is billed per action, not per seat. Pilots get budgeted at pilot volume and cancelled at real volume, which is usually one or two orders of magnitude higher.

What to do: before switching anything on, estimate the real monthly volume of that process and multiply. If the number does not work at full volume, it does not work — the pilot was only hiding it.

Value that was never demonstrated

This is the most common and the most avoidable. Six months in, someone asks how much was saved and there is nothing to answer with, because nobody measured the previous process.

What to do: record three numbers before you start — time per case, error rate, and detection lag. They are set out in benefits of automating processes, and they get taken beforehand, because afterwards they cannot be reconstructed.

Inadequate controls

Here, cancellation is a governance event rather than a technical one. Someone in a review could not answer what is this returning and what could it break, and the project died there.

What to do: a volume cap per hour, an allow-list of permitted actions, an auditable log of every run, and two weeks in shadow mode before going live. All four are detailed in CRM with artificial intelligence.

Why narrow agents survive

The pattern among the ones that do reach production is that they do less. General autonomy remains hard to operate and easy to break; an agent confined to a domain with clear rules — qualifying a lead, booking an appointment, reconciling a payment — works inside a space where the rule can be written down and the error can be bounded.

You reach the same conclusion from the other direction. If you can write in one sentence what it has to do and when it must stop, it is a good candidate. If you cannot, it is not an agent problem yet: it is a process that has not been defined.

What to do about what you were already sold

If you switched on some “agent-powered” feature in your CRM or ERP over the last few months, a short review is worth the time:

• Find the execution log. If there is none, there is no way to know what it has been doing.
• Check how many of its suggestions get accepted without edits. If it is 100%, nobody is reviewing and the control is fictional.
• Ask who finds out when it fails. If the answer is “whoever notices”, there is no alert.
• Compare it against the previous process. Without a number there is no case — for or against.

That review takes an afternoon and usually settles the argument about whether to expand it or switch it off.

In short

Adoption is real and fast: by the end of the year, close to half of enterprise applications will ship with agents built in. The cancellation rate is real too, and it is not explained by the technology.

The projects that survive are the boring ones: small scope, written rules, explicit limits, a log of everything, and a number to compare against. Exactly what a demo does not show.

If you are not yet clear which process in your operation is a candidate, the prior step is diagnosis: there are nine fairly recognisable signs that point to what is failing and what kind of system addresses it.

---

Adoption and cancellation projections: Gartner, June 2025 and 2026–2027 forecasts, based on a survey of more than 3,400 organisations.