Forward Deployed Engineer vs Consultant: Which Delivery Model Fits the Problem?

The internet version of this comparison is usually simple:

Consultant = slides.

Forward Deployed Engineer = code.

It is memorable. It is also increasingly wrong.

Deloitte, EY and McKinsey now recruit or operate Forward Deployed Engineers themselves. Salesforce has built a Forward Deployed Engineer Partner Network spanning major consulting firms. The boundary between “consultant” and “FDE” is therefore not an employer boundary and not even a clean job-title boundary.

A more useful distinction is:

Consulting is a broad service category. Forward deployment is a specific delivery pattern. They can overlap.

The buying decision should be based on where ownership sits, what the team is expected to produce, and what happens when the original plan collides with reality.

Why the old comparison has broken down

Traditional management and strategy consulting can still be advisory. A client may buy research, operating-model design, market analysis, transformation planning or executive decision support without expecting the consulting team to own production software.

But implementation consultancies have written production systems for decades.

In 2026 the overlap became even clearer.

Deloitte’s Forward Deployed Engineering offering explicitly positions engineers inside client environments to move AI and software into production.

EY announced FDE roles for the UK and Ireland focused on designing, building, integrating and operationalising AI in live customer environments.

McKinsey’s QuantumBlack organisation recruits Forward Deployed Engineers to deploy its technology and hand over production systems.

On 12 August 2026, Deloitte said it had become the first global systems integrator to staff and deliver a Salesforce Forward Deployed Engineering engagement. The example places a consultancy inside the FDE category through its delivery model and vendor partnership.

An FDE team can sit inside a consultancy. The proposal should make clear who will do the work, what the team owns and who remains accountable after launch.

Compare delivery models, not labels

A serious comparison should distinguish at least seven common models.

Advisory consulting

Primary value: analysis, decisions, strategy, operating model, programme design or specialised domain advice.

The client may implement the recommendation itself or appoint another delivery team.

Best fit when the key uncertainty is what the organisation should do.

Implementation consulting

Primary value: deliver a defined transformation or system implementation, often with project management, architecture, integration and change capability.

This can look very similar to FDE when the consulting team includes strong engineers and works directly in production systems.

Best fit when the organisation needs a structured implementation programme, often across multiple workstreams.

Software or product agency

Primary value: design and build software for a client.

The agency may own discovery and engineering, but it commonly works toward a product or project boundary rather than embedding around an ongoing deployment/product feedback loop.

Best fit when the organisation needs a product or system built, with relatively clear ownership boundaries.

Staff augmentation

Primary value: add engineering capacity.

The client usually owns architecture, prioritisation, backlog and product decisions.

Best fit when the organisation already knows what to build and needs more hands or specialist capability.

Independent FDE

Primary value: own a defined deployment outcome across discovery, code, integration and production.

The work often starts before the implementation specification is complete because discovering the true system boundary is part of the job.

Best fit when the company knows what business outcome matters but not exactly how the production system must change.

Vendor FDE

Primary value: make a particular platform work deeply inside the customer environment while feeding deployment knowledge back to the vendor.

OpenAI and Palantir are strong vendor-FDE examples, while Salesforce’s 2026 FDE Partner Network shows the model extending into trained implementation partners.

Best fit when the organisation has made or is comfortable making a strategic commitment to that vendor’s platform.

Product + partner FDE

Primary value: combine a vendor platform with external implementation capacity.

Salesforce’s FDE Partner Network and Anthropic’s system-integrator strategy illustrate this direction.

Best fit when the customer wants platform expertise plus scaled implementation capacity.

The comparison dimensions that actually matter

A buyer should ask the same questions of every provider regardless of what it calls itself.

The most revealing test: it is week three and the plan is wrong

Suppose the project began with a clear hypothesis:

“Connect the AI assistant to the CRM and automate the workflow.”

By week three, the team has discovered that CRM data is incomplete, the important documents live elsewhere, identity rules block the planned service account, and the real bottleneck is a manual approval step nobody mentioned during procurement.

How each model responds tells you more than the title.

Advisory consultancy

A pure advisory team may update the recommendation, identify the process issue and define a revised target operating model.

That can be exactly what the client needs if the real problem is organisational.

But the engineering still needs an owner.

Fixed implementation programme

An implementation consultancy may raise a change request, revise scope, add a workstream or re-plan the programme.

This is appropriate when governance and predictability matter more than rapid iteration.

The downside appears when every newly discovered fact becomes commercial or programme-management friction.

Staff augmentation

The augmented engineer asks the client’s product or engineering lead what to do next.

That is correct: strategic ownership remains with the client.

It fails only when the reason the contractor was hired was that nobody inside the client currently owns the cross-functional problem.

Software agency

A good agency may re-scope quickly and solve the newly discovered issue.

The question is whether the engagement is organised around the software deliverable or the operating outcome. If the approval workflow sits outside the defined product boundary, the agency may reasonably stop there.

FDE engagement

A genuine forward-deployed team should treat the discovery as part of the job.

The implementation path changes because the team is accountable for the workflow, not for proving the original diagram correct.

That may mean changing the architecture, replacing one integration, automating a different step or recommending that the project stop because the expected value no longer justifies the build.

That last option matters. Outcome ownership should include the ability to say do not build this.

FDE does not mean “no scope”

Forward deployment is sometimes described as if the solution is to remove process and let senior engineers improvise.

That is not a sustainable commercial model.

The distinction is between scope defined around an outcome and scope defined around a pre-decided implementation.

For example:

Weak FDE scope:

Build three agents, two dashboards and a CRM connector.

Stronger FDE scope:

Reduce the manual work required to resolve category-X service requests while preserving approval controls; establish the baseline and release criteria during discovery.

The second still needs boundaries, budget, access assumptions and decision rights. It simply leaves room for the technical route to change when evidence changes.

The vendor-FDE feedback loop is genuinely different

One of the strongest characteristics of the original vendor-FDE model is that field deployment does not end with customer delivery.

OpenAI asks FDEs to codify successful patterns into reusable tools, playbooks and building blocks and to feed deployment signal into Product and Research.

OpenAI’s current FDE roles similarly ask engineers to turn field learning into reusable tools, playbooks and product feedback.

That creates a loop:

Customer problem → deployment → field evidence → reusable product improvement → next deployment

A generic consultant cannot automatically reproduce that because the consultant may not own the underlying platform.

But an independent FDE can create a similar loop at a different layer by turning repeated deployment patterns into reusable internal accelerators, libraries, evaluation harnesses or vertical IP.

This is one reason the commercial model matters as much as the job title.

A practical way to choose

Start with the main uncertainty. If it is strategic or organisational, advisory consulting can help clarify the decision. If the destination and workstreams are known, an implementation consultancy or agency can deliver them. If the backlog is clear and the team needs capacity, staff augmentation may fit. Consider an FDE when the team must discover the production path while building against a defined outcome. A vendor FDE can help when deep access to a selected platform matters.

What should you ask a provider before deciding?

Instead of asking “Are you a consultant or an FDE?”, ask:

1. Who from your team will actually do discovery?
2. Will that same team write production code?
3. Can they work in our repositories and cloud environment?
4. Who makes architecture decisions?
5. How do you handle discoveries that invalidate the original scope?
6. How is success measured?
7. What happens during rollout?
8. What do we own at the end?
9. What support remains after handover?
10. Which parts of the solution are tied to your own platform or IP?

The answers reveal the operating model far more reliably than the label.

Choose advisory work to clarify a strategic decision, or add engineering capacity when the backlog is already clear. Consider an FDE when the team needs one owner to discover the production path while building toward a defined outcome.