"We shut the AI agent down right after it went live, because it did not meet our expectations." We have heard this more than once. So what went wrong, and where? The demo looked flawless. We have put together nine reasons why an agent ends up not working the way it should.
A source system goes down, and instead of raising an error the agent returns an empty field and presents it as fact. Or an email arrives with an attachment that hides an instruction planted by an attacker. The agent carries it out, because it cannot tell content apart from a task.
Neither of these situations shows up while you are testing the agent. Both appear once it is running for real.
According to a survey by S&P Global Market Intelligence, 42% of companies abandoned most of their AI initiatives, up from 17% a year earlier. The average organisation scrapped 46% of its proofs of concept before they ever reached production. Forrester points out that an agent running over the long term behaves like a distributed system, and that what it demands above all is discipline in orchestration, identity and context handling. Most companies have prepared for none of that.
| How many projects never make it | |
|---|---|
| Agentic projects cancelled by the end of 2027 over cost, unclear value or weak risk controlGartner, June 2025 | over 40% |
| Enterprises that will restrict or withdraw agent permissions by 2027Gartner, May 2026 | 40% |
| Companies that abandoned most of their AI initiatives (17% a year earlier)S&P Global Market Intelligence, March 2025 | 42% |
| Proofs of concept scrapped before reaching productionS&P Global Market Intelligence, March 2025 | 46% |
| What holds deployment back | |
| Integration with existing systemsAnthropic and Material, 2026 State of AI Agents Report | 46% |
| Cost of implementationAnthropic and Material, 2026 State of AI Agents Report | 43% |
| Data access and data qualityAnthropic and Material, 2026 State of AI Agents Report | 42% |
| Change management on the people sideAnthropic and Material, 2026 State of AI Agents Report | 39% |
| Market and security | |
| Vendors genuinely building agentic AI, out of the thousands that claim toGartner, June 2025 | approx. 130 |
| Security leaders who regard agentic AI as a concernForrester Security Survey 2026 | 49% |
| Who is actually scaling agents, and what it returns | |
| Large companies with revenue above USD 1 billion that are scaling agentsMcKinsey State of AI, 2026 | 40% |
| Smaller companies that are scaling agentsMcKinsey State of AI, 2026 | 22% |
| Companies attributing at least some EBIT impact to AI, unchanged year on yearMcKinsey State of AI, 2026 | 37% |
| Companies whose AI running costs have limited their use of itMcKinsey State of AI, 2026 | approx. 20% |
| Where Europe stands today | |
| EU enterprises using at least one AI technologyEurostat, ICT usage in enterprises 2025 | 20.0% |
| Of which Slovakia and CzechiaEurostat, ICT usage in enterprises 2025 | 18.0% / 17.6% |
| EU enterprises using AI-based RPAEurostat, ICT usage in enterprises 2025 | 5.4% |
Figures show the share of organisations reporting each item in the survey. The surveys were run among technical leaders and managers during 2025 and 2026.
The last row matters more than it looks. It suggests that deliberate, structured automation is still a minority practice in Europe, while AI agents are built best, and most often, on top of RPA that already exists.
A chatbot answers in a chat window. An agent carries out tasks on its own.
The difference shows up after the request is made. AI agent can look data up in your CRM, read a document, weigh the context, use a tool, create a record, start a process, ask for approval and track the result. Every one of those steps touches a company system and has real consequences.
So implementing an agent means settling architecture, integration, security and operations first. Prompt engineering is the smallest part of the job.
The information held in each individual system, whether that is your CRM, your ERP, email, spreadsheets or a document store, is correct on its own terms. Each system has its own logic, its own identifiers and its own version of the truth. When those systems are not connected, the agent cannot reliably answer even a simple question about the status of a request.
This fragmentation is why companies tend to pour everything they have into the agent’s context and hope it will find what matters by itself.
Before you go live, map the source of truth for every data object, along with its owner, its quality rules and its key identifiers. An agent should not have access to everything. It should have a precisely defined context for one process.
In a demo it is enough to show that the agent can reach an interface. In production it also has to know what to do when the interface does not respond, when data arrives incomplete, when the schema changes, and when the whole operation needs to be rolled back without leaving anything behind.
In a survey by Anthropic and Material covering more than five hundred technical leaders, this came out as the single most common barrier, named by 46% of respondents. They describe one specific pattern too. The agent was built against a schema from, say, January. The interface was retired in the meantime, and nobody notices the breakage, or notices only once it is too late.
For every process, define the inputs, the outputs, the permitted tools and actions, the escalation conditions, the error scenarios, the rollback and the audit trail. The agent should not invent a process. It should use the one you have already proven, ideally through RPA you already run.
We also came across a practitioner discussion about running agents in production, and the same reason comes up again and again. The team does not want to slow the rollout down by defining access rules, so it grants the agent access to the whole system “just for testing”. The temporary fix then becomes permanent.
Agents end up with shared, borrowed or overly broad access, which means one agent opens up everything within its reach.
How to avoid it: give every agent its own identity, with a separate service account, an explicit list of permitted write actions, mandatory human approval for sensitive operations, and logging of denied attempts as well as successful calls. Permission reviews need a fixed date in the calendar, not a vague “as needed”.
When an agent processes content from outside, such as an email, a document, a web page or a ticket, that content can rewrite its instructions. OWASP, the Open Worldwide Application Security Project, ranks this first in its list for agentic applications, as ASI01, goal hijacking.
“The model is never the control.”
Gee Rittenhouse, VP of Agentic Security at AWS, and Eric Johnson, SANS Institute fellow, September 2026
Security across multiple agents cannot live in a system prompt. It has to be enforced by the platform itself.
Separate the layer where rules are enforced from the layer where the model makes decisions. Enforcement belongs in the platform, the gateway and the permission model, not in an instruction that says “do not delete records”.
An agent can fail to reach a system and carry on with its task anyway, without the data or the actions it needed. By the time a human notices, the agent has taken three more steps and multiplied the error. What then gets fixed is a broken output or an intermediate step, rather than the actual cause.
Context window exhaustion, cascading failures and schema drift are tested by almost nobody, even though those are exactly what produce silent failures with no error message.
How to avoid it: set a limit on the number of steps, add loop detection, a timeout, and a mandatory safe state the agent returns to. Every tool call needs an explicit definition of what its failure means for the rest of the run.
Gartner warns against applying one universal rule to every agent.
“Enterprises are treating AI agent governance as binary – either locked down or fully trusted, and that is the root cause of failure.”
Shiva Varma, Senior Director Analyst, Gartner
Failure then takes two forms. A simple agent gets buried under controls it never needed, so people in the company work around it. An autonomous agent is given too much freedom, which creates security or compliance exposure. Gartner recommends proportionate governance with four levels of autonomy, each a separate trust boundary.
Gartner distinguishes four levels: the agent observes, advises, acts with approval, or acts autonomously. Each one calls for a different degree of control.
The third level has one catch: approval degrades under pressure. When an employee clicks approve on reflex because the prompt has popped up for the thirtieth time that hour, the control no longer exists, whatever the original human-in-the-loop design said.
The developers say the problem sits with operations. Operations says the problem is in the AI. Neither side settles it, so the agent keeps running unfixed.
Here is a more extreme case. In June, an AI agent gained unauthorised access to a government healthcare portal. The operator was a private company in another country, and the injured party had a contract with neither of them. The incident was not reported until September, because no procedure had anticipated this situation. It is known as an orphan incident, one with no owner.
Before you switch anything on, name the process owner, the data owner, the owner of the technical solution, the person who responds to an incident, and the person who has the authority to shut the agent down. That last name matters most and is the one most often missing.
How many times the agent ran, how many messages it processed, how many tokens it spent. That is useful telemetry, and it tells you nothing about the benefit.
We also found a case where a company tracked agent activations for six months and never measured whether any of that activity improved a business outcome. The agent kept running, delivered close to nothing, and burned budget.
Every process needs one business KPI and one cost. For example the share of cases resolved automatically, the time to respond to a customer, and the cost per successfully completed task. Put it on a dashboard that management can see, not only the team that built the agent.
Licence and development costs are easy to calculate. Model requests, repeated tool calls, large contexts and searches across bulky data are far less predictable. One in five companies told McKinsey that AI running costs, tokens included, had limited their use of it.
Set a ceiling per agent and per process, bring in smaller models wherever they are good enough, and configure an automatic stop when an agent crosses the limit. Cost per task belongs in the report next to the benefit, not in a separate file held by whoever administers the cloud.
Banks, insurers, utilities and public administration face risks and obligations that an ordinary project never meets.
Take the AI Act after the Digital Omnibus. Obligations for high-risk systems under Annex III, which covers creditworthiness, life and health insurance underwriting and workforce management among others, moved from 2 August 2026 to 2 December 2027. High-risk AI embedded in regulated products has a deadline of 2 August 2028. The postponement takes effect on publication in the Official Journal.
Transparency obligations under Article 50 still apply. A person has to be told they are interacting with AI, and AI-generated content has to be marked in a machine-readable way. For systems placed on the market before 2 August 2026, there is until 2 December 2026 to put the technical marking in place.
To a bank, an AI vendor is the same kind of partner as a cloud provider. That means due diligence, a contract with mandatory clauses, and an entry in the register including subcontractors. Assessment takes weeks to months. A company that has this ready in advance saves the weeks it would otherwise spend chasing documents.
A good first candidate for an AI agent repeats often, has clear inputs and outputs, runs over systems that already have interfaces or existing automation, carries no critical impact if it goes wrong, and has a point where a person steps in and decides the final output.
Lead qualification, application checks and internal search are good examples.
Poor candidates are processes with no data foundation, no documentation, heavy regulatory exposure, or changes that cannot be undone without consequences.
If you can answer these six briefly and clearly, and back the answers with configuration, your pilot has a strong chance.
At Millennium we build agents as another layer on top of a customer’s existing architecture. In practice that means connecting to a CRM built on Microsoft Dynamics 365, to automation in Power Platform and UiPath, and to documents and reporting in Power BI. Designing the decision logic, permissions and escalations, and running the whole thing under an SLA, comes with it.
Some problems will not be solved by any vendor, and it would be dishonest to claim otherwise.
Fitting an agent into established ways of working
The fourth most common barrier in the survey cited above is change management, named by 39% of respondents. A vendor-designed agent can be technically perfect, and if it does not earn the trust of the people who are meant to use it, they will not use it. It helps when the agent takes over only the least pleasant part of the work rather than the whole job.
Data ownership across the company
Until it is clear which system is the primary one for a given piece of data, the agent has nowhere to draw a reliable answer from. That decision belongs with leadership, not with a project.
Security red teaming for agents
Prompt injection attacks are a discipline of their own and need testing on an ongoing basis, ideally by a specialist.
Deciding what not to automate
Some processes can be scrapped or simplified instead of automated. A vendor who admits that loses part of the engagement, and the customer may save more than the agent would ever have returned.
Why do AI agents fail in production?
Most often on integration, data quality, overly broad permissions, and controls that do not match what the agent is actually allowed to do. Model quality is named by very few respondents in the surveys.
What is the difference between a chatbot and an AI agent?
A chatbot answers. An agent carries out steps in real systems, works in tools, writes records and starts processes. That brings different demands on permissions, auditing and operations.
How long before an AI agent delivers a measurable effect?
With one well-chosen process and available data, the first measurable results are realistic within a few months. What decides it is the readiness of your data and integrations, not the choice of model.
What does the AI Act require of companies in 2026?
Obligations for high-risk systems under Annex III have been postponed to December 2027. Transparency obligations under Article 50 continue to apply, including informing people that they are interacting with AI and marking AI-generated content.
How do you measure the return on an AI agent?
With one business KPI and one cost per process. For example the share of cases resolved automatically against the cost per successfully completed task. The number of agent runs measures nothing.
An agent that knows everything may be interesting. An agent that knows exactly what it needs to, has the right data behind it and acts within the boundaries the company has set, is one you can keep using.
If you are moving an agent into production in an environment where nothing is allowed to break, get in touch.
