Ask Who Owns It at Month Six
Gartner predicts 70% of enterprises will abandon agentic AI built by vendor forward-deployed engineers by 2028. The number has no disclosed method. The mechanism does: engagements fail on structure before technology. Five questions to put in the contract before month one, each checkable against a document.
- forward-deployed-engineers
- vendor-contracts
- ai-implementation
- knowledge-transfer
- enterprise-ai
Gartner predicts that by 2028, 70% of enterprises will abandon agentic AI built by their vendor's forward-deployed engineers, "trapped by soaring costs and unable to evolve it on their own." That's a prediction. The release (29 September 2026) doesn't describe a survey, a sample or a method behind the number, so read 70% as a direction rather than a measurement.
The mechanism is the useful part. Mukul Saha, the Gartner analyst quoted in the release, says "FDE success starts with getting the engagement structure right, from scope and incentives to governance, ownership, and exit." The failure he describes doesn't happen in the code. It happens in what was or wasn't written down before the engineers arrived.
What you're actually buying
A forward-deployed engineer (FDE) is a vendor's engineer who sits inside your business and builds with your people. The model is good at one thing: getting a hard integration working fast, with someone who knows the product from the inside.
It also means the people who understand your system best are on someone else's payroll. When they rotate off, what they know leaves with them unless the contract said otherwise. Saha's description of the best-scoped engagements is a list of things most statements of work leave out: "clear guidelines on governance, business value delivery, IP ownership," plus co-ownership, knowledge transfer and "an exit strategy from day one."
Then there's the label. Saha notes that many providers now use "forward deployed" for what used to be called implementation, professional services or AI consulting, "some thoughtfully, others because it sounds more strategic." Some, he says, charge premium fees without the delivery depth or change management maturity to justify them. Gartner's name for this is "FDE washing," and it predicts that through 2028 less than 20% of FDE engagements will turn recurring customer needs into capabilities in the vendor's core product. If a vendor tells you every engagement improves its product, that's a claim worth testing.
Five questions to answer before month one
Gartner's release recommends structure. It doesn't give you a checklist you can hand to procurement. The five below are ours, built from its recommendations and from how engagements go wrong in practice. Each one can be checked against a document.
-
Who is the executive sponsor, by name? Gartner says the sponsor should be "accountable for business outcomes, not simply the implementation budget." Test: the name is on the first page of the statement of work, and it isn't the person who signed the invoice.
-
What do we own at month six? Code, prompts, evaluation sets, configuration and credentials should sit in your accounts, not the vendor's. Test: pick a Tuesday and ask your own engineer to ship a small change without vendor access. If they can't, you rent the system.
-
Who on our side sits next to each vendor engineer? Gartner recommends embedding FDEs with internal domain experts. Test: every vendor engineer has a named counterpart who can explain each component to a stranger. If nobody can, the knowledge is still one resignation away from gone.
-
What does exit look like, and when is it decided? Gartner says to follow the exit plan set at the start rather than extend the engagement. Test: exit conditions are written as things you can measure, with a calendar date for the first extension decision. An exit plan with no date is a wish.
-
Is this an FDE engagement or a consulting engagement with a new name? Test: ask for the last time the vendor's engineers changed the product based on something built for a client, and ask how long the engineers assigned to you have been in role. Vague answers tell you which one you're buying.
Whether the record of how the work actually runs transfers to you when the engineers leave is a sixth question, and a large one. We'll come back to it separately.
What this doesn't tell you
A vendor can agree to all five and still staff the engagement badly. The checklist improves your odds of owning the outcome. It says nothing about whether the engineers are good.
It will also cost you something. Exit terms and knowledge transfer take the vendor's time and cut into the margin of an open-ended engagement, so expect pushback on price or scope. Treat that as information. A partner that resists writing down how you leave is telling you how it expects the engagement to end.
One more caveat on the source. Gartner sells advisory work, and the full guidance sits in a playbook for its clients. We've read the public release, not the playbook, so the specifics above come from the release and the checklist is our inference.
Gartner's own measure of success is useful here: "not by implementation completion, but by the enterprise's ability to manage, optimize, and scale" the technology. Go and find the statement of work for any engagement where a vendor's engineers are building something for you. Count how many of the five answers are written on the page. Whatever isn't on the page belongs, in practice, to the vendor.
If you want that question answered for your specific situation, the Forge Playbook does it. Answer a few questions about your business and we'll put together a tailored outline of which workflows are worth automating and what a realistic budget looks like for each. Free, no obligation, takes about three minutes.
