Forward deployed engineers are a symptom, not a cure

Every AI vendor I meet now sells forward deployed engineers, and what they are being sent to deploy is almost always an agent. Frontier labs do it. The big platforms do it. The system integrators, who used to sell “teams”, now sell “pods”. The pitch is the same in every deck: our platform is powerful, your environment is complicated, so we will put our engineers inside your company until the thing works.

Gartner published a guide to this in March, An AI Leader’s Guide to Forward Deployed Engineering to Scale AI, by Arun Chandrasekaran and Robert Thanaraj. It is a careful piece of work, and it says the quiet part plainly: the rise of the model is “a sign of AI platform immaturity”. I have run a company that sits on both sides of this line for eight years. We sell delivery, and we now sell a platform. So I want to say what the Gartner note can only imply, and then describe what I think an enterprise should demand instead.

Forward deployed engineer (FDE)

An engineer employed by a technology vendor or services firm who is embedded in a customer's environment to take an AI use case from pilot to production, measured on the outcome and on the customer's adoption of the vendor's platform rather than on hours.

What the model is actually telling you

Strip the branding and an FDE is an admission. The platform, on its own, cannot get from the demo to the Monday morning when a real process runs on it. Someone has to wire it to the systems of record, write the last mile of data plumbing, work out what the agent must refuse, sit with the compliance team, and stay until the numbers hold. The vendor has learned that if nobody does this, the pilot stalls, the renewal does not come, and the logo quietly leaves the slide. So they send an engineer.

It is no accident that the demand for forward deployed engineers arrived with agentic AI. A chatbot that drafts text can be shipped as a product and left alone. An agent that decides what to do next, calls your systems and writes to your records cannot, because most of what makes it safe to run is not in the model at all. It is the list of what the agent must refuse, the named person who approves anything irreversible, the trace of every run, and the budget per step: the four tests I call Agentic in Production. Every one of them is organisational work that lives on your side of the line, in your systems of record, with your people’s names on it. That is the last mile the FDE is being sent to walk, and it is why the platform was never going to walk it alone. The FDE is the industry’s answer to the question this site exists to answer: who does the work between the demo and production, and who owns it afterwards.

That is not a criticism of the engineers. The good ones are excellent, and the skills Gartner lists for the role, full-stack depth, data wrangling, problem framing, stakeholder translation, an ownership mindset, are exactly the skills that get agents into production. It is a criticism of where the engineer sits. An FDE is paid by the vendor, incentivised on the vendor’s platform adoption, and carries the vendor’s codebase in one hand and your production credentials in the other. Every risk in the model follows from that geometry.

Gartner cites its own 2024 survey finding that, on average, 59 percent of generative AI prototypes never reach production. I believe the number; it matches what I see. But look at the reasons given, data, integration, unrealistic expectations, technical implementation, and notice that none of them is “not enough vendor engineers in the building”. They are organisational failures that an outside engineer can paper over for one use case and cannot fix for the next.

The five risks, and the one cause

The guide names the risks well, so I will not repeat the list at length. Vendor dependency, because only the FDE understands what the FDE built. Security and data exposure, because the FDE needs privileged access to be useful. Talent atrophy, because your engineers become operators of a black box while the vendor’s engineers become the architects. Shadow architecture and technical debt, because “move fast” bypasses your standards. And long-term maintainability, because much of what an FDE hand-codes today is domain logic that the next generation of models will make redundant.

Read them again and they are one risk with five faces. The work is done on the vendor’s side of the line. The knowledge accumulates on the vendor’s side of the line. The incentives point to the vendor’s platform. The exit, if there is one, is the vendor’s decision. An FDE engagement that is not designed to end is staff augmentation with a better title, and the guide says so.

What I find most useful in the note is not the warning but the prescription. Outcome-based SLAs measured at the business level. IP ownership settled before the work starts, with a rule of thumb that most of what is built goes back into your own platform, not into a one-off script. A shadow engineer from your team on every vendor engineer. Composable architecture with swappable models. Guardian agents checking the primary agent’s output. And an exit plan on day one, both value-bound and time-bound.

I agree with all of it, and I want to go one step further. Those controls are not the fine print on a good FDE engagement. They are the engagement. If a vendor cannot put them in the contract and in the price, you are not buying delivery; you are renting a person.

What we do instead, and why it looks the way it does

At Ailoitte we deliver agentic work through what we call AI Velocity Pods, and I want to be honest about the lineage. A pod is a small senior team embedded with the client for the length of an outcome. From the outside it looks like forward deployment. The differences are all in the geometry.

Three ways to get an agent into production. The first two columns follow Gartner’s distinction between professional services and FDE; the third is how we work.

The pod works on your side of the line. It builds in your environment, on your stack, against your systems of record, under your security controls. The agents it builds are yours: the prompts, the workflows, the connectors, the evaluation set, the runbook. There is no vendor codebase in the other hand. That is Gartner’s “at least 70 percent of the code goes back to your platform” rule, set to one hundred percent, because I have never seen a good reason for the other thirty.

The pod is paid for an outcome, not for presence. Before a price is agreed there is a two-week definition phase that produces three artefacts: an evaluation set with an agreed pass rate, a refusal list enforced in code, and a budget per run and per month. Those three artefacts are Gartner’s outcome-based SLA, written down before anyone commits a number. They are also the exit plan, because when the agent passes the set inside the budget with the refusals enforced, the pod’s work is done and the pod leaves. The engagement ends by construction, not by negotiation.

The pod includes your people. Every pod has a domain reviewer from the client, part-time, who owns the refusal list and labels the evaluation cases, and a named owner on the client side who inherits the runbook and the kill switch at handover. That is the shadow-engineer requirement, except that the shadow is not shadowing; they are holding the two documents that define whether the agent is allowed to run. When the pod leaves, the person who can switch the agent off and the person who decides what it may do are both employees of yours.

The pod is small on purpose. Three to five people, and everyone in it has read every prompt and every failing trace. That is what lets the price be fixed, and it is why a pod does not become the permanent fixture that Gartner warns about. A twenty-person embedded team has to be managed. A pod has to finish.

And the pod builds composable systems, for a commercial reason rather than a philosophical one. Fixed price cannot afford an architecture that needs constant hand-tuning, so the pod routes each step to the cheapest model that passes the evaluation set, behind standard interfaces, and puts refusals in the tool layer rather than the prompt. When the next model arrives, you swap it and re-run the set. The hand-coded domain logic that Gartner rightly expects to go obsolete is kept to the refusal list and the workflow, which are the two things you would want to survive a model change anyway.

The honest part

We now sell a platform too. Leverge is a library of 306 agents that deploy inside your CRM, ERP or ticketing system, so I am exposed to the same critique I am making. Two things keep me honest. Every agent’s runtime workflow is published, so a buyer can read exactly what it does before signing and an auditor can read it afterwards; nothing lives only in an engineer’s head. And the agents run inside your systems of record rather than replacing them, so the exit is a configuration change, not a migration. Whether that is enough is for buyers to judge, and the vendor evaluation playbook has the questions I would ask, including of us.

Gartner also predicts two futures I think are right. The internal FDE, an engineer on your payroll who bridges IT and a business unit, is the shape of the AI team that regulated enterprises will build, and a pod’s job is to leave that person better equipped than it found them. And AI agents as junior FDEs, doing the API mapping and the boilerplate, is already how our pods work; the human time goes to definition, approvals and change, which is where it should have been all along.

If you are doing this in your company

If a vendor offers you forward deployed engineers, say yes to the engineers and no to the geometry. Ask for the outcome as a written evaluation set, a refusal list and a budget, priced before the work starts. Ask who owns every artefact, and expect the answer to be you. Name your shadow, and make them the owner of the refusal list, not an observer. Ask what happens to the architecture when the model changes. And ask for the date and the condition on which the engineer leaves. If the vendor cannot answer the last question, the engagement has no end, and it was designed that way.

If you are building the capability in-house, hire the internal FDE Gartner describes and give them the same three artefacts as a job description. The skills on Gartner’s list are real; the location is what matters.

Whoever walks the last mile, a vendor’s engineer, a pod, or your own, the job is the same: get the agent to pass the four tests, and leave the people who own the tests inside your company. Everything else is a delivery model.

Source: Chandrasekaran, A. and Thanaraj, R., “An AI Leader’s Guide to Forward Deployed Engineering to Scale AI”, Gartner, 5 March 2026 (G00847066), and the 2024 Gartner AI Mandates for the Enterprise Survey it cites. Gartner’s findings are paraphrased here; the report itself is available to Gartner clients.