Verdict: The model is no longer the bottleneck — the process is. When MIT's Project NANDA found that 95% of enterprise generative-AI pilots produce zero measurable P&L impact (MIT NANDA, "The GenAI Divide," 2025), the cause was not that LLMs are too dumb. The cause was that companies bolt a model onto a workflow designed for humans and then expect ROI from a tool that does not understand the workflow. The fix is not a better model. The fix is to redesign the workflow around what AI can actually do — a job done by forward deployed engineers (FDEs), increasingly augmented by internal "FD agent" tooling that captures company-specific context no frontier model knows.
Last verified: 2026-07-31
- The 95% GenAI-pilot-failure stat is MIT Project NANDA, published August 2025.
- The 80%+ AI-project-failure stat is RAND Corporation, 2024–2025.
- Kimi K2 (now K2.6) is an open-weight MoE model from Moonshot AI, released April 2026.
- This is an original synthesis for builders and operators; it adds a worked decision framework and a comparison table built from primary sources.
What Is "Forward Deployed Engineering," and Why Does the Enterprise Need It?
Forward deployed engineering (FDE) is the practice of embedding engineers directly inside a customer's operating environment to map how work actually gets done, re-engineer that work around what AI can do, and ship AI into the systems the company already runs (Salesforce, NetSuite, SAP, Dynamics). Unlike traditional consulting — which produces a specification and hands it off — FDE redesigns the process and implements it on top of the customer's systems of record.
The enterprise needs FDE because the AI wave left large companies behind. They spent years and millions migrating to systems of record they cannot abandon for a greenfield AI tool. One enterprise client reported spending $5 million and 5 years migrating to NetSuite alone. If an AI vendor's pitch requires the customer to migrate off those systems, it is dead on arrival for exactly this reason. We wrote a deeper treatment of when this model makes sense as a go-to-market in When Does Your Company Actually Need Forward Deployed Engineers? The 2-Question Test.
Why Do Enterprise AI Pilots Fail So Often?
Most enterprise AI pilots fail because they are applied to broken processes, not because the models are weak. MIT Project NANDA analyzed 300 public AI deployments and 150 executive interviews and found that while the technology is sound, "95% of corporate pilots stall, producing little or no productivity uplift. MIT attributes this to poor integration, not model quality" (MIT NANDA via Fortune, August 2025).
RAND Corporation's analysis of 2,400+ enterprise AI initiatives found an even broader 80% failure to deliver intended business value — roughly twice the failure rate of ordinary IT projects (RAND Corporation, 2024–2025). The research converges on a single root cause: data and integration, not the model. Gartner separately predicts that over 60% of AI projects unsupported by AI-ready data will be abandoned through 2026 (Gartner, 2025).
The pattern is the same in finance: a team gives a non-technical operator Claude, asks them to feed 150 pages of process documentation into a prompt, waits two minutes, and gets verbose output that is wrong on the specifics. The model is "smart enough" — it is the lack of process understanding and the lack of structured context that break the result.
What Are the Three Jobs a Forward Deployed Engineer Actually Does?
A forward deployed engineer does three jobs, in this order:
- Map how humans do the work today — interview every process lead in the department (AP, AR, card reconciliation, banking, billing, FP&A). Critically, capture what happens when things go wrong, not just the golden path. Most corporate documentation describes the happy path; the reality is that "Sarah in AP handles the workflow this way, but when things go wrong she escalates to Chris, who takes 4 days to reconcile the PO against the invoice." That cycle time and that human handoff are the entity-specific context an AI must understand before it touches the process.
- Re-engineer the process around AI — split the process into what is fully automated, what is human-in-the-loop, and what stays purely human. Aim for adoption, not disruption: an 11-step workflow cannot collapse to a 1-step workflow without the team rejecting it. A defensible FDE redesign might automate 4 of 8 steps, route 3 through human-in-the-loop, and leave 1 as human-only because the risk is too high or the task is not unique enough for an agent to add value there.
- Deploy agents on top of existing systems of record — the AI must live on top of Salesforce, NetSuite, Dynamics, or SAP. Customers who spent $5 million and 5 years migrating will not migrate again for an AI demo.
For the org-design side of this — how to size the FDE team and avoid the "custom dev shop" trap — see How to Structure a Forward Deployed Engineering Team That Scales (Without Becoming a Custom Dev Shop).
What Does an "FD Agent" Do, and How Is It Different from a General LLM?
An FD agent is an internal tool that augments a human FDE. It is not a general-purpose frontier-model chatbot. It is three layered systems:
| Stage | What it does | Why a frontier LLM alone cannot |
|---|---|---|
| 1. Engagement agent | Pulls in the FDE's meeting notes (e.g. Granola), synthesizes incoming PDFs/PowerPoint slides, and answers "which person owns this process?" or "are Sarah and S. Moza the same person?" | Frontier models get confused by the dozens of near-duplicate names and role aliases inside any enterprise; entity resolution requires the company's knowledge graph, not a generic model. |
| 2. Workflow agent | Sits inside the workflow builder with the human FDE and catches edge cases the FDE forgot — e.g. "you forgot to ask who owns this step, so the email routing is wrong." | An FDE building a workflow is under time pressure and has clients pinging 24/7; the agent co-pilots the build, the way a coding copilot_review refs code. |
| 3. Autonomous assistant (still in development) | Receives a low-stakes change request from the client (e.g. "route the QC report to a different inbox"), queries the company knowledge graph, ships the change to the workflow on the platform, and frees the FDE for higher-value client interviewing work. | Requires both good output quality and reliable context extraction (see next section) — neither is solved by raw prompting. |
The architecture that holds these three stages together is a single source of truth — typically a dependency graph — that represents how the company actually functions. Most enterprise workflows are remarkably linear but contain cycles; a dependency graph is the right representation because it captures the ordering the process owners care about (person C should not see a record before A and B approve it).
How Do You Get Quality Output from a Post-Trained Model Instead of Vanilla Claude?
The speaker's team found that frontier models (Anthropic Claude was named) cannot produce a good normalized process flow from raw extracted context — they are too verbose and lack the consulting instinct of "what detail does the client care about, and what can be glossed over." The approach they take is two-fold:
- Post-train an open-weights model on process-flow writing. Kimi K2 (now K2.6), an open-weight Mixture-of-Experts model from Moonshot AI with 1 trillion total parameters and 32B active, is one foundation that works (Moonshot AI / NVIDIA NIM model card; Kimi K2.6 release, April 2026). Post-training teaches the model the right balance of detail and clarity for process documentation.
- Train a graph-traversal tool in an RL environment. The model is useless if it cannot extract the right context from the knowledge graph in the first place. So the team exposes graph-traversal tools — entity-resolution ("are Sarah and Sarah M. the same person?"), cycle-detection, DAG-violation detection — and trains them in reinforcement learning to reliably traverse the graph and surface the right context for the next step.
This is exactly the kind of bespoke layer on top of open-weights models that lets a focused team punch above generic frontier-model prompting. For an architectural counterpart on the orchestration side, see How to Orchestrate AI Agents Like a Company: A 5-Layer Framework That Actually Works in 2026.
What Is the Real "Next Bottleneck" in Enterprise AI?
The next bottleneck is not intelligence or execution — those are largely solved for knowledge work. The next bottleneck is how deep you can go into a customer without scaling headcount exponentially. Specifically:
- Context extraction — getting the unwritten process knowledge ("what does Sarah actually do when the invoice does not match the PO?") out of the operators and into a machine-usable graph.
- Entity resolution — recognizing that "Sarah," "S. Moza," and "Sarah M." in the Slack channel and the email thread are the same person. Frontier models cannot do this reliably without your knowledge graph.
- Workflow redesign with adoption in mind — collapsing an 11-step human workflow to a 5-step human+AI workflow without the team rejecting it.
If you are an operator, this is the work, not "give everyone Claude." For a deeper, decision-framework version of this view, see Why Most Enterprise AI Projects Never Scale in 2026 (and the 3-Pillar Framework That Fixes It).
What This Means for You
If you are an operator inside a large enterprise, the single highest-leverage thing you can do is not buy another AI tool. It is to map one department's actual workflow (golden path AND the exceptions), build a dependency graph of who owns what, and pilot a single re-engineered sub-process that lives on top of your existing system of record. The model matters less than the context you feed it.
If you are building an AI product for enterprises, you should assume your customer is not migrating off their system of record. Your tool must read from and write to the system they already run. A "point solution that improves one part of sales" might deliver 5–10% ROI on that function; the durable value comes from re-engineering an entire department at a time, which is what justifies the FDE investment.
If you are hiring or training FDEs, the rare profile is double-threat: top-1% technical ability (AI fluency, the ability to read a workflow and see where the agent belongs) AND top-shelf communication skill (the ability to sit with a non-technical operator in finance or procurement and extract the real process, not the documented one). Most consultants have the EQ and most engineers have the IQ; the FDE role rewards both. We cover the product-strategy side of this investment in Forward Deployed Engineering as a Product Strategy: The Playbook That Actually Builds Sticky Software.
Quick Comparison: Three Approaches to Enterprise AI Adoption
| Approach | What it is | Typical ROI | Failure mode |
|---|---|---|---|
| "Slap a frontier model on it" | Give operators Claude/ChatGPT, expect them to prompt their way to productivity. | Little to none in production. | MIT NANDA's 95% (context not captured, model wrong about company specifics). |
| Point solution | Buy a SaaS that improves one sub-process (e.g. prospecting only). | ~5–10% on that function. | ROI is real but local; the rest of the department is unchanged. |
| Department-wide FDE re-engineering | Embed engineers, map the real workflow, build a dependency graph, re-engineer the whole department on top of the system of record. | Cited by practitioners at 25–75% on the department. | Hard to hire the FDE profile; hard to scale without internal FD-agent tooling. |
ROI figures in the bottom row are practitioner-reported, not independently measured — treat them as directional, not audited.
FAQ
Q: Why do most enterprise AI pilots fail to reach production? A: MIT Project NANDA found 95% of generative-AI pilots produce zero measurable P&L impact, attributing the cause to poor integration and missing company-specific context, not model capability (August 2025). RAND separately found 80%+ of all enterprise AI projects fail to deliver intended business value, roughly twice the failure rate of non-AI IT projects.
Q: What does a forward deployed engineer actually do? A: An FDE embeds inside a customer's team, maps how work is actually done (including the edge cases undocumented operators handle), re-engineers the process around what AI can do, and ships AI on top of the customer's existing systems of record (Salesforce, NetSuite, SAP, Dynamics). The role blends top-tier technical ability with the consulting skills needed to extract real process from non-technical operators.
Q: Why not just give an enterprise operator a frontier model like Claude? A: Frontier models are too verbose for normalized process documentation, fail at company-specific entity resolution (resolving dozens of near-duplicate names inside a large company), and do not understand the unwritten exception-handling that defines how the work actually runs. They also produce brittle results when fed hundreds of pages of context in a single prompt, which is the state of most enterprise knowledge.
Q: What is an "FD agent" and how is it different from a general LLM? A: An FD agent is internal tooling layered on top of (or beside) a frontier model that gives one human FDE the leverage to manage many client relationships. It has three stages: an engagement agent that reads notes/docs and answers "who owns this?", a workflow agent that co-pilots the workflow builder and catches forgotten edge cases, and an autonomous assistant that handles low-stakes inbound change requests so the FDE can focus on high-value client interviewing.
Q: What is the single source of truth for an enterprise's actual processes? A: A dependency graph — a representation of who owns which step and in what order. Most enterprise workflows are mostly linear with cycles; a dependency graph captures the ordering operators care about (person C should not see a record before A and B approve it) and is the substrate on which any AI agent must operate to add real value.
Q: Why do companies post-train open models like Kimi K2 instead of just using Claude? A: Frontier models lack the consulting instinct of distinguishing detail the client cares about from detail that can be glossed over. Post-training an open-weights Mixture-of-Experts model (Kimi K2 / K2.6 by Moonshot AI, 1T total / 32B active parameters) on the specific task of writing normalized process flows teaches that instinct — and lets you pair output quality (post-training) with reliable context extraction (an RL-trained graph-traversal layer) that a generic model cannot match.
Discussion
0 comments