Why most agentic AI projects fail before they start

Agentic AI is being sold to SMEs as the next production system: an agent that reads your invoices, chases your leads or triages your support queue, without a person watching every step. The pitch is compelling. The failure rate behind it is real, and it is mostly not about the AI.

Gartner expects more than 40% of agentic AI projects to be cancelled before the end of 2027, citing unclear value, spiralling cost and weak governance. Separately, only around 15% of organisations investing in agentic AI report being genuinely ready to run it in production, despite many putting significant budget behind the effort. If well-resourced enterprises with dedicated AI and security teams are failing at that rate, an SME running an AWS estate nobody has looked at in years is not going to beat the odds by accident.

The problem is rarely the model

The industry data on why agentic AI projects stall is consistent, and it has almost nothing to do with model quality. The most commonly cited blockers are data quality and provenance, regulatory and data sovereignty requirements, and security and privacy risk. Only around one in five organisations report having a mature governance model for autonomous agents at all.

That matters more for an SME, not less. A large organisation with a thin governance model at least usually has some form of IAM structure and periodic access review. Many SME AWS accounts we see were set up to ship a product, by whoever was building it at the time, and have not been revisited since. An agent is now being asked to act autonomously inside that account.

What actually breaks in production

Strip away the vendor language and the structural risks of giving an agent autonomy over real systems are specific and well understood.

• Over-permissioning: agents are usually given broader access than the task requires, because narrowing it down properly takes more setup work than leaving it open
• Cascading failures: in a multi-agent or multi-step chain, one bad decision or bad input can propagate through every downstream step before a human sees it
• Untraceable data leakage: without proper logging and data classification, nobody can say afterwards what the agent actually read, sent or stored
• Shadow deployment: an agent connected to a real API key outside of any change process, quietly left running

None of these require a sophisticated attacker or an exotic failure mode. They require exactly the conditions that describe a large share of SME AWS estates today: loose access, thin logging, and nobody specifically assigned to watch the account.

What a realistic path in looks like

A focused, single-workflow agentic pilot is typically a six-to-ten week piece of work, not a big-bang platform rollout. Before any of that starts, four things are worth doing properly rather than skipping.

• Classify the risk of the specific use case — an internal drafting assistant and an agent with write access to customer records are not the same conversation
• Map exactly what data and systems the agent needs to touch, and whether that access already exists cleanly or needs to be built
• Decide what "wrong" looks like for this workflow, and where a human has to stay in the loop before anything is treated as final
• Confirm the account has the logging, access control and cost visibility to show what the agent is actually doing, before giving it anything to do

How we approach this

We treat an agentic AI pilot as an infrastructure and governance question first, and an AI question second. Before we recommend building an agent for a client, we look at what it would actually need to touch, and whether the account it would run in could support that safely today.

That often surfaces work that has nothing to do with AI — tightening IAM, adding logging, classifying data — and it needs doing regardless of whether an agent ever gets built. Where it doesn't, we say so before any agent gets near production, not after.