Forward deployed engineering (FDE) has become one of the fastest-growing categories in enterprise AI. OpenAI, Anthropic, Salesforce, Google, and dozens of consulting firms are all now using the term, building teams around it, and positioning it prominently in their go-to-market language.

That growth creates a problem for enterprise buyers.

When a term moves from niche operating model to mainstream positioning language in under 18 months, the gap between firms that genuinely operate this way and firms that have adopted the language without the underlying model becomes very difficult to see from the outside. Every partner deck now mentions embedded engineers. Every proposal references production deployment. Every sales conversation includes the word outcomes.

None of that tells you whether the firm can actually deliver.

This piece gives you the questions that do.

Why the Evaluation Is Harder Than It Looks

The forward deployed engineering model is specific. It requires engineers who are technically capable across the full stack, comfortable operating inside client environments with all the ambiguity and organisational complexity that entails, and accountable to production outcomes rather than delivery milestones.

That combination is genuinely scarce. Which is precisely why firms that do not have it are under significant commercial pressure to describe their offering using language that implies they do.

The Forrester Wave Q2 2026 criteria, explicitly reward production deployment capability and operating model design. That signal has accelerated the rebranding of advisory and consulting practices as forward deployed engineering without the structural changes required to actually operate that way.

The result is a market where the terminology is consistent and the delivery capability is not.

Six Questions That Separate Genuine FDE Capability from Rebranded Consulting

1. Where will the engineers actually work?

This is the most fundamental question and the one most likely to produce a revealing answer.

A genuine forward deployed engineering team will be physically or virtually embedded inside your environment for the duration of the deployment. Not visiting on a schedule. Not attending weekly check-ins from a remote delivery centre. Actually present, day to day, in the operational environment where the system being built will eventually run.

Ask the specific question: where will the engineers working on my programme be located, and what does a typical working week look like for them during the engagement?

A firm with genuine FDE capability will answer this precisely. A firm that has rebranded a traditional delivery model will describe a process of regular touchpoints, site visits, and collaboration sessions, which is a different operating model with a different failure profile.

2. Where does accountability end?

A traditional consulting engagement ends at delivery. The system is handed over, signed off, and the vendor's responsibility concludes. What happens after that, whether the system is adopted, whether it performs in production conditions, whether the teams using it find it usable, is outside the scope of the engagement.

Ask directly: what does success look like for you at the end of this engagement, and what happens if the system is delivered but not adopted?

A firm with genuine FDE capability will define success at production adoption and business outcome. A firm operating a traditional delivery model will define success at technical delivery and handoff, possibly with a support period attached.

This distinction matters more than almost any other factor in predicting whether an AI initiative reaches production. Genuine adoption rather than technical delivery is the actual finish line.

3. How is scope change handled?

Enterprise environments are not stable. Requirements that were accurate at the start of an engagement regularly turn out to be incomplete once the build is underway and real constraints surface.

Ask: what happens when we discover mid-engagement that the integration environment is more complex than the initial assessment suggested, or that a requirement needs to change based on what we find in the actual system?

A genuine forward deployed engineering partner will describe a continuous adjustment process, because they are inside the environment where those adjustments become necessary and can respond in real time. A traditional delivery partner will describe a change control process, which is legitimate but signals a different operating model, one optimised for scope management rather than production outcomes.

4. Can they show a track record in your specific integration environment?

Forward deployed engineering is not a generic capability. The value of embedded engineers is precisely that they understand the specific constraints of the environment they are working in, the ERP configuration, the data structures, the compliance requirements, the organisational dynamics.

Ask for specific examples of deployments in your sector, ideally involving the same core systems your organisation runs on. An automotive manufacturer running ERP should ask about prior ERP integrations in automotive environments. An FMEG company with a complex dealer network should ask about prior dealer platform deployments.

Generic AI delivery experience does not transfer cleanly to specific enterprise integration environments. The firms with genuine FDE capability in your sector will have specific, detailed answers to this question. The firms without it will describe their general approach to enterprise integration.

5. What does their engineering team actually look like?

Forward deployed engineering requires a specific kind of engineer, one who is technically capable across the full stack, comfortable with ambiguity, and able to operate inside a client's organisational environment rather than a controlled internal one.

Ask to understand the composition of the team that will actually work on your programme. How senior are the engineers? What is the ratio of engineers to project managers and account managers? What does their technical background look like across data engineering, AI application development, cloud infrastructure, and system integration?

A firm with genuine FDE capability will have engineers at the centre of the engagement structure. A firm operating an advisory model with delivery support will have project managers and account leads at the centre, with engineering capacity behind them.

The ratio matters. So does seniority. Forward deployed engineering is not a model that works with junior engineers supervised remotely by senior ones.

6. How do they price the engagement?

Pricing structure is one of the clearest signals of delivery confidence and method maturity, as the Forrester Wave Q2 2026 analysis makes clear.

Ask whether any portion of the engagement fee is tied to production outcomes rather than delivery milestones. Ask what the milestone structure looks like and what triggers each payment.

A firm with genuine FDE capability and a track record of production delivery will be willing to discuss outcome-based elements because it has confidence in its ability to deliver them. A firm whose model ends at delivery will price against delivery milestones alone, because that is the extent of what it can control and therefore commit to.

This does not mean every engagement needs to be fully outcome-based. It means the willingness to have a genuine conversation about outcome-based pricing is a signal worth reading carefully.

Red Flags to Watch For

Beyond the six questions above, several patterns in the sales process signal a gap between claimed and actual FDE capability.

• The proposal is heavy on methodology and light on engineering specifics.

Genuine FDE partners lead with engineering capability and integration experience. Advisory firms that have rebranded as FDE partners lead with frameworks, approaches, and process diagrams.

• The team presented in the sales process is not the team that will do the work.

This is common in consulting engagements and almost always signals a traditional delivery model. In a genuine FDE engagement, the engineers who will be embedded in your environment should be identifiable before the engagement starts.

• The timeline is longer than 90 to 120 days to first production deployment.

Forward deployed engineering is specifically structured to deliver production outcomes quickly, because a longer timeline increases the risk that requirements shift before delivery. Proposals with 6 to 12 month timelines to first deployment are usually describing a traditional project delivery, not an embedded production model.

• Governance and compliance are treated as a separate workstream.

A genuine FDE capability builds governance into the delivery architecture from day one. Partners that treat compliance and governance as a parallel track managed by a separate team are describing an advisory model, not an embedded delivery model.

What a Genuine FDE Partner Looks Like in Practice

To make the evaluation concrete, here is what a genuine forward deployed engineering engagement should look like from the first conversation to production deployment.

The initial conversation is led by engineers, not account managers, and focuses on your specific integration environment, your named business constraint, and what production looks like for this use case. Not a generic AI capability pitch.

The proposal specifies which engineers will be embedded, at what seniority level, for what duration, and what production milestone defines the end of the engagement. Not a methodology deck with resource categories.

The first 30 days are spent inside your environment, against your actual systems, discovering the real integration constraints before committing to an architecture. Not producing a discovery document from interviews conducted remotely.

The engagement extends accountability through to genuine adoption, with the embedded team present for the first weeks of production operation, resolving the issues that only surface when real users are running real transactions through the system.

Vishleshan AI's forward deployed engineers operate exactly this way across automotive, FMEG, financial services, and supply chain environments, taking AI from a named use case to production in 90 days.

The forward deployed engineering label is now widely used. The operating model it describes is not widely practiced. The gap between the two is the single most important thing for enterprise buyers to evaluate when selecting an AI delivery partner in 2026.

The six questions in this piece will not give you a perfect answer in every case. But they will give you a significantly clearer picture of whether the firm across the table from you is structured to actually deliver production outcomes in your environment, or whether they are selling you a compelling description of a model they have not yet built.

The difference between those two things is the difference between AI in production and AI in perpetual pilot. And by now, most enterprise leaders have seen both often enough to know which one they are trying to avoid.

Vishleshan AI's forward deployed engineers work inside your environment until AI is genuinely in production. Book a Consultation