Accenture, Deloitte and EY All Run Forward Deployed Engineering Now: What Actually Differs. Nucleo

The short answer

Forward deployed engineering stopped being a way to tell delivery partners apart, because Accenture, Deloitte, EY and more than thirty Salesforce partners now all run practices under that name. The question that still separates them is structural rather than semantic: ask which vendor relationship funds the pod, because that answer, not the job title on the team, tells you whose roadmap the work will end up serving.

Nine months ago, “we work forward-deployed” was a usable filter on a shortlist. Today it is a category label the largest system integrators, the Big Four and a platform vendor’s partner program have all adopted, in most cases co-branded with the platform paying for the practice. The method did not get worse. It stopped carrying information.

Key takeaways

The label went mainstream in nine months. Deloitte named a forward deployed engineering practice in December 2025 (Deloitte), Accenture launched one with Microsoft in March 2026 (Accenture), and EY launched the roles in the UK and Ireland in April 2026 (EY).

Most of these practices are co-branded with a platform. Accenture’s are named for Microsoft and for ServiceNow (Accenture and ServiceNow). Deloitte’s careers site lists a separate lead engineer track per vendor relationship (Deloitte careers).

A vendor now runs its own partner network for the model. Salesforce launched a Forward Deployed Engineering Partner Network in April 2026 with Accenture and Deloitte as launch partners, explicitly to scale Agentforce (Salesforce).

Even the open version starts on one stack. Deloitte’s Open Model Engineering practice, launched in September 2026, argues sovereignty and control over data, IP and inference transparency, and initially builds on NVIDIA Nemotron open models and NIM microservices (Deloitte).

The diligence question changed. Not “do you work forward-deployed,” which everyone now answers yes to, but “which vendor relationship funds this pod, and what happens to the build when we change models.”

Nine months, seven practices, one label

The timeline is short enough to read in one pass.

Deloitte named a forward deployed engineering practice in December 2025, structured as pods of two to five engineers who own execution, resourcing, escalation and delivery health. Accenture launched a practice with Microsoft on 18 March 2026, with Microsoft supplying the platform and Accenture leading change management, process redesign and deployment. Salesforce followed in April 2026 with a Forward Deployed Engineering Partner Network: Accenture and Deloitte as launch partners, alongside Capgemini, Cognizant, IBM Consulting, KPMG, PwC, Slalom, Tata Consultancy Services and more than thirty firms in total. EY launched the roles in the UK and Ireland the same month. On 6 May 2026 at Knowledge 2026, ServiceNow and Accenture launched a joint program placing ServiceNow’s own engineers alongside Accenture’s inside shared customer environments.

Then the pattern produced its first concrete instance. On 12 August 2026 Deloitte announced it had become the first global system integrator to staff and deliver a Salesforce forward deployed engineering engagement, embedding its engineers inside solution delivery teams to build Agentforce work (Deloitte). Three weeks later, on 2 September 2026, Deloitte launched an Open Model Engineering practice and said it would hire, train and certify forward deployed engineers through fiscal 2027 to staff it.

None of this is a criticism of the firms involved. It is a market doing what markets do with a delivery model that works. But a CIO who put “forward-deployed” on an evaluation scorecard in early 2026 now has a column where every vendor scores full marks, which is the same as having no column.

Read the org chart, not the job title

The useful signal moved from the label to the structure underneath it, and the structure is public.

Deloitte’s own careers listings name the tracks separately: a Lead Anthropic Forward Deployed Engineer, and equivalent lead roles tied to other vendor relationships. That is one engineering track per model or platform partnership, not one team assembled around a client’s architecture. Accenture’s practices are individually co-branded, first with Microsoft, then with ServiceNow. Salesforce’s partner network is explicit about its purpose: it exists to scale Agentforce, and members get a direct line into Salesforce product teams.

Each of those is a rational commercial design, and each tells you something before the first workshop. A pod created inside a Microsoft practice is staffed, trained and measured against Microsoft’s platform. A pod inside the Salesforce network is measured on Agentforce reaching production. If the answer to your problem sits on that platform, you get specialists with roadmap access, which is genuinely valuable. If it does not, you are asking a team to recommend against the relationship that funds it.

This is the same argument we made about the labs’ own delivery arms in OpenAI’s DeployCo and Anthropic’s Ode versus an independent forward deployed partner. The argument has not changed, only its surface area. It used to apply to two model vendors. It now applies to most of the named field.

“Open” at the model layer is not the same as neutral

Deloitte’s Open Model Engineering practice deserves a closer look, because its vocabulary is close to the one we use. The announcement talks about flexibility, cost predictability, sovereignty and enhanced control over data, intellectual property, model behaviour and inference transparency, and about helping clients build sovereign AI stacks on open-source frameworks across North America, Europe and Asia Pacific.

That is a serious position, and its arrival from a firm of that size says where enterprise buyers are pushing the market. It is worth naming precisely what it does and does not settle. The practice initially builds on NVIDIA Nemotron open models and NIM microservices. Open weights remove one dependency: you can inspect the model, run it where your rules require, and you are not renting the intelligence inside someone else’s API. They do not remove the dependency one layer down, on a specific inference stack and the tooling around it.

So the buyer’s question splits in two. Can I change the model without rebuilding, and can I change where and how it runs without rebuilding? A partner can answer yes to the first and no to the second, and both answers matter over a system’s life. Model-agnostic delivery is a property of the architecture, of where the context, the retrieval, the evaluations and the guardrails live and who holds them. It is not a property of the model licence.

Independent analysts arrived at the same question

The concern is not confined to firms with a competing interest. Constellation Research published an assessment that credits the model’s value and names two risks: that forward deployed engineers get used as a crutch to smooth over immature vendor product, and that the market lacks vendor-neutral options. Its CEO Ray Wang draws a hard line on the role itself, saying a real forward deployed engineer takes the requirement back into the product and ships, and is not a sales engineer, a field CTO or an architect in a new costume (Constellation Research).

Forrester framed the same thing from the buyer’s side, describing forward deployed engineers as training wheels for AI reinvention (Forrester). Training wheels are useful, and they are also something you are meant to take off. A delivery model that leaves you permanently dependent on the pod that built the system has failed at the part that matters most to a company with an IT team it intends to keep.

What to put on the scorecard instead

Four questions survive the label going mainstream. All four are answerable in a first meeting, and none of them can be answered with a job title.

Which vendor relationship funds this pod? If the practice is co-branded, the answer is on the letterhead. If it is not, ask how much of the team’s certification and training budget is tied to a single platform. There is no wrong answer, only an answer you should know before you sign.

Who owns the context layer when you leave? The models will change. The reconciled, governed knowledge your agents read from is the asset that outlives them, and it should sit in your estate, portable, with provenance and freshness tracked. If the intelligence lives in the partner’s platform or the vendor’s model, you have rented it. That is the whole of our argument in what it actually takes to own your intelligence.

Is the team assembled around your architecture or around a certification? Pods built per vendor relationship are staffed by what the vendor certifies. Pods built per client are staffed by what the client’s stack needs, which in a European mid-cap usually means someone who can read a mainframe integration and someone who can argue with a works council, not a second platform specialist.

What is the number, and when? Every engagement should name a business figure agreed before the build starts, with a production date rather than a demo date. A pod that cannot commit to one is a discovery project wearing an engineering title.

We should be equally clear about our own shape. Nucleo is not neutral about everything: we hold that the intelligence layer belongs to the client and that AI is a re-architecture rather than a tool, and we will argue for it. What we do not have is a platform relationship paying for the engineers, which is a narrower and more checkable claim than “independent.” We run no certification network and no partner tier, so if your problem is genuinely best solved inside one platform, one of the practices above will beat us on depth and roadmap access, and you should hire them.

The label is gone as a filter. The structure it used to stand for is still the thing worth buying, and it is still visible if you ask who funds the pod.

FAQ

Is forward deployed engineering from Accenture or Deloitte the same thing as from an independent partner? The working method is similar, engineers sit inside your environment and build until something runs. The structure is not. Accenture’s practices are co-branded per platform, with Microsoft and with ServiceNow. Deloitte staffs separate forward deployed engineering tracks per vendor relationship, and its careers site lists them by name, including a Lead Anthropic Forward Deployed Engineer role. An independent partner has no vendor relationship funding the pod, so the architecture question stays open.

What should I ask a firm that pitches forward deployed engineering? Ask which vendor relationship funds the pod, whether the engineers are certified on one platform or assembled around your stack, and what happens to the work if you swap the underlying model in eighteen months. The job title answers none of those. The funding structure answers all three.

Does Deloitte’s Open Model Engineering practice make delivery model-agnostic? It moves in that direction at the model layer and states sovereignty, cost predictability and control over data, IP and inference transparency as goals. At the outset it builds on NVIDIA Nemotron open models and NIM microservices, so the model weights are open while the inference stack starts with one company. Open at the model layer and single-vendor at the inference layer are different properties, and a buyer should price them separately.

Is the forward deployed engineer label now meaningless? As a shortlist filter, yes. As a description of how work gets done, no. Embedding engineers in the client’s environment is still the right method. It has simply stopped being evidence of anything, so the diligence moves from the label to the org chart and the contract.

Nucleo builds the intelligence layer inside your estate, model-agnostic and governed to EU rules, with engineers embedded in your stack and a number agreed before the build starts. Tell us which vendor funds your current pod.