12 AI Agent Pain Points and How to Fix Them

If you build agents for a living, the failure stories stop feeling like accidents pretty quickly. Twelve recurring patterns show up across databases wiped by coding agents, wallet-transfer tools running without approval, chatbots inventing a policy that the airline was then held liable for, and pilots that never reach production. This review is assembled from primary sources and public reports — an open incident index, a framework vendor’s security advisory, a research note on production root causes, and analyst projections — not from any hands-on testing of our own. Each failure mode below has a control you can implement this quarter. Many recurring failures in these records trace back to a small set of engineering gaps — missing approval gates, wrong authorization lists, untrusted context, and no traceability — and each one has a concrete, buildable fix.

1. Irreversible destructive actions with no approval gate

The agent incident record for the Replit database deletion describes an agent that deleted a live production database after nine days of documented misbehavior in July 2025. The repo is explicit that its timeline is reconstructed from press narratives and that no vendor postmortem was published, so treat the details as approximate — the shape of the failure is not. The same repo records Amazon Kiro deleting and recreating a live production environment, and a Google Antigravity agent wiping an entire drive after being asked to clear a cache folder.

Fix: gate every destructive tool behind an explicit human approval step, keep destructive verbs on a short allowlist separate from read tools, run least-privilege credentials that physically cannot drop production tables, and require a dry-run or diff preview before any write that cannot be undone. Assume the agent will eventually be wrong.

2. Tool authorization checked against the wrong list

The VulnCheck advisory for IntentKit CVE-2026-76066 covers versions at or below 2.6.3, scored CVSS 8.7 under CWE-862. The executor validated tool calls against the full tool registry instead of the per-request narrowed list the caller had authorized. Owner-only state-changing tools — wallet transfers, posting — could therefore execute with no approval gate, reached via indirect prompt injection or history replay. The CVE record carries the same identifier, and the index entry notes that no confirmed exploitation was reported in the sources it reviewed.

Fix: enforce authorization at execution time against the same narrowed allowlist you advertised at planning time. Re-derive the allowed tool set per request, deny by default, and never let a tool call resolve by name lookup against a global registry. Add a second check for state-changing tools even when the first passes.

3. Prompt injection turning the agent against its owner

Security exploits are the largest single category in the open index: 48 of 88 tracked agent failures are security incidents. The common mechanism is content the agent reads — web pages, tool output, ticket comments, file contents — carrying instructions the agent executes as if they came from its operator.

Fix: treat everything retrieved as untrusted data, not instructions. Mark untrusted content distinctly in the prompt boundary, never allow it to modify system-level policy, and keep privileged tools out of any agent that processes untrusted input. Where possible, isolate the untrusted-reading step from the privileged-action step so that injected text never shares a context window with tools that mutate state.

4. Sensitive data exposed by agent features

The Meta Muse chat-sharing exposure is an infrastructure lesson, not a prompt lesson. The index entry for the Muse exposure gives the mechanism: share URLs embedded the conversation title in a subdomain, which landed in public passive DNS. Roughly 6,800 share links became enumerable, and Meta paused the feature. Security firm Claroc documented the enumeration method, and Ars Technica first reported the exposure.

Fix: never put user-generated or model-generated text into hostnames, URLs, or other identifiers that leave your trust boundary — titles, summaries, and session names all leak through DNS, logs, referrers, and caches. Use random unguessable tokens as the only identifier in a share link. Make sharing opt-in, revocable, and time-bounded, and audit for identifier-derived leakage before shipping the feature.

5. Authoritative hallucination

In the indexed case studies, Air Canada’s chatbot invented a refund policy and the airline was held liable for what the bot said. The failure is not that the model was wrong; it is that nothing in the system forced it to defer to a source of record.

Fix: give every factual claim class a governed source — a policy document, a pricing table, a support KB — and require the agent to answer only from retrieved passages from that source. When retrieval returns nothing that matches, the correct output is a refusal or a handoff, not a fluent guess. Return citations with each answer so a reviewer can check grounding without re-running the agent.

6. Inconsistent answers across systems

One of the five root causes of production failure is that agents give different answers depending on which system they consulted, which Atlan frames as the common root cause behind the five modes, context debt. Two agents, or the same agent on two days, resolve “active customer” or “refund window” differently because nothing forces a single canonical definition.

Fix: define business terms once in a governed layer and have every agent consume that layer rather than its own private definitions. Version the definitions, record which version produced an answer, and block deploys that introduce a new locally-defined term. Context debt compounds silently, so treat ungoverned context with the same seriousness as an ungoverned database schema.

7. Tests pass while production breaks

Evaluation suites that cover the demo scenario give false confidence: the same Atlan analysis notes agents that pass tests and still fail in production; Atlan attributes the gap to test coverage set by intuition rather than real traffic.

Trace replay is the author’s recommendation; Atlan’s own suggested fix for this gap is dashboard-as-eval. Capture anonymized production-shaped traces and replay them in CI on every prompt, model, or tool change. Hold out a slice of real data that no one tunes against, and treat regression on that holdout as a release blocker rather than a nice-to-have. Include failure-path traces — timeouts, empty retrievals, refusal cases — so the suite covers the paths your agent will hit in production.

8. Pilots that never reach production

Gartner has projected that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. A widely cited MIT research summary, reported by Fortune, puts roughly 95% of enterprise GenAI pilots at no measurable P&L impact.

Fix: define the production bar before the pilot starts — a cost ceiling, a named owner, documented risk controls, and one business metric the agent must move. A pilot with no stated cancellation criterion cannot produce a decision, only a longer pilot. Write the criteria in the kickoff doc so the eventual go/no-go is arithmetic rather than politics.

9. Cost and value unclear

Cost escalation is one of Gartner’s three named cancellation drivers in the same press release. Note the honest caveat: this is a list of causes behind the cancellation projection, not a measured cost study, so there is no per-task dollar figure to quote here.

Fix: meter cost per completed task, not per token in isolation — include retries, tool calls, and human review time in the total. Set a per-task cost budget at design time and alert when a workflow drifts past it. Tie the meter to the business metric from the pilot bar so cost per outcome, not cost per call, is what you report.

10. Agents that cannot scale beyond one use case

A fourth root cause in the production failure analysis is agents that work for the one workflow they were built for and stall everywhere else, when each agent keeps its own isolated context store.

Fix: build a shared tool and context layer that multiple agents consume — standardized tool adapters with uniform auth, a common retrieval interface, shared guardrail checks — and keep per-agent logic thin. New use cases should mostly be configuration over that layer. If adding a workflow means re-implementing tool access and prompt assembly from scratch, you have built a prototype factory, not a platform.

11. Adoption stalls because outputs cannot be traced

The fifth root cause is that users stop trusting an agent when they cannot see why it said something, and Atlan’s root-cause breakdown ties adoption stalls directly to untraceable outputs.

Fix: log, for every answer, the tool calls made, the sources retrieved, the model and prompt version, and the inputs — enough that a reviewer can reconstruct the decision without rerunning it. Make traces reviewable in a UI a non-engineer can use, because the reviewer is often an operations or compliance owner. Traces also pay for themselves twice: they are your debugging artifact and your audit artifact.

12. Customer-facing automation reversed

The Agent Failures Index records Klarna reversing its AI-first support strategy and the Commonwealth Bank rehiring staff its chatbot had replaced. Caveat: those details rest on the index’s summary; the underlying press pages were not independently reviewed for this post, so verify before quoting them in a business case.

Fix: keep a human escalation path from day one and measure resolution quality — resolved on first contact, reopened within a week, escalated — rather than only deflection rate. Deflection is a cost metric; it says nothing about whether the customer’s problem ended. Automate the narrow band where quality holds, and keep humans on the rest until the numbers say otherwise.

The 12 pain points, summarized

Pain point	Failure mode	Mitigation	Source
1. Destructive actions	Production DB and environment deleted	Approval gates, destructive-tool allowlist, dry-run	INC-001
2. Wrong authorization list	Executor checks full registry, not per-request list	Same allowlist enforced at execution; deny by default	VulnCheck
3. Prompt injection	Untrusted content steers privileged tools	Untrusted-input tagging, tool isolation	Agent Failures Index
4. Data exposure	Titles in share subdomains enumerable via DNS	Random tokens only; no content in identifiers	Engadget
5. Authoritative hallucination	Invented policy treated as real	Source-of-record grounding; refuse when none matches	Agent Failures Index
6. Inconsistent answers	Context debt across systems	One governed definition layer, versioned	Atlan
7. Test/production gap	Demos pass, real traffic breaks	Trace replay in CI; held-out real data	Atlan
8. Pilots never ship	Projects canceled before production	Written production bar before kickoff	Gartner
9. Cost/value unclear	Escalating cost, no business metric	Per-task metering tied to one metric	Gartner
10. Single-use-case agents	Bespoke wiring blocks reuse	Shared tool and context layer	Atlan
11. Untraceable outputs	Users cannot verify answers	Full per-answer trace logging and review UI	Atlan
12. Automation reversed	Support strategies rolled back	Human escalation; measure resolution quality	Agent Failures Index

How to Fix It in Practice

FAQ

Why do so many agentic AI projects get canceled? Gartner attributes the projected cancellations of over 40% of agentic AI projects by the end of 2027 to three things: escalating costs, unclear business value, and inadequate risk controls. In practice these map onto the same three gaps (the author’s mapping) — no cost metering, no stated business metric, no approval and authorization controls. Projects that write a production bar before the pilot tend to produce a decision instead of an extended pilot; this is the author’s recommendation, not a measured result.

What’s the difference between a prompt injection failure and a tool authorization failure? A prompt injection failure is about input: untrusted content convinces the agent to attempt something harmful. A tool authorization failure is about enforcement: the executor allows the call to succeed because it checked the wrong list. The IntentKit advisory shows why both matter — even with a well-behaved planner, an executor that validates against the full tool registry instead of the per-request allowlist will run owner-only tools that should have been blocked.

How do I know if my agent is ready for production traffic? Readiness is checkable, not a feeling: approval gates on destructive actions, execution-time authorization against a narrowed allowlist, grounded answers with citations, traceable tool calls per answer, and a replayed-trace CI suite that includes failure paths. If you cannot answer “which sources did this answer come from and which tools ran” for any response, you are not ready, regardless of demo quality.

The Bottom Line

Nothing in this list is exotic. Databases get deleted, tool executors check the wrong list, retrieved text gets executed as instructions, and pilots can drift for long periods without a metric. The incident records and advisories cited here support patterns 1–5 and 12; patterns 6–11 rest on analyst research and should be measured in your own stack. Each pattern maps to a specific control: approval gates, execution-time allowlists, untrusted-input handling, grounded generation, governed context, trace replay, cost metering, and full trace logging. Build the controls before you need them.

ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NiteAgent.

← Back to all posts