The FDE Playbook: Implementation as a Service

Every serious competitor now rents the same models on the same day. What is left to sell is implementation itself — the company-specific last mile, owned end to end. Here is why the capital moved, what the operating model actually carries, and how to tell an announcement from an outcome.

Scott Farrell · LeverageAI

Somewhere this quarter, a consultancy under margin pressure will send an email with the subject line Launching Our Forward Deployed AI Practice. Attached: a certification schedule, a transformation deck, a slide of new LinkedIn titles. Somewhere else, an enterprise will approve a headcount requisition for a forward-deployed engineer because the board asked what the company is doing about AI.

Neither organisation has necessarily bought anything. A title is not an operating model. And the gap between the two is where several billion dollars of 2026 capital allocation is currently sitting, waiting to find out whether it was well spent.

This is the playbook at the head of a thirteen-piece body of work on forward-deployed engineering — twelve deep modules and this synthesis. Its job is narrow and specific: explain why the category exists, what capital is actually buying, what must be true for the movement to endure, how to separate the real thing from the rebadge, and where every deeper argument lives.

1. Everyone rents the same brains

Start with the premise, because everything else is downstream of it.

Frontier capability is symmetric. Every competitor rents the same models, from the same handful of labs, on the same day they are released. Whatever advantage a new frontier model confers, it confers on everyone at once — which means it confers durable advantage on no one. Symmetry is the exact opposite of a moat.

That is not an FDE argument. It is an argument about where value can possibly live once a capability becomes a purchasable input, and it was written in this corpus before the job title went mainstream. A practitioner in the field puts the same thing more bluntly: if everyone can access it, intelligence can no longer be the moat — so the advantage goes into deployment. The edge is no longer who has the intelligence. It is where, how and why they use it.

Demos close deals; deployments keep them.

The empirical shape agrees. Roughly 40% of AI agent projects never reach production, and the gap is architectural rather than a matter of model choice or prompt engineering.¹ An MIT NANDA study of 300 enterprise AI projects found the overwhelming majority produced little or no measurable P&L impact — the models worked; the deployments didn't. McKinsey names the moment we are now in:

"In 2026, many enterprises will realise that while AI technology is advancing fast, significant value won't materialise without the fundamentals — modern IT architecture, high-quality data, capabilities, operating model, and change management. We'll see a tougher 'audit moment' where programmes fall short not because the models underperform, but because the enablers and economics weren't in place."²

Read that carefully. Every item on the list is company-specific. None of it is rentable. All of it lives in the last mile.

2. What the money actually bought

The investment record is unusually legible, because the buyers announced themselves. In dated order:

That is not "billions going into AI". It is capital moving into a very particular shape: embedded deployment, reusable partner-owned delivery IP, firm-wide context, evaluations and governance, production engineering, and the conversion of conventional consulting benches into AI-native delivery practices.

The role definitions from the originators say the same thing in operational language. Palantir's distinction is the cleanest in the category: a product engineer works on one capability for many customers; a forward-deployed engineer brings many capabilities to one customer.⁸ OpenAI's live postings are blunter still — own discovery, technical scoping, system design, build and production rollout, and measure success through production adoption, workflow impact and eval-driven learning rather than the completion of architecture artefacts.⁹

Meanwhile the model this displaces is under visible strain. KPMG Australia's FY2025 consulting revenue fell 18%.¹⁰ Deloitte recorded its first UK revenue decline in fifteen years. PwC UK cut headcount. McKinsey's workforce fell by more than 10% from its 2023 peak.¹¹ In Australia the pressure is not merely cyclical: parliamentary inquiries have recommended stronger accountability obligations, and a Deloitte report for the federal government containing fabricated references — including a fabricated court quotation — ended in a partial refund.¹²

3. Announcements are not outcomes

Here is the discipline the movement mostly lacks, and the single most useful thing you can take from this piece. Before you count a piece of FDE evidence, classify it.

Now apply it to everything in section 2. The dollar figures are E2. The role definitions are E1. BCG's revenue growth is E3 — it proves applied work is being bought, not that it worked. Almost nothing in the public FDE record reaches E4, and nothing at all reaches E5.

The E4 tier that does exist tends to be production-engineering evidence rather than forward-deployment evidence. Wells Fargo's assistant handled 245.4 million interactions in 2024 across a portfolio of more than 600 production AI use cases, without exposing sensitive customer data to the language model — enabled by privacy-first architecture, systematic testing and production-grade observability.¹ That is a genuine buyer-side outcome with numbers attached. It is also not labelled forward-deployed, and it would be dishonest to conscript it as proof of a staffing model.

The strongest evidence for the movement is also the weakest evidence for its outcomes.

This is not a reason to dismiss the category. The structural argument stands on its own: capability is symmetric, the difficulty is local, and someone has to own it. But it is a decisive reason to stop treating job-posting counts, funding rounds and vendor announcements as though they were results — and to notice that the one programme in the timeline building an E4 requirement into its own structure is Anthropic's, whose higher partner tiers are gated on production deployments and public customer stories rather than on certifications.⁵ That is the market grading its own evidence, and it is the most encouraging signal in the set.

4. What the role actually owns

Strip the recruiting gloss and the definition is operational. A forward-deployed engineer sits close enough to the work to learn how it is performed, not only how it is described. They exercise commercial and technical judgment in one head: which steps need model judgment, which should stay deterministic software, which must stay human. Then they ship something that runs inside the systems the business already owns — and when it breaks, it is their problem.

Three joined jobs, usually split across three functions.

Discovery, by observation. The documented process is rarely the real process. "An email arrives" sounds like a clean trigger; in practice it arrives from forty-odd senders, no two formatted alike, data in the body or a PDF or a screenshot or six replies deep in a forwarded thread. Half are exceptions in disguise — same as last time, ignore the second attachment, Sarah already signed off on this one — and the routing logic lives entirely in one person's head. Schedule a one-hour interview and you get what someone thinks their job is. Sit with them for a shift and you see the job. That discovery is not preparation for the work. It is the work.

Placement judgment. Of ten steps in a workflow, perhaps three actually need judgment. The rest are conditionals and API calls. Deciding, step by step, which cognition each step needs — deterministic software, model, or human — is the scarce skill, and it includes the negative case: some workflows should not be touched by AI at all, because the risk is wrong or the return is too thin or it is already automated.

Build and own. Not a prototype handed over. Working software carrying operational responsibility inside the business, integrated with the systems that already exist rather than predicated on a migration nobody asked for. If a client has just spent two years and several million dollars moving to a new ERP, an AI proposal that begins with "first, move off it" is dead on arrival.

The recognition test is an artefact, not a conversation. Ask for the operating map: current-state workflow as actually performed; future-state workflow with intelligence in the right places; one selected use case chosen for value rather than twenty parallel pilots; boundaries on what the system may and may not do; the human approval points; and quantified value stated as claims you can later measure. Without that map, teams skip to agents and discover late that they automated the wrong steps, ignored the exceptions, or built a parallel system nobody adopts.

5. Costume or capability: how to tell

Since the money arrived, the rebadging has too. The category already has a name for it: FDE-washing — title adoption without the machinery that makes the title honest. And the warning comes from inside the movement as much as outside it; practitioners hiring for these roles report a growing population of people who are neither the strongest communicators nor the strongest engineers, sitting in a job that requires both.

Two instruments separate the real thing from the costume.

The boundary matrix

Every one of the first five roles is legitimate and often necessary. The point is that none of them is the sixth, and that "embedded", "technical" and the FDE job title are not synonyms for end-to-end accountability.

The anti-washing rubric

Eight questions. All answerable with artefacts; none answerable with a title.

1. Show me the operating map. Current state as performed, not as documented.
2. Show me the eval report. Cases, pass rate over graded runs, failure categories with the evidence kept, and the confidence threshold at which the system must escalate.
3. Who is the named business sponsor, and does the engagement lead report to them rather than into a BAU IT delivery queue?
4. What decisions can the pod make without a committee, and which are explicitly reserved?
5. What is the golden path, and was it authored before this engagement started?
6. What does the engagement leave behind — tests, runbooks, reusable patterns, an updated client knowledge base — and is that in the contract?
7. What did engagement two cost compared with engagement one, and who led it?
8. What has this team refused to build, and why?

Question seven is the one that matters most and gets asked least. Titles are cheap. Transfer is not.

6. Where it sits, and why that decides everything

The most common way a forward-deployed engagement fails has nothing to do with technology. It is structural: the pod gets absorbed into the organisation that was already slow, and inherits its queue.

The refinement that resolves it is precise:

The FDE pod operates outside BAU IT line management, prioritisation queues and project methodology, while using enterprise-approved infrastructure, security controls, data access paths and production standards.

Not shadow IT. Not another IT resource. Structurally separate, strategically connected. Too integrated and the FDE becomes another resource waiting on tickets, design boards and release trains. Too separate and it becomes an innovation lab producing impressive prototypes that cannot reach real data.

This is not a contrarian position. BCG argues the AI impact agenda must be owned by the CEO and business leaders — the P&L owners — and not delegated to IT, with central governance setting standards while small cross-functional teams own business journeys end to end.¹⁴ McKinsey's July 2026 research goes further, recommending a dual operating model in which transformation pods carry different decision rights, performance metrics and talent models from the wider organisation.¹⁵ McKinsey also documents the failure mode: companies create apparently agile teams while preserving the serial path from strategy to product to architecture to development, and delivery still takes months.¹⁶ Even the academic literature converges — executive sponsorship, cross-functional integration and systematic risk assessment are the mechanisms that overcome departmental fragmentation.¹⁷

Which turns into a negotiable instrument. Before an FDE enters a client, agree a deployment charter covering: the named executive sponsor with authority to remove blockers; the reporting line; the technical partner who supplies access without owning the backlog; the governance partner who defines requirements rather than being discovered one committee at a time; the end-to-end remit; the pod's decision rights; the client's reserved decisions; success measures expressed as workflow impact and adoption rather than workshops and ARB appearances; what knowledge transfers; and one rapid escalation path.

Then make governance executable rather than archaeological. The client supplies a pre-approved golden path — environments and models, identity and secrets, data classifications, integration patterns, observability, minimum eval suites, CI/CD and rollback, risk tiers and approval requirements, release criteria, kill switches, evidence requirements, and an exception route with a committed response time. Governance authors the doctrine once; the engagement consumes it.

And then do the thing consulting agreements almost never do: put the clock in the contract. When AI can build in days, client waiting time becomes the dominant schedule risk. Track days blocked awaiting access, days awaiting decisions, exception response time, release latency, unavailable SME time. Negotiate a governance latency budget — a business day for routine golden-path decisions, two for access and environments, three to five for formal exceptions, automatic sponsor escalation for unresolved cross-functional blockers. The numbers are starting points, not benchmarks. The principle is not negotiable:

The FDE cannot be accountable for AI-speed delivery while the client reserves committee-speed decisions.

7. The hard questions

A thesis worth holding should be attacked by the person holding it. Four objections deserve better answers than the movement is currently giving.

Services don't scale. True, and ring-fenced pods with protected capacity make it worse, not better — you are buying senior-heavy staffing and refusing the leverage of the pyramid. The only honest answer is that the compounding has to be real: field patterns promoted to platform through a governed gate, with recurrence nominating and never automatically promoting; and engagement two demonstrably cheaper or better than engagement one. If neither happens, forward deployment is a margin trap wearing a better name.

Talent is the bottleneck. The role demands two kinds of judgment that rarely co-occur in one person, and the market response — hire unicorns, or train everyone for years — treats scarce judgment as a headcount problem. It is an infrastructure problem. Compile the repeatable judgment once, instantiate it per practitioner against each client, patch it once, and the whole bench upgrades. That is a claim with a clear falsifier, and the falsifier is engagement two.

Confidentiality versus compounding. What compounds is client-specific, and clients did not pay to fund your reusable IP. The resolution is a governed promotion protocol with five possible dispositions for any field pattern — local-only, configurable, internal primitive, supported platform, or reject — with de-identification, contract clearance and a human gate before anything moves upward, and rejections preserved rather than deleted. "Paid discovery" is only honest under reciprocity: the customer gets useful delivery now, with explicit learning rights.

It might be a transitional role. Platforms will absorb some of this. Better connectors, default eval suites, governance primitives — the tooling floor rises every quarter, and roles built on a capability overhang have a habit of thinning. The counter-observation is that AWS's own partner model is explicitly designed so the harness stays with the partner rather than the platform, which is the opposite of absorption. Both can be true: the floor rises, and the scarce judgment moves up with it. What stays constant is that someone must own the last mile.

When forward deployment is the wrong answer

• Commodity implementation. If the problem is well understood, the pattern is standard and the vendor's default configuration fits, you are paying senior rates for work that does not need judgment.
• A well-specified standalone product. If the requirement is genuinely stable and generic, build it as a product with product economics. One capability, many customers — that is the other job.
• No path to production ownership. If the engagement cannot reach production — no sponsor, no data access, no golden path, no protected capacity — do not take it. Without a sponsor it becomes an IT experiment. Without a golden path it becomes an approval project. Without direct business access it automates somebody's description of the work.

And the most underrated deliverable in the model: the refusal. If the first bounded test shows the inherited recommendation was wrong, rejecting it is engagement success — not a failure to implement the deck. Write that into the statement of work, so that being the adult in the room is a contracted outcome rather than a personality risk.

8. What to do on Monday

1. Classify your evidence. Take every FDE claim currently in front of you — vendor, internal, or press — and label it E0 to E5. Notice how much of your confidence rests on E0 and E2.
2. Ask for the two artefacts. An operating map and an eval report. Any supplier who can produce both is having a different conversation from one who can produce neither.
3. Write the charter before the engagement. Sponsor, reporting line, remit, decision rights, reserved decisions, success measures, transfer, escalation. If you cannot fill in the sponsor row, you have already found your first problem.
4. Publish the golden path. If your governance function cannot hand a delivery team a pre-approved route with an exception lane and a response-time commitment, your delivery teams are doing archaeology and you are paying for it by the day.
5. Instrument the latency. Two weeks of counting blocked days will tell you more about your AI programme's real constraint than another architecture review will.
6. Design the second engagement now. Decide, in advance, who will lead it and what will be cheaper because of the first. Then hold yourself to it.

Where each argument lives

This piece is deliberately a map rather than a territory. Each claim above is developed properly somewhere else in the series:

• Someone Has to Decide Where Intelligence Belongs — the role, its scarce judgment, and the operating map.
• Proof-Carrying Transformation — the seven packages and four gates; borrowed versus transferable authority.
• Compounded Execution Capital — the individual's compiled career, and why the marketable unit is delivery fidelity rather than speed.
• Sell the Compression, Not the Components — how to prove broad capability without a catalogue of claims.
• Forward-Deployed Practice OS — scaling judgment across a bench, and the naming of FDE-washing.
• Internal Deployment Is the Go-to-Market — the firm as customer zero.
• Retail MCP Is the Doorway, Not the Memory — why engagement continuity must belong to the platform.
• Engagement World — the persistent project reality between institutional memory and the context window.
• FDE Delivery Looks Like Waterfall Per Increment — gated delivery under cheap generation.
• The FDE as Paid Product Discovery — turning field exceptions into deliberate platform decisions.
• AI That Survives Audit — carrying an intervention through Australian enterprise approval.
• The Engagement Auditor Is Not the Janitor — separating epistemic audit from structural maintenance.