Forward Deployed Engineering Model: Gartner's 70% Exit Warning

Every major AI platform now wants to put engineers inside your company. AWS put $1 billion behind a dedicated FDE unit, Microsoft is planning to send 6,000 engineers to customers, and on October 13 Accenture and Workday launched a joint forward deployed engineering program for HR and finance agents. The forward deployed engineering model has gone from a Palantir quirk to a standard way vendors sell AI.

Gartner thinks most of it won't last. In a September 29 prediction, the firm said 70% of enterprises will abandon agentic AI built through vendor FDE by 2028. That's a forecast, not a measured failure rate. But the reasons behind it are worth reading before you sign anything.

TL;DR

• Gartner predicts 70% of enterprises will abandon agentic AI built by vendor FDE teams by 2028, citing cost and a lack of internal capability.
• The failure is structural: no exit plan, no knowledge transfer, no internal owner.
• Use FDEs for the ambiguous part, write the exit into the contract, and measure success by whether your team can run it alone.

What Gartner actually predicted

Gartner's argument is that FDE engagements "often fail structurally before they fail technically." The agent works. The problem is what happens around it.

Three points stand out:

• Costs outlive the value. Customers get fast early progress, then keep paying premium rates for work a traditional partner model could deliver more cheaply.
• Capability never transfers. The vendor's engineers understand the system. Your team doesn't. When the engagement ends, nobody can change it safely.
• "FDE washing" is real. Gartner analyst Mukul Saha warns that "many providers now use 'forward deployed' as a label for implementation," and some charge premium fees without the delivery depth, program management or change management maturity to justify them.

Gartner also expects fewer than 20% of FDE engagements through 2028 to turn recurring customer needs into core product features, which is the part that's supposed to make the model pay off for vendors.

Why vendors are building FDE teams anyway

The supply numbers explain the rush. According to CIO Dive's coverage, Saha estimates there are about 2,000 active FDEs, with demand roughly four times that. Google Cloud posted 59 FDE roles in May, AWS committed $1 billion to an FDE unit in June and Microsoft spent $2.5 billion on an AI deployment division in July. Accenture is adding 1,000 AI deployment specialists to its Gemini Business Group.

For vendors this makes sense: embedding engineers is the fastest way to turn a pilot into consumption revenue. For buyers, the incentives differ. A vendor's FDE is very good at getting that vendor's product working inside your stack. They're less motivated to design something your team can swap out, and they're rarely measured on whether you still need them in a year. That isn't bad faith; it's what the role is paid to do.

The Accenture and Workday program shows the pattern: teams work inside the client's processes and controls, and lessons feed back into Workday's product. Useful if you're committed to that platform.

Where the forward deployed engineering model goes wrong

A failed FDE engagement often follows the same arc. Week one is exciting. By month three there's a working agent. By month six the original engineers have rotated, the internal team was too busy to pair, and nobody wrote down why the retrieval pipeline is shaped the way it is.

The FDE did the job they were hired for. Nobody was hired to do the other one.

The four gaps that sink engagements

1. No accountable sponsor. Gartner recommends an executive sponsor who owns business outcomes, not just the implementation budget. Without one, success gets defined as "shipped."
2. No internal pairing. If your engineers aren't committing code alongside the FDEs, you're buying a black box.
3. No exit criteria. Engagements get extended "because the team isn't ready," exactly the trap Gartner describes.
4. Wrong problem. FDEs earn their premium on ambiguous, integration-heavy work, not a standard CRM rollout.

CIO Dive also cites a Gartner estimate that FDE consulting fees alone could exceed $200,000 per quarter per use case. At that rate, a slow exit gets expensive quickly.

Vendor FDE vs independent provider vs in-house

The real choice isn't "FDE or not." It's whose engineers, for which part of the work, and who owns the system afterwards.

A common pattern is a mix: external FDEs for the first deployment, with in-house engineers paired from week one so the second needs less help. Our guide to in-house vs FDE vs staff augmentation covers that split in more depth.

What this means for your budget, scope and timeline

Scope. Draw a hard line around the part that needs FDEs: messy integrations, ambiguous requirements and evaluation design. Standard connectors, UI work and documentation can go to cheaper delivery.

Budget. Model two phases, not one. Phase one is the FDE build. Phase two is your team running it, plus any reduced support. If phase two has no budget, you've planned for the 70%.

Team. Name two or three internal engineers who will own the system before kickoff, and protect at least half their time. That's the real cost of a clean handover.

Timeline. Put the exit date in the plan from the start. An illustrative first agent deployment: discovery and evals in month one, build and pairing in month two, then a final stretch where your engineers lead and the FDEs review.

A contract and exit checklist before you sign

Gartner splits its advice into before signing, during the engagement and proving independence at the end. On paper, that looks like this.

1. Define the problem. Write one paragraph on why this needs FDEs rather than a standard implementation partner.
2. Name the sponsor. One executive, accountable for a business metric, not for the invoice.
3. Specify deliverables. Code in your repositories, architecture docs, eval suites and runbooks.
4. Write the knowledge transfer clause. For example: "Provider engineers will pair with named client engineers on all production changes. By week 10, client engineers lead all merges with provider review."
5. Settle IP rights. Prompts, eval datasets, fine-tuned weights and integration code should be yours.
6. Agree exit criteria. Your team ships a meaningful change unassisted, on-call runs without provider escalation for a set period, and evals pass on your infrastructure.
7. Ask for the bench. Who will be embedded, and what happens if they rotate off?
8. Test for FDE washing. Ask for recent production work done inside a customer's environment, not a demo.

Still undecided between building internally, bringing in a partner or using a vendor team? The free AI Deployment Assessment walks through that choice based on your scope, team and timeline. Pair it with the vendor evaluation checklist when you start talking to providers.

Find the right deployment partner

The lesson from Gartner's warning is simple: choose a team for how well they leave, not just how fast they start. When you compare providers, ask about handover, pairing and exit criteria before you ask about speed. Our provider matching tool compares providers against your requirements with plain-language reasons and gaps, and every profile shows verification status, with any featured placement clearly labelled. Find an FDE provider.

Key takeaways

• Gartner's 70% figure is a forecast about vendor-led FDE, driven by cost and missing internal capability.
• Vendor FDE teams exist to drive platform adoption, so their incentives won't always match yours.
• Reserve FDEs for ambiguous, integration-heavy work and send routine delivery elsewhere.
• Put the exit plan, IP terms and knowledge transfer into the contract before kickoff.
• Measure success by whether your team can change and run the system on its own.

FAQ

What is the forward deployed engineering model?

The forward deployed engineering model embeds a provider's engineers with a customer's team to scope, build and ship software in production. Unlike solutions engineers who support a sale, FDEs own the deployment: integrating legacy systems, writing production code and setting up evaluation. Palantir popularised it, and many AI vendors now use it.

Why does Gartner predict vendor FDE projects will be abandoned?

Gartner says 70% of enterprises will abandon agentic AI built through vendor FDE by 2028 because costs become unsustainable and internal teams can't evolve the systems alone. The firm also flags "FDE washing," where providers relabel ordinary implementation work as forward deployed engineering and charge premium fees without the delivery depth to match.

Is a vendor FDE better than an independent FDE provider?

It depends on how committed you are to one platform. A vendor's FDE knows its product deeply and moves fast, but may not prioritise portability or handover. An independent provider can work across systems, though quality varies. Judge either on production track record, pairing approach and exit terms.

How do you exit an FDE engagement cleanly?

Plan the exit before signing. Set criteria such as your engineers shipping a change unassisted, running on-call without escalation and passing evals on your own infrastructure. Pair internal engineers with FDEs from week one, keep code and documentation in your systems, and hold to the exit date.

Before your next vendor call, write down which part of the work really needs embedded engineers and who on your team will own it after go-live. If either answer is unclear, start there. Take the free AI Deployment Assessment.

Sources

• Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028
• Are forward deployed engineers flirting with failure? (CIO Dive)
• Accenture Launches Forward Deployed Engineering Program with Workday
• AI buyers need to plan beyond forward-deployed engineers (Okoone)