Matz Fitzpatrick has a great interview on 20vc about why AI Needs Forward-Deployed Engineers
The numbers are in, and they paint a stark picture of the current state of enterprise AI. According to a recent MIT report, only 5% of Generative AI deployments are actually working in any production form. Furthermore, Gartner predicts that 40% of all enterprise AI projects will likely be canceled by 2027.
We are witnessing a massive "chasm" between the exponential improvement of AI models and the stagnant reality of enterprise adoption. While consumers have embraced tools like ChatGPT, enterprises are stuck.
Why? Because for the last decade, we have been conditioned to buy software as a "box"—a SaaS application we can simply plug in. But Matt Fitzpatrick, CEO of Invisible, argues that this era is over. AI is not an app; it is a fundamental restructuring of data and workflow. To bridge the gap, we don't need more salespeople or better off-the-shelf software. We need Forward Deployed Engineers (FDEs).
The traditional SaaS business model is built on a specific economic equation: build the software once and sell it to thousands of customers with zero customization. As Fitzpatrick notes, "The minute you had to bring in FDEs in a SaaS context, your economics broke instantly".
To preserve their margins, vendors are flooding the market with "out-of-the-box" AI agents. But in complex enterprise environments, these generic tools fail. Salesforce AI research recently found that while some agents handle single tasks okay, they are only 33% accurate on multi-turn workflows.
If you are building a simple file repository, you don't need customization.
But if you are trying to automate a claims processing workflow, manage patient journeys, or write investment memos in a private equity firm's specific style, a generic "box" will fail. It requires hyper-personalization, and that requires engineering.
The Risks of the "Science Project" (Internal Builds)If buying off the shelf doesn't work, why not build it internally? Many CEOs assume their internal tech teams can handle the load. However, the data suggests that externally driven builds are 2x as effective as internal team builds.
Internal teams often lack the discipline to focus on ROI, treating AI initiatives as "science projects" rather than business products. Fitzpatrick shares a cautionary tale of a retailer that spent $25 million building a proprietary customer service agent. They built their own evaluation tools to measure speed and sentiment, but they missed a critical flaw. The agent began hallucinating, refunding millions of dollars to customers just to "resolve" calls quickly. The project was shut down months later.
Top-tier AI engineering talent is a finite resource, heavily concentrated in AI startups and big tech, not in the IT departments of traditional enterprises.
The FDE model offers a third way—neither a generic SaaS app nor a risky internal build.
What is an FDE? Forward Deployed Engineering is often confused with sales engineering or consulting. It is neither. An FDE team is a small unit (often just 1-2 people) responsible for configuring modular platforms to build a hyper-specific solution for a client's unique data environment.
They do not build from scratch. They utilize core platforms (data ingestion, agent builders, process builders) and tailor them to the fragmented reality of the client's infrastructure—linking Electronic Health Records, CRMs, and ERPs into a unified intelligence layer.
The Speed of Execution Under the old "Accenture Paradigm," companies would pay consultants hundreds of millions over several years to layer applications together, often ending up with no working data linkages.
In contrast, because FDEs leverage modular architecture, they can typically deliver a fully working, hyper-personalized solution in two to three months.
Perhaps the most radical aspect of the FDE model is how it aligns incentives. In a market where executives are pitched by 250 vendors a week, trust is at an all-time low.
The FDE model enables a "Proof Before Pay" approach. The engineering team engages in a "solution sprint" (usually around 8 weeks) to prove the technology works in the client's actual environment. As Fitzpatrick explains: "We say we will do it for free for 8 weeks and prove to you that [it] works... You don't pay a dollar until you prove the tech works".
This shifts the risk entirely onto the provider. If the FDEs cannot configure the model to handle the specific workflow (e.g., verifying 17th-century French architecture or managing underwater drone swarms), the client pays nothing.
We are currently in a transition period similar to the shift from slide rules to Excel. In the 1980s, accountants manually calculated financial statements. When Excel arrived, accounting didn't disappear; it became infinitely more sophisticated
.Right now, enterprises are trying to force AI (Excel) into their businesses using the procurement and implementation methods of the past (Slide Rules). It isn't working. To make the leap, we must abandon the idea that AI is a commodity to be bought and accept that it is a capability to be built. The Forward Deployed Engineer is the architect of that build.
--------------------------------------------------------------------------------
Q: Isn't this just "consulting" or "services" in disguise?
A: No. Traditional services (like the "Accenture paradigm") involve years of billing for manual integration. FDEs are configuring a software platform. The goal isn't to bill for hours; it's to stand up a "hyper-personalized system of agility" quickly. Once the software is up and running (usually in 90 days), the heavy lifting is done, though ongoing fine-tuning is required.
Q: Can't we just use synthetic data to train our models and avoid the need for human-in-the-loop engineering?
A: Not for high-value tasks. Synthetic data works for "base truth" logic (like math). But for complex reasoning—like legal memos, multi-language cultural context, or medical triage—synthetic data fails. These tasks require Human-in-the-Loop (RLHF) and expert validation. Fitzpatrick argues we are in the "first inning" of this complexity and will need human expertise in the loop for decades.
Q: How do we measure success if we adopt this model?
A: Stop using tech metrics and start using business metrics. Do not locate the initiative in the tech function. Give it to an operational leader (e.g., Head of Call Center) and measure it against operational KPIs: call resolution time, cost per call, or routing logic accuracy. If the vendor doesn't move those specific needles, fire them.
Q: Why can't I just wait for the models (GPT-5, Gemini, etc.) to get better?
A: Because generalizability is "orthogonal" to enterprise adoption. A better public benchmark score doesn't help a private equity firm write a memo in their specific style. Enterprise success depends on 99% precision on a hyper-specific task, not general knowledge. That precision only comes from the fine-tuning and data integration that FDEs provide.
Q: Is this model sustainable for the software vendor?
A: It is high-investment, but it creates deep "institutional memory." Once an FDE team has solved a complex problem—like fine-tuning a model for underwater drone sensors—that logic becomes a reusable asset. While it contradicts the low-touch SaaS ideal, it is the only way to actually unlock value in the enterprise.