Forward-Deployed Engineers Won't Fix Your Stalled AI Pilot
    AI Strategy & Economics

    Forward-Deployed Engineers Won't Fix Your Stalled AI Pilot

    Every enterprise AI vendor is pitching the same fix right now: more forward-deployed engineers. Here's why that headcount play skips the seam where pilots actually die.

    Nathan Barrett
    Nathan Barrett

    Chief Product Officer

    September 11, 2026
    8 min read
    Share:

    The industry's answer to stalled enterprise AI is now headcount: put engineers on-site by the hundred. Having sat inside those stalls, we think the constraint was never the number of engineers.

    On September 8, 2026, Accenture and Google Cloud launched the Accenture Gemini Enterprise Business Group, with a stated plan to establish a 1,000-person forward-deployed engineer (FDE) workforce on top of nearly 50,000 Google Cloud-skilled professionals (Accenture). If you buy enterprise AI, you'll be pitched some version of this all quarter. Worth being precise about what it solves and what it doesn't.

    The pro-FDE case is real, start there

    Embedded forward-deployed engineers are genuinely good at the hardest part of enterprise AI: turning something that works in a sandbox into something an organization is willing to run in production. Accenture CEO Julie Sweet's framing, "Clients want clear value and they're stuck," is an accurate read of the market (WSJ). Scale buys reusable accelerators, industry templates, a deep bench. And MIT-based reporting found that purchased solutions from specialized vendors and partnerships succeed about 67% of the time, roughly twice the rate of internal builds (Fortune). Buying from a partner works. That isn't where we disagree.

    The argument is about which seam the pilots die in, and whether more engineers at the front of the engagement closes it.

    The stall happens after the build

    Look at the published reasons projects die. Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls (Gartner).

    A Gartner survey of 782 infrastructure and operations leaders, published April 7, 2026, found only 28% of AI use cases fully succeed and meet ROI expectations (Gartner). Success was tied mainly to integrating AI into existing workflows and securing full executive support.

    MIT NANDA's work found that most pilots stall with little measurable P&L impact (Fortune). Its lead author blames a learning and integration gap, not model quality.

    None of those are engineer-supply problems. Cost, ROI proof, risk controls, and workflow fit are all owned in production, months after the demo lands.

    Which is why one detail in the WSJ coverage matters more than the headline number: Accenture's FDE pods "typically then pass the project on to other Accenture counterparts to handle the actual scaling" (WSJ). That handoff is the seam. The people who built the thing aren't the people who answer for it when the bill arrives.

    Treat the failure-rate numbers as directional rather than settled. Several of the biggest figures in circulation reach readers through secondary aggregators, and sample sizes are modest. The direction of the evidence holds even where the precision doesn't.

    Argue about the delivery contract

    Be fair about the label. Forward-deployed engineer job postings rose more than 729% year-over-year in April 2026 per Indeed data, and ex-Palantir practitioner Piotr Kraus notes many organizations now call "an FDE anybody who's customer-facing and a little bit technical" (LeadDev). Forward deployment also went institutional across 2026: OpenAI, IBM Consulting, ServiceNow with Accenture, Deloitte, an AWS partner program (Magma). A 1,000-FDE commitment is a category move, not a differentiator.

    Palantir's global head of commercial, Ted Mabrey, put the sharper version of the critique: "every replicant I've encountered is a half measure," copycats replicate the form of the model without aligning their economics to customer outcomes (Substack). That critique lands on any firm that bills time rather than outcomes, including small ones. So skip the argument about titles. Argue about the contract. The label matters less than what the forward-deployed engineer is empowered to own once code ships.

    Five questions to put to any AI delivery partner

    • Who owns the system in month seven? Get a named team on the page. If the build team hands off to a scaling team, ask who carries the outcome across that line.
    • What SLA covers the agent in production? Uptime, incident response, and who gets paged at 2 a.m.
    • What happens at the funding gate? Who produces the cost and value evidence the CFO will ask for, and in what format?
    • When is governance configured, sprint one or sprint nine? Ask for the sprint number in writing.
    • What reusable assets sit underneath the engagement? Without a platform beneath it, a forward-deployed function "is just a dev shop whose maintenance costs eat it alive" (Magma). That test applies to us too. We hold ourselves to it by building and running Companion on our own platform.

    Cost accountability has become part of the buying decision

    Picture month seven. The pilot works, traffic is real, and an invoice lands on the CFO's desk that nobody modeled during the build. Who explains it? That question, more than any capability demo, decides whether the project gets its next round of funding.

    The money side of this has moved fast. The FinOps Foundation's sixth annual State of FinOps survey landed February 19, 2026: 1,192 respondents representing more than $83 billion in annual cloud spend. It found 98% of practitioners now manage AI spend, up from 31% two years earlier, with "FinOps for AI" the top forward-looking priority (Linux Foundation). The same survey shows practitioners prioritizing "shift left": embedding financial context earlier in the engineering lifecycle so teams decide pre-deployment rather than remediate after the invoice (Linux Foundation).

    This matters because pilot economics tell you almost nothing about production economics. Cockroach Labs, citing a March 2026 Gartner analysis, reports that agentic models require between 5 and 30 times more tokens per task than a standard chatbot (Cockroach Labs). Multiply a successful demo by real traffic and a multi-step loop, and the funding gate is where the project quietly dies. Reporting from PointFive collates the picture: 79% of enterprises had AI cost overruns in the past 12 months, while only 26% report full real-time visibility into what their AI costs to operate (PointFive).

    The practical fix is per-model spend tracking wired into the same GCP billing the customer already has, reviewed on an hourly refresh. A cost model belongs in the first sprint alongside the architecture, with the same seriousness.

    Governance in sprint one is a scoping choice

    Here's the part that undercuts the headcount argument most directly. Google Cloud launched Gemini Enterprise Agent Platform on April 22, 2026. It represents the evolution of Vertex AI. Google stated that all Vertex AI services and roadmap evolutions will be delivered exclusively through Agent Platform (Google Cloud). It ships several new capabilities:

    • Agent Identity, Agent Registry, and Agent Gateway
    • Agent Simulation, Agent Evaluation, and Agent Observability with full execution traces
    • Access to more than 200 models through Model Garden, including Anthropic's Claude (Google Cloud)

    In plain terms:

    • Agent Identity: gives each agent a principal the same way a service account does, so you can write perimeter and access rules about it.
    • Agent Registry: the inventory. Which agents exist, who owns them, and which version is running.
    • Agent Gateway: the doorway agents pass through to reach internal systems and data, where you put controls on what they're allowed to touch.

    Google has also extended VPC Service Controls to agents: administrators can use agent identities directly in perimeter ingress and egress rules via standard IAM principals (ITBrief).

    Read that plainly. Identity, registry, evaluation, observability, and network perimeter are platform-native now. Capabilities are moving quickly and the launch material doesn't label each one's release status, so confirm current availability before you architect against a specific piece. But the shape of the conclusion holds: if a partner defers governance to a later phase, that's a scoping decision, not a consequence of team size. Nobody needs a thousand engineers to put an agent inside an existing perimeter and bill it to the commit the customer already has.

    One fair criticism of embedded models deserves a straight answer: dependency. Forward-deployed engineers who never leave become a single point of failure. The counter is documentation, inherited platform controls, and a retainer the customer can size down. Production ownership should be an auditable service with named substitutes.

    The honest version of the argument

    We're a smaller partner making a reasoned case rather than citing a settled one, no source we found measures FDE program outcomes at scale. A forward-deployed engineer who lacks authority over production economics can't close the seam this piece describes. Scale and embedded engineers both deliver real value. But every failure cause the published research names is owned after the handoff that the pod model builds in by design.

    So ask the month-seven question before you sign anything. If you want that conversation grounded in your own estate, our Claude on Google Cloud Enablement engagements start with Discovery and Assessment, governance and cost modeling scoped into sprint one.

    Topics

    AI StrategyFinOpsAI GovernanceCloud CostEnterprise AI

    Continue Reading

    More articles in this series

    View all articles