Preface Where Do AI Projects Actually Get Stuck?

A complex system that works is invariably found to have evolved from a simple system that worked. — John Gall, Systemantics

In 2026, nearly every industry summit is saying the same thing: AI is what will decide this round of business competition. Capital is chasing the "agent" narrative, chip makers keep setting new market-cap records, and any startup pitch with the word "AI" in it gets an easier hearing. That heat is real.

But point the camera at enterprise production systems and the picture looks completely different. A report from MIT NANDA puts a number on it: 95% of organizations get no measurable P&L impact from generative AI¹. In plain terms: the GPUs are bought, the tokens keep burning, and the books show nothing coming back.

Behind the number are real people and real frustration. In 2021, an engineer who had done deployment work wrote on Hacker News that it had made him a worse engineer². Five years later, an AI delivery engineer in China put it a different way, but the meaning hadn't changed: after four iterations, the biggest thing the project delivered was emotional reassurance for leadership³.

Every demo looks stunning. So why does everything stall the moment it hits production? Where, exactly, is the block? Different people give different answers. What follows is an attempt to put those answers side by side and see whether they are, in fact, describing the same thing.

I. The Block Is Real

The block in AI adoption isn't a feeling — it's a fact with numbers behind it.

MIT NANDA's 2025 report, The GenAI Divide, gives three figures¹:

95% of organizations report no measurable P&L impact from AI — the report's own phrase is "no measurable P&L impact," which is not the same claim as "95% of projects failed," though the two are often conflated;
Only about 5% of custom enterprise AI tools ever reach production;
On procurement, buying (about 67%) far outpaces building in-house (about 33%) — but buying doesn't solve the problem either: purchased tools stall at the demo stage just the same.

The third figure is worth pausing on: most companies' first instinct is to buy, and the report shows the block persists after purchase. That points to a shortage not of AI tooling, but of the capability to install that tooling into the business. The report's own explanation points the same way: the block isn't model capability — it's a learning gap (organizations haven't yet learned how to use it) and integration.

II. The First Wall: Integration

So where, specifically, does "installing it into the business" get stuck? The answer on the ground is more mundane than it sounds.

Most enterprises where "AI doesn't work" hit a wall that has nothing to do with the model — it's the systems wall that's gone unfixed for twenty years: data sits in seven or eight systems that don't talk to each other, workflows span three different tools, and the interfaces were written by someone who left a decade ago. AI hasn't fixed that wall, and agents won't fix it automatically either (more in Chapter 9)⁴.

Model capability has jumped several orders of magnitude in a few years. This wall hasn't moved an inch. It doesn't discriminate by model — swap in a stronger one, and the wall is still there.

III. The Second Wall: Permissions

The second wall is more hidden: agents can't budge the enterprise's permission system.

An agent only holds the permissions of the human user behind it, and unlike a human colleague, it can't talk its way around a permission wall with a favor or a workaround when it gets stuck⁴ — so agents deployed into enterprises often die at step one: they can't even get the data they need (more in Chapter 10).

Integration and permissions share one thing in common: neither is a technical problem — both are "nobody is responsible for fixing this" problems. The model vendor isn't responsible. The software vendor isn't responsible. The customer's IT department has its own boundaries. The block lives in the cracks nobody owns.

IV. The Week After the Demo

The following is a composite drawn from multiple real lessons; the people and company are fictional, used to show the shape of the block.

A customer-service agent performs flawlessly on demo day: smooth answers, accurate conclusions, a beautiful dashboard. Then it connects to the real ticketing system for its first week —

Day one, the permission wall: ticket data lives in three systems, and the agent's account only got read access to one of them. Waiting on approval.

Day three, a tool misfire: permissions finally cleared, and in one batch operation the agent wrote test data into a production field. The rollback ate an afternoon.

Day five, unmeasurable regression: after a version change, the support lead says it "feels worse," the engineer says "I can't tell the difference" — nobody has a baseline, so nobody can prove anything either way.

Week two, the business doesn't use it: front-line support still works from the old ticketing UI — "the new system takes one extra click." The system is live and green. Zero users.

Every one of these walls gets its own chapter later in this book: permissions (Chapter 10), tool boundaries (Chapter 11), provable outcomes (Chapters 12–13), nobody uses it (Chapter 15). For now, the point is just to see them lined up together — what separates demo from production was never "a bit smarter." It's a series of walls, each with a name.

V. Quality Has a Measurable Depth

Beyond the walls, there's a subtler, quantifiable block: quality.

An insurance practitioner posted a number on X (formerly Twitter): their internal agent's real-world accuracy at first launch was about 70%, against a contractual commitment above 98%⁵. Those 28 points between 70 and 98 are exactly what "delivery capability" means in practice — not something you get by tuning a prompt, but something built up through a whole loop of evaluation and regression testing (fully unpacked in Chapters 7 and 12).

There's a slower gap too: model capability jumps a full generation within a year, while adoption on the ground lags far behind⁶. This matches a feeling a lot of people share — AI capability sprints forward, and the world feels strangely unchanged, much the way self-driving's technology curve has climbed steeply for years while the traffic outside looks exactly the same as it always did. This "adoption gap" corroborates MIT's data: the block isn't capability, it's adoption and integration. Chapters 15 and 28 take this up in full.

VI. Enter the Protagonist

Put the threads together:

The block is real and measurable;
Its names are integration, permissions, evaluation, organizational incentives — none of them a model problem;
What these walls share is that nobody is directly responsible — no one owns "shipped, usable, maintainable" end to end.

Which gives us this chapter's core claim: model capability is a commodity; the capability to install a model into a specific business is scarce. The 2026 surge of the FDE (Forward-Deployed Engineer) role is the market pricing exactly that scarcity.

It isn't a new invention. Palantir ran this exact playbook over twenty years ago, built around the forward-deployed engineer as an organizational form: put the engineer on-site with the customer, accountable for what actually runs in production. In 2026, the market needs it again — consulting giants have turned it into a service line, and model companies are building their own delivery organizations in-house (Chapter 4 lays out the timeline day by day).

The six parts and twenty-eight chapters that follow take apart the question "which bridges need fixing, and by whom": what the role is (Part One · Role and Boundaries) → how delivery happens (Part Two · From Discovery to Production) → the engineering wall (Part Three · Engineering Foundations) → adoption and handoff (Part Four) → the business (Part Five · Business and Productization) → people and organization (Part Six).

The Gall's Law quote that opened this chapter says the same thing another way: a complex system that works was never designed that way — it evolved, step by step, from a simple one that worked. And "evolved" only happens because someone stayed accountable for every one of those steps.

The first item on that list is the most basic one: what is an FDE, actually — what result is this person on the hook for?

MIT Project NANDA, The GenAI Divide: State of AI in Business 2025 ↩ ↩²
Hacker News, "Every engineer should do a stint in consulting" ↩
"AI Job Sense: Stop the Agent Rat Race" ↩
a16z, Box CEO on AI agents and why enterprises can't keep up ↩ ↩²
"Inside an Applied AI Company" (Pace long-form post) ↩
Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩