Peregian Digital HubAI Adopted

Forward deployed

Forward Deployed Engineers: Embedding AI expertise in organisations

What the FDE role is, why organisations are hiring for it, how to do it well, and the real work that happens when an AI specialist embeds inside a business to deploy agents.

A Forward Deployed Engineer (FDE) is an AI specialist embedded inside an organisation to discover, build, and hand over AI-agent solutions for real work, then move on. As agents enter knowledge work across the business, organisations face a gap: their internal teams lack the depth to deploy and refine agent workflows alone, and vendors cannot staff every client. The FDE role is how markets solve that gap. It is rapidly expanding—the market went from nearly zero dedicated FDE roles three years ago to a priority hire across enterprise vendors, AI labs, and their startup partners.

The emergence of the FDE role

The FDE model is not new. Tom Blomfield pioneered it at Palantir decades ago as a way to solve deeply heterogeneous customer problems that no single product could address off the shelf. Bob McGrew, former Chief Research Officer at OpenAI who worked the model at Palantir, describes the core FDE mechanism: embedding engineers at customer sites to fill the gap between what the product does and what the customer needs, then generalising those site-specific solutions into platform features that serve the next ten customers. AI agents, specifically, have triggered explosive growth in the role: McGrew argues that AI agents are a new market category with no incumbent product, and FDE-led on-site discovery is essential because the market itself is not yet defined. Unlike chat products or traditional software, agents demand deep integration into customer workflows, custom tooling, and ongoing refinement as the organisation learns what is possible. An FDE lives inside that discovery and implementation loop.

The scale of the shift is visible in hiring. McGrew notes that twenty-plus YC startups now hire FDE roles, up from nearly zero three years ago, and Meta, Anthropic (in partnership with Blackstone and Hellman & Friedman), OpenAI, and Aaron Levie, CEO of Box, all describe launching or expanding FDE units. Levie calls the internal FDE the highest-demand hire in tech. The reason: there is vastly more agent deployment work than there are people trained to do it.

The work itself: what FDEs spend time on

The work an FDE does once embedded is not writing production code in the traditional software sense. It is diagnosis, wiring, and change management. Levie describes the work required: upgrading IT systems, provisioning agent context, modernising workflows around human-agent handoffs, and managing adoption and change. It is not a one-time setup: each model upgrade creates fresh work to capture gains or redeploy scaffolding, as new breakthroughs force rearchitecting.

The bottleneck is often not the agent itself but the organisation's readiness. The "Bob and Sally problem" is a common one: Bob has too much access, Sally has too little, and the agent either bounces off an entitlement wall or, worse, answers questions using data it should not have seen. Data silos are another constant: contracts stored in five different places, roadmaps across 30 locations, no consistent definitions of metrics. When every employee gets an MCP connection to the data warehouse, bad definitions become a company-wide problem. An FDE spends significant time mapping and rebuilding these foundations. Integration work—systems, context, workflows, change—is where the constraint lies, not capability alone.

Beyond data and infrastructure, FDEs help organisations rethink workflows themselves. Background agents will consume more tokens than chatbots, yet most organisations have not redesigned their processes for unattended work. An FDE identifies candidate workflows (contract review feeding into a project-tracking system, invoice processing, M&A due diligence, client onboarding), wires the agent, and helps staff transition from "chatting with AI" to "AI working in the background while we do other things." The transition is not automatic; it requires rethinking handoffs, defining where human judgment enters, and often retraining how a team thinks about their own work.

The FDE playbook: from discovery through generalisation

McGrew's core playbook rests on three moves: embedding two distinct team types on-site, outcome-based pricing, and demo-driven development.

Team structure and roles

McGrew describes two roles that work in tandem on customer sites: Echo teams and Delta teams, each with a distinct profile.

Echo teams work on diagnosis and discovery. Echo hires need domain rebels—people who recognise existing processes are broken—people from inside the customer's industry who already understand how things could be different. An Echo person already knows what good looks like in that industry, which problems are worth solving, and what customers actually need rather than what they say they need. They live on-site, walk the floor, sit in on meetings, and build deep relationships with the business side. Their output is diagnosis: here is the real problem, here is what the agent should solve, and here is how the workflow should change.

Delta teams are the rapid builders. They accept throwaway code rather than architects optimising for long-term maintenance. A Delta person's job is speed: build a working prototype of the agent, test it against real workflows, learn what breaks, and rebuild it. They are ruthless about iterating, not preserving. Once the agent and workflow are working, the Delta work is largely disposable—the generalised platform version will replace it—so the skill is rapid learning and iteration, not construction.

Outcome pricing and aligned risk

McGrew emphasises that pricing structure matters to the engagement model. Startups sell the successful result of solving a problem, not just software, so early risk sits with the startup and enterprise buy-in focuses on executive leadership rather than IT gatekeeping. When both sides are paid for the result, both stay focused on the customer's actual problem, not feature creep or scope bloat. It also aligns incentives: if the agent does not work, the startup has not been paid, so the startup's entire attention is on working delivery, not moving to the next customer. For the customer, it means the startup's skin is in the game.

Demo-driven development

McGrew describes demo-driven development, where every feature is tested for relevance to a real customer problem (for example, "How does this help the analyst stop a terrorist plot?"), and forces product thinking from the customer's perspective. Every capability the agent gains is validated against a real workflow problem a person inside the customer described. If an idea for a feature does not make sense in a demo with a real customer use case, it does not make it past the whiteboard. This is not theory-driven architecture; it is wedged tightly into what the customer needs to succeed.

Generalisation and product leverage

The hardest part of the playbook is knowing when and how to build something that scales beyond one customer. McGrew notes that the Palantir ontology illustrates a failure mode of FDE work: if each customer's solution is too specialised, the product becomes worthless for the next site. The goal is to increase contract value and valuable outcomes per customer while product features do more of the lifting. (An inference from his framing: every engagement has a tipping point where the FDE team should ask "Is this custom forever, or can we build a feature that generalises?" and make a deliberate choice, rather than drifting into permanent one-off work.)

McGrew captures the tension in a phrase: "The FDE model effectively is doing things that don't scale at scale" yet success means identifying the abstraction level that fits many customers. The move from Echo to Delta to generalisation is the playbook's crux.

The constraints

The FDE model is not a panacea, and the sources themselves supply honest limitations.

FDEs will be outnumbered by internal hires

Andrew Ng, co-founder of Coursera and founding lead of Google Brain, argues that AI Engineer roles will far outnumber FDE roles: most companies will hire more of their own staff than they will accept embedded vendor engineers. His reasoning is sound: vendor lock-in risk. When the best AI platform choice is uncertain (and it still is), tightly binding a firm's processes to one vendor's FDE and way of working reduces flexibility. Most organisations will instead hire or retrain their own people for what Ng calls the generalist AI Engineer—someone who combines LLM prompting, agentic frameworks, evals, and AI coding agents. The AI Engineer role will eventually fragment into specialisations—LLMOps, Evals, AI Data, Harness Engineering—similar to how Software Engineering split into frontend, backend, and mobile, but right now organisations are hiring generalists because the role itself is barely defined.

When to avoid the model

McGrew himself offers the sharpest counterweight. His core quote in sources is "If you can avoid it, do." The FDE model is expensive and demands a lot of the customer's attention. It makes sense when: (1) the problem is genuinely new and the market product is undefined; (2) the customer is large enough to justify the cost and complexity of an embedded team; (3) getting to working agent workflows fast matters more than building generic platforms. If the problem is well-defined, the customer is small, or the timeline is long, other models (pre-built tools, consulting, internal hire) may be better.

Building for learning and handover

One often-invisible part of good FDE engagement is how knowledge flows. Tobi Lütke, CEO of Shopify, describes a compelling model: public agents become learning engines as staff absorb patterns by watching others work, without formal training. Shopify runs River, its coding agent, in public Slack channels rather than private windows. The result: engineers watching other engineers use River adopt the same patterns the next day. River's merge rate climbed from 36% to 77% over two months without model retraining: teams noticed where it got stuck, fed back what it should have known, and the agent improved by absorbing each team's accumulated knowledge.

This has implications for how an FDE hands over. (An inference: keeping the work public and searchable—whether in Slack channels, documentation wikis, or recorded demos—means the practitioner does not carry all the knowledge away when the engagement ends. Future team members find the patterns the FDE and customer discovered together by searching old conversations, not by asking the FDE.) Private AI windows lock apprentices out; whoever is at the keyboard learns, everyone else is locked out of the model's improvement loop.

Practical toolkit for implementation

An FDE working on agent implementation needs more than playbook. The tokenizer source documents a specific tool-design pattern for embedding self-improvement loops into agent workflows.

CLIs enable agent self-improvement through logged execution: every run is recorded so the agent can inspect what it tried, what succeeded, what failed, and then strengthen its instructions. This is different from general coding: a CLI built for agent use returns structured, parseable output (JSON, tabular data) that the agent can inspect without visual pattern-matching. Agents move faster with CLIs than GUI-based tools because they parse structured output directly, saving tokens and reducing hallucination. The practical workflow is tight: an agent runs a task, logs the result, reviews its own logs to identify what broke, proposes a new instruction or tool, tests it, and improves. MCP servers are more complex than needed for local or internal automation; CLIs are simpler to build (a few lines with a framework like Click or Bun) and lower-friction for agents and humans alike.

One concrete example: 90 seconds, a video-creation platform, deployed background agents monitoring production logs via DataDog that autonomously diagnose and fix recurring issues; at one point an agent detected a shared email-provider reputation block and rotated credentials without human intervention. The agent logged what it tried, noticed a pattern across several failures, and proposed the fix. This kind of autonomous improvement is possible when the tooling is built for it.

Where the role is heading

Several sourced clues suggest where the FDE model is evolving.

First, it is moving from a specialty role owned by VC-backed vendors to a permanent internal hire. Levie's phrasing—the internal FDE as the highest-demand hire in tech—suggests that large organisations are now hiring or retraining people for this role, full-time and in-house. The boundary between "vendor FDE" and "internal AI lead" is blurring.

Second, it is fragmenting into vertical specialisations. Matt Slotnick, a venture capitalist and market analyst, notes movements by firms like Gainsight and Anthropic (via Fractional, its acquired FDE services firm) to embed AI-augmented services delivery teams inside customers, tailored to industry workflows. This suggests the generic FDE playbook is evolving into industry-specific versions—verticalisation that mirrors how consulting practice evolved.

Third, the role is becoming permanent. Levie notes that each model upgrade creates fresh work to capture gains or redeploy scaffolding, reframing engagement as ongoing partnership, not a discrete project with a defined end. An organisation that embeds an FDE now may keep that relationship as models advance, because each breakthrough forces rearchitecting.

Sources