Why 95% of agent pilots die — and the boring engineering that ships the other 5%

The numbers are grim and worth stating plainly. MIT's State of AI in Business 2025 found that 95% of enterprise generative-AI pilots deliver no measurable P&L impact. Gartner expects over 40% of agentic-AI projects to be cancelled by the end of 2027, citing unclear value, spiralling cost, and inadequate risk controls — and coined the term "agent washing" for the flood of chatbots and RPA scripts rebranded as agents.

Here's the part that matters if you're about to build one: the failure is almost never the model. The demo worked — that's why it became a pilot. What kills it is everything around the model: the scoping, the identity story, the approval flow, the audit trail, the rollout. That work is boring, unglamorous, and entirely learnable. Below are the five decisions that, in our experience shipping agents across several industries, separate the 5% that reach production from the 95% that don't.

1. Scope the tools — a team, not a one-agent army

The single most common self-inflicted wound is handing one model twenty or thirty tools and hoping it picks the right one. It won't reliably — the more tools in the prompt, the worse the selection, a failure mode that gets dramatically worse under real-world ambiguity. The fix is architectural: a small team of narrow specialists, each with a short, auditable tool-list, coordinated by an orchestrator. It's the difference between a generalist who's mediocre at everything and a team of experts. We wrote up the mechanics in why narrow specialists beat one 30-tool agent.

2. Forward the identity — the agent is never more privileged than the user

Pilots almost always run the agent on one service account with broad access, because it's the fastest way to a demo. It's also the fastest way to a security review that never ends. In production, the agent acts as the signed-in person: their identity is forwarded into every downstream call, and the data services enforce their normal per-user authorization. The agent has no ambient authority of its own. This is the control that turns "can we let it touch real systems?" from a leap of faith into a policy you can point at — the full pattern is in letting an agent act as you, safely.

3. Gate the writes — reading is automatic, acting is not

An agent that can read is useful and low-risk. An agent that can write — send the email, create the order, move the money — is where the value and the danger both live. The decision that ships: anything that changes data or spends money pauses for a human plan, and that approval is bound to the person who gave it and re-checked when it actually runs. Below is the shape of the dispatch — the same tool registry, two very different paths depending on whether a call mutates.

 // Reads run straight through. Writes require an approval token that is bound // to THIS user and re-verified at execution — an approval can't be replayed // by another principal or drift out of scope between "yes" and "go". func (a *Agent) dispatch(ctx context.Context, call ToolCall) (Result, error) { user := callerID(ctx) // forwarded, verified identity — never the SA if user == "" { return Result{}, status.Error(codes.Unauthenticated, "no caller identity") } tool := a.tools[call.Name] if tool.Mutating { appr, ok := a.pendingApproval(ctx, user, call) if !ok { // Persist a pending action, return the plan for the human to approve. return a.requestApproval(ctx, user, call) } if appr.UserID != user || !appr.Matches(call) { return Result{}, status.Error(codes.PermissionDenied, "approval not valid for this action") } } return tool.Run(ctx, call) // audited on completion (decision 4) } 

The trap to avoid is prompt fatigue: gate every step and people rubber-stamp, which is worse than no gate. Gate writes and spend, not reads — most of what a good agent does needs no approval at all.

4. Audit everything — the record before anyone asks for it

Every mutating action lands in an append-only, integrity-checked trail: the real user (not the service account), the tool, the arguments, what changed, and when. Not debug logs you grep and lose — a first-class, tamper-evident record. When a client's compliance team asks "what has this agent done, and on whose authority," the answer should be a query, not an investigation.

If an agent can take an action and you can't later prove who authorized it and what it did, you don't have a production agent — you have an incident with a future date.

5. Phase the rollout — read-only first, then guarded writes

Big-bang launches are how pilots become cautionary tales. The agents that survive ship in phases: a read-only foundation first — it drafts, summarises, retrieves, but changes nothing — so the team builds trust on real work with zero blast radius. Only once that's earned do the guarded write actions come on, one at a time, each behind the approval gate. Every blueprint we produce is structured this way, and it's why "will it actually ship?" has an answer that isn't a shrug.

The part nobody scopes: what it costs to run

One more quiet killer: an agent that works but costs more than the work it replaces. Token spend is a real operating line, and left unmetered it's the surprise that ends the project after the demo dazzled. Meter it per agent, budget it, and cap it — the how is in what an AI agent actually costs.

Why this is good news

None of the five decisions above is a frontier research problem. They're engineering — the kind that's tedious to do well and easy to skip, which is exactly why most pilots skip them and most pilots die. Do them, and the model in the seat almost stops mattering: the same reason we can stay model-agnostic is the reason our agents hold up when the model changes underneath them. The winning move was never a more autonomous agent. It was a more trustworthy one — scoped, identity-bound, approved, audited, and rolled out like you mean to keep it. If you're weighing one up, the playbook answers the questions that come before any of this.