AI agent failures: 5 reasons agents fall out of use
Three months ago, invoice checks went to an AI agent. The run history shows it working every morning. Ask the staff, though, and they say they no longer look at its results: checking the work themselves is faster. With no errors and no complaints, the AI agent falls out of use.
In a 2025 study by NANDA, a research group at MIT, 60% of organizations had evaluated enterprise generative AI systems, but only 20% reached a pilot and just 5% reached production. The reasons it found were not model quality. They were workflows that break at small differences, systems that don’t learn from how they are used, and misalignment with day-to-day work. In Japan, too, IPA’s DX Trends 2026 found that among companies using or trialing AI, 31.8% got the effect they expected or more.
This article covers five ways AI agents fall out of use after launch, and how to prevent each. It also checks, against the research, whether outsourcing, often blamed, is really the cause.
The short answer: agents fall out of use because they can’t change after they are built
- Not capability, but the inability to change: when the work changes and the AI agent doesn’t, staff go back to doing it by hand
- Five failures: it can’t keep up with change, no one owns it, no one measures it, its model retires, and no one trusts it with the work
- Outsourcing itself isn’t the cause: in MIT’s study, AI built with outside partners reached production more often. What decides it is who fixes it after it is built
- Decide before launch: the owner, the numbers to watch, how to fix it, approvals, model changes, and when to stop
What the research shows after launch
| Study | Findings |
|---|---|
| MIT NANDA (2025; interviews with 52 organizations, a survey of 153 senior leaders, and over 300 public deployments) | 5% of enterprise generative AI systems reached production. For complex work, such as multi-week projects or client management, 90% would assign it to a junior colleague rather than AI |
| IPA, DX Trends 2026 (1,799 companies) | Among companies using or trialing AI, 31.8% got the effect they expected or more. 50.6% said “some effect”, so half see results, but fewer than they hoped |
| Gartner (June 2025) | Predicts that by the end of 2027, over 40% of agentic AI projects will be canceled due to escalating costs, unclear business value, or inadequate risk controls |
| Sinch (May 2026; 2,527 decision makers in 10 countries) | 74% of enterprises have rolled back or shut down an AI customer communications agent after deployment due to a governance failure |
Each study has its own scope and definitions, and MIT’s report is preliminary, with a small sample. What they share is this: getting AI used, and keeping it used, is harder than building it.
Failure 1: it can’t keep up with change
A business partner’s site changes its screens. A form gains a field. An approval threshold changes. The work keeps changing, a little at a time. If the AI agent doesn’t change with it, exceptions pile up, staff fix more and more by hand, and before long the manual way is faster.
In MIT’s study, the reasons users gave for not building AI into their core work were “breaks in edge cases and doesn’t adapt”, “can’t customize it to our specific workflows”, “too much manual context required each time”, and “it doesn’t learn from our feedback”. A corporate lawyer at a mid-sized firm said of ChatGPT that it is excellent for first drafts, but it doesn’t retain knowledge of client preferences or learn from previous edits, and repeats the same mistakes.
If AI doesn’t remember a fix staff explained once, staff make the same correction every run. Why automation stops when screens change is covered in Why RPA bots break when screens change.
What to check:
- When a business rule or a partner’s screen changes, who fixes it, where, and how quickly
- Whether what staff fixed, and why, is kept and used in the next run
- Whether, on an exception, it stops and tells someone, rather than quietly producing a wrong result
Failure 2: no one owns it
When the rollout project ends, the team disbands. The contract with the vendor ends. The person who built it moves on. What remains is an AI agent that still runs but belongs to no one. Staff who notice a problem don’t know whom to tell, so they quietly go back to doing it by hand.
Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built by vendor FDEs (forward deployed engineers), trapped by soaring costs and unable to evolve it on their own. It notes that early progress can look fast while no internal capability is built. MIT’s study finds that organizations that succeed decentralize the authority to build while keeping clear accountability.
What to check:
- For each AI agent, who is accountable for the work and who fixes it, and who stands in when they are away
- Who fixes it after the contract with the vendor ends
- Whether there is a list (a ledger) of every AI agent that runs
Handling automation whose builder has left is covered in Taking over an RPA bot whose builder has left, and how to keep the list in How to build a robot ledger for RPA, with a template.
Failure 3: no one measures whether it is used
An AI agent that falls out of use raises no errors. In the run history, it runs every day. What changes is the time staff spend rechecking its results, and the number of cases they handle without it. You can’t see either unless you measure them.
In MIT’s study, only 40% of companies had bought an official AI subscription, but workers at over 90% of companies used personal AI tools for work regularly. Staff who stop using the company’s AI don’t stop working. They move to something else.
Unclear business value is also one of the three reasons Gartner gives for cancellations. MIT finds that companies that succeed judge AI on business outcomes, not model benchmarks.
In Sinch’s survey, the organizations with the most mature governance rolled back AI agents most often, at 81%. Sinch reads this as better monitoring letting them identify failures other organizations are missing. What you measure, you can decide to fix or stop sooner.
What to check:
- Whether success is defined in numbers (such as the share of cases handled without a person’s correction)
- Whether you regularly look at how many cases the AI agent handled, how many people corrected, and how many were handled without it
- Who looks at those numbers and decides whether to fix it or stop it
Setting success criteria is covered in the adoption steps of 7 things to check before adopting AI agents for business.
Failure 4: its AI model retires
The AI models that AI agents use retire. Anthropic gives at least 60 days’ notice, and requests fail after retirement. On October 14, 2026, OpenAI notified developers that GPT-4o, GPT-4.1, and other models leave the API on January 14, 2027.
Notices go to whoever holds the AI model’s API account. If the vendor holds it, your team may not notice until the agent stops one day. A replacement model may not behave the same, so test it on the work before switching.
What to check:
- Whether you or the vendor holds the AI model’s API account
- Who receives retirement notices, and who tests the replacement model
- Whether there is a procedure for comparing results on the same inputs before and after the change
What happens under outsourcing, FDE, and in-house building once a notice arrives is compared in Building AI agents in-house: outsourcing, FDE, or AI + RPA.
Failure 5: no one trusts it, so people recheck everything
Once a single error reaches a customer or partner, staff start rechecking every result the AI agent produces. If they recheck every case, it takes as much effort as doing the work by hand. Soon there is no point in running it through AI.
In MIT’s study, 70% would give quick tasks such as drafting emails to AI, while 90% would give complex work to a junior colleague. In Sinch’s survey, too, the reason enterprises rolled back or shut down AI agents after deployment was a governance failure.
The way out is not to choose between trusting it with everything and checking everything. Place a person’s approval only before operations that are hard to undo (registering, sending, paying), and check the rest with numbers you can verify outside the AI, such as counts and totals.
What to check:
- Which operations are hard to undo, and who approves before each
- Whether the AI’s results can be checked outside the AI, with counts or totals
- How far back you can go when an error is found
How to split steps between AI and fixed procedures is covered in AI agents vs RPA: when to use which, step by step.
Is outsourcing to blame?
You sometimes hear that outsourced AI agents fall out of use. The research says it isn’t that simple.
In MIT’s study, AI built with outside partners reached deployment about 67% of the time, against about 33% for tools built internally. Employee usage was also nearly double for externally built tools. Here, partnering means buying a learning-capable tool and customizing it together with the vendor. MIT itself cautions that the figures are self-reported by 52 organizations, and that the correlation does not prove causation.
According to MIT, the companies that succeeded treated AI vendors less like software sellers and more like business service providers, and they:
- Demanded deep customization to their own processes and data
- Judged tools on business outcomes, not model benchmarks
- Worked through early failures with the vendor, treating deployment as something they grew together
- Started initiatives from frontline managers, not a central team
Meanwhile, as noted above, Gartner predicts that 70% of enterprises will abandon agentic AI built by vendor FDEs.
The two don’t contradict each other. Working with outside partners makes production easier to reach. Whether the agent stays in use depends on who fixes it as the work changes after it is built. All five failures happen whether you outsource or build in-house. They just happen differently.
| Failure | How it tends to happen when outsourced | How it tends to happen when built in-house |
|---|---|---|
| It can’t keep up with change | Every fix waits for a quote and a slot | It waits until the builder has time |
| No one owns it | When the contract ends, no one fixes it | When the builder moves on, no one understands it |
| No one measures it | The contract has no business outcome numbers | No one is assigned to look at the numbers |
| Its model retires | The notice goes to the vendor, and your team doesn’t notice | Whoever gets the notice has no time to test |
| No one trusts it | You can’t see inside, so people recheck every case | No one has decided where approvals go |
How to compare outsourcing, FDE, and building in-house is covered in Building AI agents in-house: outsourcing, FDE, or AI + RPA.
Six things to decide before launch
- Owner: who is accountable for the work, who fixes it, and who stands in
- Numbers to watch: cases the AI handled, cases people corrected, and cases handled without AI. Who looks at them, and how often
- How to fix it: who fixes it and where, where the reasons for fixes are kept, and how changes are tested before production
- Approvals: who approves before operations that are hard to undo
- Model changes: who holds the API account, who receives notices, and how a replacement model is tested
- When to stop: at what numbers you fix it and at what numbers you stop it. Once stopped, take it off the ledger
The sixth is easy to overlook. An AI agent no one uses still costs AI usage fees, and still has access to the systems it operates. With a stopping rule decided, you can stop it without hesitating once you notice it has fallen out of use.
Frequently asked questions
Should we rebuild an AI agent that has fallen out of use?
First, check which of the five failures it fits. If it has only fallen behind changes in the work, fixing it brings it back into use. If no one owns it, decide an owner first. If the business numbers show no effect, stopping it is also an option.
How can we tell that an agent is starting to fall out of use?
Watch the trend in cases people corrected and cases handled without AI. The run history alone only shows that it runs. Asking staff how much they recheck its results is also a quick way to find out.
What should we settle in a contract with a vendor?
Success criteria measured by business outcomes, who owns what is built, the documents handed over, who holds the AI model’s API account, and who fixes it after the contract ends. See Building AI agents in-house: outsourcing, FDE, or AI + RPA for details.
Keep it in use with Kitewell
Descarty’s Kitewell is AI RPA that AI builds and AI fixes. Business staff build by conversation, and fix by conversation. It covers the five failures this way:
- It keeps what you teach: each business rule or correction you state in the chat is kept at once, in your words, under What Kitewell knows. The chat says what it remembered, and Undo takes it back. The assistant reads everything it knows for every request. Teach from a manual teaches it from a PDF, Word, or Excel file
- Fix by conversation: ask the assistant, and it shows the change and a preview of the flow. Nothing is saved until you choose Apply, and Undo takes it back. AI relearns a screen operation only when the screen changes, and the run record shows when it did
- It tells you when a run stops: failures and approvals waiting are sent to Slack, Microsoft Teams, email, and more. With failure diagnosis on, the first failure in a streak is sorted into Try again, Needs you, Workflow change, or Unclear, with the cause and the next step
- See the numbers: Runs & logs shows failed runs and the success rate
- Place approvals: any step can require approval. The approver chooses to approve, send back, or reject, and when and how they decided is recorded
- Change a model in one place: AI models are registered under Agents & models, and workflows refer to the registration. Change the registration, and every workflow that uses it follows. Learned screen operations are not tied to a model, so they need no relearning
- See everything, and fix as a team: export a robot ledger to Excel. With projects synced through Dagu Cloud, workflows someone fixed and what Kitewell knows reach every computer
In the PoC, Descarty builds the workflows together with your team to prove the effect. In production, your staff build and fix the workflows by talking with Kitewell’s assistant. What you build, and the ability to fix it, stay with you from the start.
You can start by choosing one AI agent that has fallen out of use, or one process a vendor fixes for you, and verifying it with us as an early access partner. See Early access partners for details.
Summary
- AI agents fall out of use less because of model capability than because they can’t change with the work after they are built
- Five failures: it can’t keep up with change, no one owns it, no one measures it, its model retires, and no one trusts it with the work
- Outsourcing itself isn’t the cause. In MIT’s study, AI built with outside partners reached production more often. What decides it is who fixes it after it is built
- Before launch, decide the owner, the numbers to watch, how to fix it, approvals, model changes, and when to stop
Sources
- Fortune: MIT report: 95% of generative AI pilots at companies are failing (August 18, 2025), reporting MIT NANDA’s preliminary report “The GenAI Divide: State of AI in Business 2025” (July 2025). In the report, the share reaching production is on page 3, personal AI tool use on page 8, users’ reasons and the work they would give a person on pages 12–13, and the comparison with outside partners and what successful buyers did on pages 19–20
- IPA (Information-technology Promotion Agency, Japan): DX Trends 2026 (July 30, 2026; in Japanese). The effect of AI adoption is figure 3-13
- Gartner: Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (June 25, 2025)
- Gartner: Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028 (September 29, 2026)
- Sinch: Sinch research reveals 74% of enterprises have rolled back live AI customer communications agents (May 13, 2026)
- Anthropic: Model deprecations
- OpenAI: Deprecations
Verify it on your own work as an early access partner
We run Kitewell workflows with you on the same screens and data as production, and measure processing time, success rate, and how easily a stopped run is fixed.
The joint verification differs by engagement. For system integration, we set the requirements and design and test on production screens through errors and screen changes. For adoption by your staff, it is a one-department pilot: staff are trained, build their own tasks, and the effect is measured.
What we ask of you
- One contact person for the work being automated
- Procedure documents or manuals (or a recording of the work if there are none)
- Test accounts and access to the screens involved
- Sample data close to production
- A machine to run Kitewell
- An API key for the AI model you will use, or an in-house model server
- Regular feedback during the verification
- Help publishing the joint verification case study
Verify Kitewell with us on your own work
- Kitewell's developers support you directly, from the first interview to production
- Features your work needs are added to Kitewell itself, with priority
- The results are published as a joint verification case study, without your company name if you prefer
- One month for ¥500,000 before tax, with no charge if the agreed success criteria are not met
- If you go on to a contract, the verification fee is credited to the first year