Why Agentic AI Projects Get Canceled, and What an Eight-Week Pilot Gets Right

A customer asks for a refund, and the agent finds the order in the CRM, checks the returns policy and drafts a reply in under a minute. Then it stalls, because the refund approval sits in a finance system it was never connected to and the customer’s address doesn’t match between two databases. Gaps of this kind rarely surface in a demo, yet they decide how much an agent costs to run and whether anyone can trust it, which puts the bigger risk in agentic AI inside the business the agent is dropped into rather than inside the model.

Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, pointing to rising costs, unclear business value and weak risk controls. Read closely, that forecast is about how these projects get approved on the strength of a demo, with little view of what the work costs today or who owns the outcome.

The question I’d put to any leadership team is whether the business can support this agent doing the work every day, at a cost and level of risk it can live with. Answering it means looking hard at what I call the work after automation, meaning everything people still have to do once the agent has finished its part, and an eight-week pilot is a practical way to measure it before committing to a full rollout.

The Problems an Agent Inherits From the Enterprise

An agent rarely works on its own, since even a simple-looking task touches customer records, a couple of business applications and usually an approval step, and every connection limits what the agent can see and do. Where records are inconsistent or nobody is quite sure who signs off, the agent inherits the confusion along with the task.

Routine cases are seldom the problem; exceptions are, because that’s where operating costs pile up, and they’re precisely the part a demo is built to avoid. Deloitte’s 2026 research found that only 5% of organizations rate their business processes as highly prepared for AI agents, a number more telling than any model benchmark because it suggests the AI is ready well before most processes are.

The Business Case Has to Include the Work After Automation

Timing how fast an agent produces an output is the easiest way to overstate its value, since the figure that matters is how much effort the finished task takes. Say a request takes an employee 20 minutes to process, and the agent gets the first pass down to two, which looks like an 18-minute saving right up until someone spends 15 minutes checking the result and fixing errors. Three minutes saved is a thin return once the cost of running the agent goes on the other side of the ledger.

McKinsey’s analysis of a banking customer-service agent shows the same pattern at scale: tokens made up 20–25% of variable operating costs and human oversight 70–75%, so most of the money sat outside the model. Without a baseline in place before anyone writes code, a pilot can show plenty of technical progress and still leave the investment case untested. At a minimum, the business owner needs a clear answer on each of these points:

• Volume: how often the process runs and how many people touch it.
• Completion time: how long the whole task takes, checking and corrections included.
• Accuracy: how often it goes wrong or needs redoing.
• Cost per task: what a successfully completed task costs today.
• Business impact: what a real improvement would change for customers, staff or the business.

An Agent Has to Earn Its Place in the Workflow

Adoption usually gets filed under change management, although in my experience it’s settled much earlier, by where the agent sits in the workflow. A global professional services company had built agents for support and compliance work, and its support agent could pull information from several internal systems, but people had to open a separate application to use it and mostly didn’t bother. Once the same workflow was moved into the existing support platform, it appeared inside the ticket associates were already working on, and a compliance screening agent went the same way, built into Salesforce so that it ran whenever a case was created.

Nothing about the agents themselves changed; their position in the workflow did. Associates already had a reason to open a ticket or create a case, so meeting them at that moment asked nothing extra of them. Placement is therefore an architecture decision as much as an adoption one, because the agent needs context where the work happens, and its output has to feed the next step without someone copying it across by hand.

Autonomy Changes the Security Equation

An agent that can only read information carries one kind of risk, and one that can change records or email customers carries another entirely, so the controls have to follow what it’s actually allowed to do. Excessive permissions and leaking sensitive data are the familiar risks, but prompt injection deserves the closest attention: instructions hidden in a document or an email that the agent picks up while doing a perfectly legitimate job.

Gartner’s May 2026 guidance on agent governance breaks autonomy into four levels, which gives a practical way to decide how tight the controls need to be:

1. Observe: the agent retrieves information and spots patterns, with read-only access.
2. Advise: it recommends an action, and an employee makes the decision.
3. Act with approval: it prepares or starts an action that a person has to authorize before it runs.
4. Act autonomously: it carries out approved actions on its own within set limits, with monitoring and escalation for exceptions.

At every level, an agent needs its own identity, permissions limited to its task and a record of each action it takes. Organizations also need rules for how data is handled and retained, clarity on what reaches outside model providers, and someone with the authority to pause the agent and pull its access the moment something looks wrong.

Each of these controls carries a running cost, since wider permissions, extra monitoring and frequent approvals all add up over time. The right level of autonomy is therefore an economic decision as well as a security one, and it sits wherever the agent delivers a worthwhile outcome at a risk the business can accept.

Choose a Process That Can Justify an Agent

Plenty of teams start with the technology and go looking for a problem when the better starting point is a process whose cost or delays are already obvious to the people doing the work.

A global expert-network company we worked with fit that description: its team was matching survey requests to experts across three systems that didn’t talk to each other, checking profiles, past participation and compliance by hand for every match. We built an agent that combined semantic search with that participation history and the compliance rules, and in production mismatch tickets dropped 80%, mapping accuracy rose 40% and the team got back 22% of its bandwidth.

The project worked because the problem was specific, with scattered information, manual stitching and match quality that could be measured before and after. Specificity also helps answer whether a process needs an agent at all. Work governed by fixed rules is usually cheaper to handle with conventional automation, and work that mostly involves finding and summarizing information is often well served by an AI assistant, while agents earn their extra cost and risk when the job means reading context, choosing between permitted actions and chaining several steps toward an outcome.

An Eight-Week Pilot With Clear Decision Points

The whole pilot hangs on one commercial question: can this agent improve the process enough to justify running it at scale? Eight weeks gives enough room to test the business case, the technology and the organization’s ability to manage what it builds.

Weeks 1–2: Establish What Needs to Improve

Start by documenting the process as it runs today, from volume and completion time to error rates, rework and cost. Note which systems are involved, who owns each stage and which exceptions need a human, then get the business owner and the technical team to agree on the one outcome the agent is supposed to improve. Decision point: keep going once the problem, the baseline, the owner and the success measures are clear.

Week 3: Define the Agent’s Boundaries

This is where the agent’s limits get set, covering its identity, permissions, data access, approved tools and degree of autonomy. Test it against prompt injection, unauthorized access, sensitive-data exposure and tool misuse, and put logging and incident response in place along with a way to suspend the agent or revoke its access. Decision point: keep going once the controls and intervention steps have actually been tested and everyone knows what the agent is allowed to do.

Weeks 4–6: Test the Conditions That Break the Demo

Now give it realistic work, including incomplete records, conflicting information, odd requests and the occasional system failure. Track how many tasks it completes, how accurate it is and how much correcting people have to do, then work out what a successfully completed task really costs once model usage, integrations, monitoring and review are all counted. Decision point: move to live testing when the agent hits the agreed thresholds and the team understands both its running cost and the ways it fails.

Weeks 7–8: Put It in Front of Real Users

Give it to a small group of employees and a controlled slice of real work, with the old process still there for anything the agent can’t handle. Watch whether people actually use it, whether it saves them effort and whether they trust what it produces.

At the end, put the results next to the baseline from week one and look at productivity, accuracy, adoption, how often people had to step in, total operating cost and any security risks still open. The call is then to scale, fix specific gaps and retest, or stop, and a pilot that shows the agent is too expensive or too unreliable for the job has still done its work, because it has prevented a much bigger investment built on guesswork.

Measure the Outcome, Then Decide How Much Autonomy to Give

Counting how many tasks an agent processes says very little, since a system can churn through thousands of requests and still leave employees verifying, correcting or finishing most of them. Cost per successfully completed task, read alongside accuracy and exception rates, gives a far better picture of whether the process has improved end to end.

Those same measures become the case for giving an agent more room. One that reliably handles routine requests inside agreed limits can be trusted to act on them alone, while one that keeps meeting ambiguous cases keeps a human approving those decisions, with permissions reviewed as the evidence builds.

Scale When the Business Can Support the Agent

An agent that works well for one team will sooner or later have to deal with other departments, applications and approval chains. Scaling it takes clear ownership, consistent access controls and a way of handling exceptions, along with a budget for keeping the agent current as the processes around it change.

The decision underneath all of this is how much responsibility the organization is ready to hand over, and it has to rest on evidence from real work rather than a good demo. Leadership should come out of the eight weeks knowing what the agent can handle, where people still need to step in and what it will cost to run. The enterprises that pull ahead with agentic AI will be the ones that design for the work after automation from the first week and fund agents on the tasks they actually complete.