On September 8, 2026, Accenture and Google Cloud announced the Accenture Gemini Enterprise Business Group. Google Cloud will train up to one thousand Accenture engineers, embed them inside client offices, and let them write production Gemini applications directly on the customer's own systems. The label these engineers wear is forward deployed engineer.
Nine weeks earlier, on June 30, AWS pushed one billion dollars into its own forward deployed engineering hub, seeded with thousands of engineers meant to sit inside enterprise customers rather than at re:Invent booths. In a single two-week stretch in May, ServiceNow with Accenture, Cognizant, Anthropic and OpenAI all formalized forward deployed engineering programs. Anthropic prefers the label Applied AI Engineer. The role is the same one.
Reading that timeline in order tells you what actually happened this year. Forward deployed AI engineering, the label the industry has now standardized on, is a concession. The AI labs looked at their enterprise deployment numbers and stopped pretending the models sell themselves.
The 95% number is why
The MIT Media Lab's Project NANDA report from July 2025, "The GenAI Divide: State of AI in Business 2025," put the failure rate of enterprise generative AI pilots at 95%. The base is real. NANDA interviewed 150 leaders, surveyed 350 employees, and pulled apart 300 public deployments. Somewhere between thirty and forty billion dollars of enterprise spend produced no measurable P&L impact for the vast majority of buyers.
The report is careful about the cause. Every failure mode sits downstream of the API call. Brittle workflows, weak contextual grounding, and handoffs into legacy systems built for a different era account for the gap. The models were competent. The plumbing was not.
For a lab that sells API calls, this is a hard read. You can ship a stronger model each quarter and watch it die on the last mile of every client. So Anthropic, OpenAI, Google, and AWS all did the same thing at once. They stopped shipping only the model. They started shipping a person with the model.
Palantir was the tell
The forward deployed engineer role did not come from the labs. It came from Palantir, in the early 2010s. Palantir was selling to intelligence agencies that could not write a normal requirements document, because the requirement was classified from the vendor and the vendor was classified from the requirement. Traditional software delivery could not thread that hole. So Palantir sent engineers into the agency, sat them at the desk, and let them write the software against the real data.
The model worked so well that Palantir has posted 640% share price growth over five years, 85% revenue growth in the first quarter of this year, and 133% growth in its US commercial book. Every consultancy in the room this year has looked at that P&L and concluded that the embedded engineer is not a mode. It is the whole business.
That is why the September 8 announcement matters. The AI labs are not experimenting with a new role type. They are conceding that Palantir was right about how enterprise AI actually reaches production, and they are copying the model at scale, one thousand engineers at a time.
What you are actually buying
If you are the buyer, the language will land as good news. Someone will sit at your desk. They will know the model. They will write the integration. They will hold accountability for the outcome rather than for the artifact. The role even comes with a salary tag that reads as serious. OpenAI's forward deployed engineers earn between $160,000 and $280,000 at the mid level, and $350,000 to $550,000 at the senior end. Anthropic's Applied AI Engineer job spec asks for six years of experience plus prior technical advisory work into large enterprises.
That is the pitch. The pitch is real.
What the pitch does not say is who the engineer works for.
Read the Accenture posting for a Palantir forward deployed engineer, or the Anthropic Applied AI Engineer job description, or the OpenAI FDE listing that surfaces on every recruiter site. In every one of them, one line does the same job. The engineer's remit includes feeding insights back to Product, Engineering, and the wider Applied AI team at the vendor. That is a normal line for a vendor employee to carry. The buyer, sitting on the other side of the desk, often skims past it. It is the clause that decides the whole arrangement.
The engineer is on the vendor's payroll. Their bonus depends on how much product they get you to deploy. Their promotion depends on what they learn from your data flows, your integration seams, and your workflow ontologies, and on their ability to carry those patterns back into the vendor's roadmap.
The AI labs are not being duplicitous about this. The Anthropic listing says the loop out loud. What they are doing is renting you a very capable engineer under an arrangement where the strategic asset produced by the work, the map of how your business turns AI into money, gets shipped home at the end of the quarter.
The knowledge sits on their side of the wall
Every deployment produces two artifacts. There is the running code. Then there is the tacit knowledge of what actually made it run. Which of your teams had the clean data. Which of your workflows are orchestrated versus theatrical. Which of your reports drive real decisions and which are ceremony. Which vendor of yours will resist and which will lean in. Which director will approve budget for the follow-on phase, and which will kill it.
The code stays with you. The tacit map goes home with the engineer.
That map is what the vendor will use to sell you the next module, and, more importantly, to sell your competitor a version tuned to the seams they saw at your site. The forward deployed model is a two-way flow. The labs are honest that this is how they intend to improve their own product. The buyer is often not modeling what leaves the room when the forward deployed engineer flies out on a Friday.
Palantir's clients spent a decade discovering this. The ones that got real value out of the Palantir engagement were the ones that built their own bench of forward deployed engineers alongside the Palantir team, so the tacit knowledge of the workflow stayed in-house even after Palantir moved to the next contract. The ones that treated Palantir as a delivery vendor got a running system and lost the ability to change it.
Forward deployed AI engineering is the shape of enterprise AI now
Forward deployed AI engineering is the operating model the major labs and consultancies are now using to close the deployment gap that NANDA measured. It is worth being blunt about what that means for the executive on the buy side. The default arrangement of enterprise AI has stopped being product delivery. It has become embedded services.
That is fine, and often correct, at the discovery stage of any real AI program. Nobody, including your own engineering team, knows on day one which parts of your operation will actually pay when you point a Claude or a Gemini or a GPT at them. The value of an embedded engineer is precisely that they can compress the discovery loop from six months of committee work into six weeks of shipping code against your real systems.
The mistake is confusing that with a long-term architecture. Six months in, the vendor's forward deployed engineer knows your operation better than most of your directors do. They are just optimized. The vendor optimizes them to renew the contract, upsell the module, and feed the roadmap. Your interests, as the client, are optimized only insofar as the renewal depends on the results you can see.
The three roles you need to keep in-house
There are three roles no organization should ever outsource to a vendor's forward deployed team. Keep these three in-house and the vendor's engineer becomes a force multiplier on your own bench. Outsource them and the vendor becomes the operating system of your AI program, with you as the customer of your own workflow.
The first is the person who owns the evaluation harness. Whoever writes the tests that decide whether a Claude output is a good enough answer for your billing team, or your underwriting desk, or your ticket triage, defines what "working" means for your AI. That definition is your strategy expressed in code. It cannot live on the vendor's laptop. It has to live in your repository, be reviewed by your product owners, and be readable by your compliance team without a translator.
The second is the person who owns the integration graph. Someone in your organization has to be able to draw, from memory, the map of which agent calls which internal API, which system of record, which human reviewer, which external vendor. If only the vendor's forward deployed engineer can draw that map, the vendor is your architecture. When they rotate to the next client, your architecture rotates with them.
The third is the person who owns the failure log. Every enterprise AI system fails in ways specific to the enterprise it runs in. The pattern of failure is more valuable than the pattern of success, because the failure log is what you use to steer the next quarter's investment. If the vendor holds the failure log, the vendor steers your investment. If you hold it, you do.
None of these roles requires you to build a lab. They require you to build a bench of three to six engineers who report to your CTO, sit next to the vendor's forward deployed team, take handoffs of every artifact the vendor produces, and refuse to sign off on any piece of production code they cannot themselves modify. That is the architecture that turns a forward deployed engagement into an asset. Anything less turns it into a lease.
The buy-side reversal you have to run
The vendor arrived with the engineer. Fine. That was the sale, and the September 8 announcement is proof it is now the industry standard motion. Your job as the buyer is to run the reversal.
Every forward deployed engineer the vendor puts on your site should be shadowed by one of your own. Every integration written by the vendor should be pair-programmed with your engineer, not delivered as a finished artifact. Every evaluation script the vendor writes should live in your repository, run in your CI, and be readable by someone who does not work for the vendor. Every failure mode observed on your workflows should be logged in a system you own, not in the vendor's Notion.
The arithmetic is straightforward. The vendor's engineers, however talented, run on a rotation schedule. Your systems run on a permanent one. The knowledge has to be captured at the pace it is generated, or it walks out the door with the engineer who generated it.
Handled well, the forward deployed model is the fastest path from generative AI pilot to real P&L impact that the enterprise has ever had access to. NANDA's 95% failure rate is a measurement of what happens when the model is treated as a product. The 5% who found real value did it by treating the model as a partner and by owning the integration themselves.
What you should not do
You should not fire your consulting agreement in a fit of independence. The AI labs and their consultancy partners have built something real, and pretending you can replicate a thousand-engineer bench inside your own IT organization in a year is a fantasy that produces the same 95% failure rate the forward deployed model was invented to fix.
You should also not sign the standard master services agreement without a knowledge escrow clause. Ask the vendor's counsel to add a schedule that names the evaluation harnesses, the failure logs, the runbooks, and the integration diagrams that must be delivered to the client's repository at every phase gate, with the client owning the copyright on the tacit artifacts. If the vendor refuses to accept that language, the vendor has told you what the forward deployed program is really for.
You should not let your own engineers report into the vendor's forward deployed lead. The reporting line matters. If your engineers report into the vendor's engineer, the loyalty and the promotion criteria run in the vendor's direction. If the vendor's engineers report, dotted-line, into your CTO for the length of the engagement, the loyalty and the promotion criteria stay pointed at your outcomes.
Architect the engagement, do not accept it
None of this is available on a menu. Every forward deployed engagement I have seen in the last twelve months has arrived from the seller as a boilerplate SOW that gives the vendor's engineer authority to write into the client's systems, learn the client's workflows, and shape the client's roadmap. The clauses that protect the buyer are always ones the buyer had to author.
Architecting the engagement means rewriting that SOW before it is signed. It means building the in-house bench that shadows the vendor's team from day one. It means naming, in the contract, which artifacts belong to the client and which belong to the vendor. It means designing the failure log, the evaluation harness, and the integration graph as client-owned systems that outlive the vendor.
That work is strategic architecture. The vendor whose engineers you are hiring cannot deliver it, for the obvious reason. A second consulting firm cannot deliver it either, because their commercial model is the same one.
That is the work Agor AI Advisory does. We sit on the buy side. We are not a delivery partner of any lab or hyperscaler. We help executives design forward deployed AI engagements that ship pilots into production without leasing the strategy. We build the in-house bench, write the shadow architecture, negotiate the knowledge escrow, and stay on until your team can operate the system without us. Then we leave, and the map stays with you.
Sources
- Accenture and Google Cloud launch Gemini Enterprise Business Group, September 8, 2026
- Google Cloud races to catch up in the AI deployment wars with Accenture deal, TechCrunch, September 8, 2026
- AWS puts $1 billion into new AI unit to embed engineers with customers, CNBC, June 30, 2026
- Why OpenAI and Anthropic are hiring forward deployed engineer teams, The New Stack
- MIT Report Finds 95% of AI Pilots Fail to Deliver ROI, Exposing "GenAI Divide"
- Applied AI Engineer, Enterprise, Anthropic careers listing
- What Is OpenAI's Forward Deployed Engineer?, Paraform, June 2026