The Engineers Left Yesterday. Can You Run Your Agents Today?

For 11 months, your vendor’s engineers sat two desks away from your data team. They learned which customer table holds bad addresses and which one is correct. They connected the vendor’s agent framework to your claims pipeline, tuned the prompts, wrote the guardrails and built the test harness.

Then on Thursday, the engineers leave. And on Friday, when an analyst on your team opens the code to change one approval threshold, there’s no one in the room who can say what will break if he or she does.

Gartner expects this scenario to become common. On Sept. 29, 2026, the analyst firm predicted that 70% of enterprises will abandon agentic AI built by vendor forward-deployed engineering by 2028, “trapped by soaring costs and unable to evolve it on their own.” Agentic AI refers to systems that plan and carry out tasks on their own, such as approving a claim or routing a refund.

Forward-deployed engineering, or FDE, is a simple model. A vendor places its own engineers inside your company to build and deploy its product alongside your staff. Gartner says the model can deliver faster early progress. But the risk comes later if your team never learns to run what was built.

That risk grows when the engagement you bought isn’t really FDE at all.

When the label doesn’t match the work

Gartner is not calling FDE a scam. It describes the model as familiar from enterprise software: technically strong, product-literate people placed close to the customer. What has changed is the hype around the name.

“Many providers now use ‘forward deployed’ as a label for implementation, professional services, solution engineering, or AI consulting; some thoughtfully, others because it sounds more strategic,” said Mukul Saha, a senior director analyst at Gartner. “Some charge premium fees without the delivery depth, program management, or change management maturity to justify them.”

The real problem is what Gartner calls “FDE washing”: consulting services marketed as FDE. The analyst firm notes that once the scope is clear, a traditional services or partner model could potentially deliver the same work more cost-effectively and with more predictable results. The issue is paying an FDE premium for work that isn’t FDE.

Gartner also has a number for this risk. Through 2028, it predicts, fewer than 20% of FDE engagements will turn recurring customer needs into capabilities in the vendor’s core product.

Here is why this number matters. In a genuine FDE model, field work feeds the product. If the vendor’s engineers solve the same problem for three customers, the fix should become a standard feature that the vendor maintains for everyone. When that doesn’t happen, custom work stays custom, and the cost of maintaining it shifts to you.

For a CDO, that cost isn’t just financial.

What walks out the door

Engineers may leave but the code stays. The knowledge behind it goes with them out the door: why the feature store is designed the way it is, which data quality exceptions the agent skips, who decided the agent could approve refunds under USD500 without a human review.

The assets they built stay too, but their ownership may not be clear. In an agentic system, intellectual property covers more than source code. It includes the evaluation datasets used to test the agent, the labeled examples, the prompt libraries, the data mappings and any model weights tuned on your records. Together, these assets hold your organization’s knowledge in a form a machine can use. If the statement of work, the contract document that lists what the vendor will deliver, does not name them, you may have to settle ownership later, when it is harder to resolve.

Gartner’s view is that this problem starts long before the engineers pack up.

The fix starts in the contract

Gartner believes FDE engagements often fail structurally before they fail technically.

“FDE success starts with getting the engagement structure right, from scope and incentives to governance, ownership, and exit,” Saha said. “The best-scoped FDE engagements have clear guidelines on governance, business value delivery, IP ownership, project co-ownership, knowledge transfer, and an exit strategy from day one.”

Governance, ownership and knowledge transfer are core data responsibilities. They belong on your side of the contract, not left to procurement alone. Gartner sets out a three-phase approach to get them there.

Phase 1: Before you sign

Gartner says to use FDE only for problems that require deep product expertise, rapid adaptation or close integration between the vendor’s technology and your operating environment. For a standard implementation, a standard services contract may be the better fit.

“Identify an executive sponsor who is accountable for business outcomes, not simply the implementation budget,” Saha said. “Establish key contractual requirements beyond procurement’s scope, including deliverables, knowledge transfer, intellectual property rights and transition or exit responsibilities.”

Procurement negotiates price. It may never ask who owns the test data. That question falls to the CDO.

One way to test what you are buying: ask the vendor to name three features in its current product that started as field work at a customer site. A team doing genuine forward-deployed work should have examples and dates. If the answers are vague, you may be buying services under a new name, and you should price and contract it as services.

Phase 2: While the engineers are on site

Gartner advises embedding the vendor’s engineers with your domain experts, engineers and end users, so knowledge spreads and the solution reflects how work actually gets done.

“Establish a cadence of iterative business validation that evaluates not only technical performance but also the operating model required to scale AI responsibly,” Saha said. “Use each increment to define decision rights, determine the appropriate balance between autonomy and human oversight, clarify how confidence and exceptions are communicated and build the governance mechanisms that sustain user trust and accountability.”

Decision rights define who can decide what, including what the agent may decide without a person. In practice, that can mean three things: every vendor engineer has a named internal counterpart who can run the system without them; the decision log, a record of who set each autonomy threshold and why, becomes a contract deliverable; and your data stewards approve how the agent handles exceptions, because your team will be accountable for those choices once the vendor leaves.

Phase 3: Exit and prove independence

Gartner says to execute the exit plan set at the start, rather than extending the engagement because internal teams are not ready.

“Ensure the organization develops the capabilities, governance, and operational ownership required to independently sustain and evolve the solution over time,” Saha said. “Success is measured not by implementation completion, but by the enterprise’s ability to manage, optimize, and scale the technology, including adapting human-AI decision models as business processes, priorities, and risk profiles evolve.”

Make that test concrete before the exit date. One practical bar: your internal team completes a full release cycle on its own, from change request to testing to production, while the vendor’s engineers observe but do not assist. If your team can’t do it, you have found the gap while there is still time to close it.

Asking for “one more quarter” only delays that test.

Go back to that Friday morning. The goal is not to keep the engineers forever. Rather it is to allow your analyst to change the threshold, run the test suite your team owns, check the decision log and ship the change before lunch, without calling the vendor.

If you can’t picture that Friday yet, you’re not ready to let those engineers leave.

Image credit: iStockphoto/gzorgz