Forward-deployed engineering, explained
Understanding the Forward-Deployed Engineering Model
A field guide for business leaders who can describe the outcome but cannot get it built.
By Daniel Zivkovic, founder of Magma Inc.
Forward-deployed engineering is a delivery model, not a job title: a senior engineer works inside your business team rather than behind a ticket queue, taking intent that is not yet a specification and turning it into a system running in your own stack. The person doing it is called a forward-deployed engineer, and the name is newer than the job. This guide explains where the model came from, how it actually works, how it differs from the consultants and contractors you already know, the criticisms it deserves, and how to judge an engagement, whoever you end up hiring.
The short version. Most stalled AI initiatives do not stall for lack of technology, and not for lack of strategy either. They stall in the translation: the people who feel the problem cannot write the specification, and the people who could build the system never sit close enough to feel the problem. Forward-deployed engineering closes that gap by putting the engineer inside the business team, showing working software early, and letting your reactions to it define what gets built. And here is the part that surprises buyers most, from the practitioners themselves: on serious engagements, solving the technical problem is usually the short part. Most of the calendar goes to something else, which this guide covers under the trust budget.
The gap that eats your momentum
If you lead a strategy, marketing, research, or operations function, you have lived this cycle. You can see, concretely, what AI should be doing for your team: the report that takes three analysts a week, the leads nobody follows up, the sixty-page documents someone reads so a decision can be made. You write it up. It becomes a request. The request becomes a ticket. The ticket meets a backlog, and the backlog thinks in quarters.
None of this is anyone's fault. Your IT organization is carrying security, compliance, uptime, and a queue of commitments made before yours arrived. The backlog is not indifference; it is arithmetic. But the result is the same: the distance between what you can describe and what gets built is measured in quarters, and the opportunity you described does not wait.
The traditional fix is to write better requirements: a sharper brief, a fuller specification, another workshop. That fix has been failing for fifty years, and it fails for a reason worth naming plainly: the people closest to the problem are not specification writers, and no document survives contact with the first working version. You know what you want when you see it, and not before. That is not a flaw in you; it is how requirements actually behave.
What is a forward-deployed engineer?
The role inside the model: a senior engineer deployed forward, in the military sense of the word, out of the vendor's building and into yours, working beside the people who own the problem. Palantir, which created the role, describes it in terms most companies reserve for founders: "FDEs' responsibilities look similar to those of a startup CTO: you'll work in small teams and own end-to-end execution of high-stakes projects."
Titles come and go, and this one is having its moment; the venture firm a16z calls new job titles a way of "meme-ing into existence the change you want to see in the world," and offers a useful legitimacy test: does the title describe work that would have been unrecognizable five years ago? For forward-deployed engineering the honest answer is that the work is older than the hype, the label is younger than the work, and what matters to a buyer is neither: it is the mechanics of the model, which is why this guide is about the model.
Where the model comes from
The practice began in Palantir's intelligence work in the mid-2000s, with customers who could not state their requirements and often could not even share their data. The only thing that worked was sending engineers into the customer's building to sit beside the analysts, learn the real workflow, and build against it directly. The job title came later: "Forward-Deployed Engineer" was formalized at Palantir around 2011. Internally the company called them "Deltas," a nickname born from business-development teams named after NATO alphabet letters, with the Delta Force echo entirely deliberate.
One fact shows how central the model was: until about 2016, Palantir employed more forward-deployed engineers than conventional software engineers. This was not a support function bolted onto a product company; for a decade, it effectively was the company, and what those engineers learned in the field became the product (Foundry) that flipped the ratio.
For two decades the model stayed niche. Then AI happened to everyone at once, and in a single stretch of 2026 it became institutional: OpenAI launched a dedicated deployment company capitalized above $4 billion, formed with 19 investment firms, consultancies and system integrators led by TPG, and staffed on day one with roughly 150 experienced forward-deployed engineers through its acquisition of Tomoro. IBM Consulting launched "Forward Deployed Units" that May. ServiceNow and Accenture launched a joint forward-deployed engineering program the same month. Deloitte stood up a named Forward Deployed Engineering service line, and AWS published a forward-deployed engineering program for its partner network. Whatever else that wave proves, it settles one question: this is now a recognized way of delivering AI into enterprises, not one vendor's curiosity.
Why now? Because AI inverted the old bottleneck. Building software used to be slow and expensive, so writing careful specifications up front made economic sense. AI made building fast and cheap, which moved the bottleneck to the other end: knowing what to build. When a working prototype costs days instead of quarters, the scarce skill is no longer coding to a spec. It is sitting close enough to the business to discover the spec, and having the engineering depth to make the discovered thing real. That pairing is the model.
When the model applies, and when it does not
Kevin Bai, a forward-deployed engineer who has done the job at Palantir, Rippling, and Anthropic, gives the cleanest rule for when the model exists at all. Picture a two-by-two: how technical the thing being delivered is, against how technical the buyer is. A technical product sold to a technical buyer self-serves (developers do not need an embedded engineer to adopt a database). A simple product sold to a non-technical buyer is configurable software (nobody embeds an engineer to roll out a chat tool). The model lives in one cell only: something genuinely technical, bought by people who are experts in their own domain but not in software. His example: an oil-and-gas executive whose "pipelines are not data pipelines, it's more going to be fluorocarbons."
In 2026 that cell is crowded, because agentic AI is exactly that: a deeply technical capability being bought by marketing, operations, finance, and strategy leaders. As Bai puts it, nearly every platform is now agentic, and nearly every seller faces customers who cannot fully specify what they need. What used to be a Palantir oddity became a general condition, which is why the model went mainstream. The venture firm Flybridge adds the economic half of the test: the model creates value where complex problems meet high stakes and where what is learned in the field becomes a reusable asset, not a one-off. If your situation fails those tests, you do not need this model, and the end of this guide says so plainly.
What the work actually looks like
Sits with the work
Not a requirements workshop and not a stakeholder interview: time spent beside the people who do the job, watching the workflow as it truly runs. One practitioner's rule of thumb: schedule a one-hour meeting and somebody walks you through what they think the job is; be there for the full eight hours and you experience the job. The map that comes out of that sitting is the real requirements document, and nobody had to write it.
Shows, then asks
Instead of asking you to specify, a forward-deployed engineer builds a working version early and puts it in front of you. This is the model's founding move: Palantir's early team famously demoed software built before they fully understood the customer, heard "this is terrible, this isn't related to what we do at all," answered "how would you like it to be different?", and wrote down every correction. Your reactions do the specifying, because "show me what you have and I'll tell you what I want" is how real requirements surface.
Ships inside your stack
The system lands in the tools and infrastructure you already run, with your IT organization's governance, security review, and sign-off designed in from the start. Practitioners are blunt about why: an agent is only worth what it can reach, so you build into the Excel your finance team lives in and onto the systems they will never leave, rather than asking anyone to migrate.
Keeps the steps visible
A counterintuitive field lesson: do not collapse a process people already know. Hand an eleven-step workflow back as one magic step and people stop using it, because the checking they trusted has disappeared. Good forward-deployed work keeps the steps visible and puts the AI to work inside each one, so the people who own the process can still see it working.
The trust budget
Here is the number that should reset your expectations, from Colin Jarvis, who leads forward-deployed engineering at OpenAI. On one of his flagship enterprise engagements, the technical problem was solved in six to eight weeks. It then took four more months of pilots, evaluations, and iteration before the people whose work it touched actually trusted it. His generalization: most of a forward-deployed engagement, seventy-five percent or more by his estimate, is spent closing the trust and validation gap, not the code gap.
That time is not waste; it is the work. It is spent running the system in shadow mode alongside the humans before it is allowed to act alone. It is spent ramping autonomy in stages, advancing only when the system stops producing surprises. It is spent putting deterministic checks on anything that must be right every time, because as Jarvis puts it, you do not want to trust a language model to enforce rules that cannot tolerate error. And it is spent maintaining an audit trail of every action the system takes, because in another practitioner's words, if you cannot show the client what the agent is doing, they will never trust you. When you evaluate a vendor, budget for this. An engagement plan that is all build and no trust-earning is a plan for a demo, not a deployment. And one honest boundary belongs in every plan: in a large or regulated organization, the last mile from a working system to production runs through your own gates (security review, compliance, change management, release calendars), and that clock belongs to your organization, not to the vendor. A vendor who promises a production date through gates they do not control is overpromising; a real plan names the dependency and walks the path with your IT.
What it is not
The model is easiest to understand by contrast with the four things it gets mistaken for:
Not a strategy consultancy
Strategy firms are built for deciding what to do, and the good ones are worth it. But their deliverable is a recommendation, and a recommendation still has to survive the build. Forward-deployed engineering starts where the deck ends: making the chosen thing run. The two pair well, and in 2026 the large consultancies started building forward-deployed benches for exactly this reason.
Not staff augmentation
A staffing contractor executes the specifications you hand them, inside the queue you already have. That is the opposite of this model: a forward-deployed engineer exists because the specification does not exist yet, and owns the outcome rather than the ticket. One practitioner's one-question detector, from Pauline Brunet, who ran the function at Cursor: ask "who will be the working team?" If the honest answer is "we're understaffed, you do it," what is being bought is staff augmentation wearing a new name.
Not a permanent hire
The profile is rare: senior engineering depth plus the ear and patience for business context, in one person. Hiring it full-time is slow, expensive, and often unnecessary: the intense season is the discovery and the build, after which the system runs and your own team, leveled up along the way, carries it.
Not a product vendor's implementation team
Vendor implementation engineers are excellent at deploying their product, and the canonical forward-deployed engineer works for a product company, feeding field lessons back into its roadmap. But 2026 also produced a second kind: services-delivered forward-deployed engineering with no product attached, which is what the consultancies now sell and what independents practice. The distinction matters to you because the incentives differ: a product-attached engineer is ultimately deploying their platform, and since the platform only earns when it is used, their goal is production on their timeline. A services-delivered engineer is loyal to your problem and your stack: the deliverable is a working system, and production is reached through your own gates, walked together. Ask which kind you are buying.
The same contrast as a table
| Forward-deployed engineer | Solutions architect | Sales engineer | Management consultant | Staff augmentation | |
|---|---|---|---|---|---|
| Primary output | A working system in your stack | A design and recommendations | A won deal and a demo | A report and a roadmap | Completed tickets |
| Sits with | The people who do the work, for weeks | Architects and IT leadership | The buying committee | Executives and workshops | The existing dev team |
| Who writes the requirements | Nobody: a working prototype surfaces them | The client, refined by the architect | Largely predefined by the product | The consultant, from interviews | The client, fully |
| Ships working software | Yes, that is the job | Rarely | No | No | Yes, to spec |
| Success measure | The system running and used | The design approved | The contract signed | The recommendation accepted | Hours delivered |
The objections, taken seriously
A model this hyped earns its skeptics, and a guide that hides them is a sales page. Here are the four loudest criticisms, answered straight.
"It is a lock-in strategy." The sharpest public version says the forward-deployed engineer's real job is to lock the client into a walled garden. For product-attached forward-deployed engineering the criticism has teeth: the engineer is embedding their employer's platform, and the deeper it goes, the harder it is to leave. The structural answer is the two-kinds distinction above: services-delivered engagements that build on the stack you already own, hand over everything, and are designed to end have no garden to wall. The practical answer is to test for it: ask what happens at handover, who owns the artifacts, and what breaks if the vendor disappears.
"It is contractors with a new label." Sometimes it is, and the veterans say so themselves: one describes doing the work of four positions for modestly more pay, and a hiring wave always attracts rebranding. The defense is not the label; it is the tests this guide keeps handing you. Where does the engineer spend the first two weeks? Who will be the working team? Does a working prototype appear in weeks? Staff augmentation fails those tests immediately, whatever the job title says.
"It is a hype cycle, like prompt engineering." The title's arc invites the comparison, and by mid-2026 a visible grift layer had formed around it. Two things can be true at once: the title is having a moment, and the model predates the moment by two decades. When the term cools, the two-by-two condition that creates the work (technical capability, non-technical buyer) does not go anywhere. Buy the mechanics, not the label.
"It becomes a dependency." This one comes from inside the house. Practitioners describe customers becoming, in one investor conversation's words, addicted to their forward-deployed engineers, and Jarvis names the vendor-side temptation plainly: services revenue is like a drug. A well-run engagement is structured against this: fixed scopes, staged handover, your team enabled to carry the system, and an ending designed in from the start. An engagement designed to never end is a different product, and this guide's checklist asks about it directly.
Two limits, stated by the model's own architects, complete the honest picture. Bai's warning to vendors applies to buyers reading between the lines: without a platform of reusable assets underneath, a forward-deployed function is just a dev shop whose maintenance costs eat it alive, so ask your vendor what they reuse across engagements. And Bob McGrew, who co-created the model at Palantir, tells companies not to adopt it at all unless they have tried everything else first: "Don't do this at home... only if you really try hard not to do it and fail... then maybe actually it's a moat." A model whose inventor warns you off it is a model being described honestly.
The honest claim for this model is narrower than the hype around its name, and stronger for it: forward-deployed engineering is a working answer to the oldest failure in enterprise software, requirements written by people too far from the work. AI did not create that failure. It raised the price of it, by making everything downstream of a good decision fast and cheap. The model exists to get the decision right, close to the work, and then make it real.
How to judge one, whoever you hire
Whether you talk to us, a global consultancy, or an independent, the same eight questions separate the real thing from a rebranded body shop. Take this list into any vendor conversation:
1. Where do they spend the first two weeks?
The real thing sits with the people who do the work: one hour gets you what somebody thinks the job is; eight hours gets the job itself. If the discovery plan is a slide deck and three manager interviews, the translation gap stays open. And ask Brunet's question: who will be the working team?
2. How soon do you see working software?
Weeks, with your data, in your stack. The model's founding move is the early demo that gets corrected in the room. A long specification phase before anything runs is the old failure mode wearing the new name.
3. How does autonomy ramp?
AI systems should run in shadow mode first, then advance in stages, each stage earned when the system stops producing surprises. Anyone offering full autonomy on day one is selling you their risk.
4. What must be right every time, and how is that guaranteed?
The parts of a workflow that cannot tolerate error should be handled by deterministic checks, not model confidence; practitioners state this as a rule, not a preference. Ask where that line is drawn and how it is enforced.
5. Is there an audit trail?
Every agent action should be traceable. This is what turns your IT and compliance teams from blockers into allies: they get a governed system to review, not a shadow system to unwind. The field version: if you cannot show the client what the agent is doing, they will never trust you.
6. What do the reports count?
Practitioners across the field converge on the same three currencies: revenue up, cost down, risk contained. Reporting that counts model calls and story points instead is measuring the vendor's activity, not your outcome.
7. How does the engagement end?
Fixed scopes, fees that credit forward, your team enabled to carry the system, and everything you paid for left behind in your stack. The dependency trap is real and named by the practitioners themselves, so ask about the ending before you agree to the beginning.
8. Whose career is this engagement protecting?
Somebody inside your company is putting their name on this decision, and for them, even bringing in outside help carries personal risk. A vendor who has thought about that designs for it: visible milestones, evidence before autonomy, numbers the champion can defend upward. A vendor who has never considered the question is leaving your sponsor exposed.
How these engagements are usually structured
Across the real market, the same shape recurs so consistently it is worth teaching as a fact: a ladder of three broad phases. An entry diagnostic of one to three weeks, usually called a sprint or an assessment (sellers often split it in two, a short readiness check and then the full sprint, which makes a four-rung ladder); a core build measured in single-digit weeks that centers on a working prototype; then an embedded or retainer phase for hardening, autonomy ramp, and enablement. Even Palantir's own buyer-facing page sells a six-week entry engagement. Observed durations across practitioner accounts run from six weeks to a couple of years, with small senior teams: one engineer across several accounts at the boutique end, small pods on the larger programs.
Two market behaviors are worth knowing as a buyer. First, the entry rung was widely renamed: practitioners found that the word "audit" scared buyers (one called it "the medicine that neither one of us wants to take"), so the market says "sprint." Knowing the rename helps you see through the label to the substance, which is the same: a short, paid diagnostic that maps the workflow and prices the opportunity before anyone commits to a build. Second, fee structure signals intent: fixed fees with credits that roll forward into the next rung are the standard risk reversal among firms confident in their follow-through, and published pricing is largely a boutique behavior, with the big firms quoting only through sales conversations. Neither structure is right or wrong, but each tells you something about the seller.
When you do not need one
A guide that only ever concludes "you need this" is a sales page with footnotes, so here is the other half.
You do not need forward-deployed engineering for a pure infrastructure or platform project: that is classic IT delivery, and your IT organization is the right owner. You do not need it for tasks a well-chosen SaaS tool already covers; paying senior engineering rates to rebuild a commodity is vanity. You do not need it if your engineering team already sits with the business and prototypes early: you already have the model, whatever you call it. And per the two-by-two, you do not need it when what you are buying is not deeply technical, or when your buyers are engineers themselves.
One condition is on your side of the table: embedding fails without a business owner. If nobody on your team can spend real time with the engineer, reacting to prototypes and making calls, the translation gap stays open no matter who you hire. The model is a collaboration, not a delegation.
And a closing observation from the market itself: the label matters less than the mechanics. Across dozens of real vendor sites, "forward-deployed" turns out to be a careers-page word, not a homepage word, and Palantir, which invented the term, does not lead with it on its own buyer-facing services page. If a vendor's mechanics pass the eight questions above, it does not matter much what they call themselves. If the mechanics fail, the fashionable title should not save them.
Quick answers
What is a forward-deployed engineer?+
A senior engineer who works inside the customer's organization rather than behind a ticket queue, turning intent that is not yet a specification into systems running in the customer's own stack. The role was created and named at Palantir; the model it belongs to is two decades old and went mainstream with enterprise AI.
How is this different from a solutions architect or a sales engineer?+
A solutions architect designs and recommends; a sales engineer demonstrates and helps close; a forward-deployed engineer discovers the requirements by building, then ships and hardens the working system. The table above lays out the contrasts side by side.
How do I tell forward-deployed engineering from staff augmentation?+
Ask who will be the working team, where the engineer spends the first two weeks, and when you will see working software. Staff augmentation executes your specifications inside your queue; forward-deployed engineering exists because the specification does not exist yet.
How long does an engagement run?+
The market's recurring shape is a one-to-three-week paid diagnostic, a build phase of single-digit weeks centered on a working prototype, then an embedded phase for trust, autonomy ramp, and handover. Budget more calendar for trust than for code: practitioners report most of the time goes there.
When should we not use this model?+
Pure infrastructure projects, commodity needs a SaaS tool covers, teams whose engineers already embed with the business, and any situation where nobody on the business side can own the collaboration. It is also the wrong model when what you are buying is not deeply technical.
Where did the term come from?+
Palantir formalized the title around 2011 for engineers deployed into intelligence customers' buildings; internally they were nicknamed Deltas. In 2026, OpenAI, IBM, ServiceNow with Accenture, Deloitte, and AWS all stood up named forward-deployed programs, which moved the term from insider vocabulary to an enterprise category.
Does this only apply to buying from AI vendors?+
No. The condition that creates the model is a technical capability bought by domain experts who are not software people. That describes a marketing, operations, or finance team adopting agentic AI just as well as it describes an enterprise buying a data platform, which is why services firms and independents now practice the model without a product attached.
When you are ready to see it working
Magma runs forward-deployed engagements for strategy, marketing, and research teams. It starts with a free scoping call, then climbs a four-rung ladder: a readiness check, a fixed-fee discovery sprint that maps the workflow and prices the opportunity, a working prototype that settles scope by reaction, and a senior engineer embedded until the system is working in your own stack, with your team enabled to carry it. Fees credit forward; the offer page has the numbers.
See how Magma runs itA field guide, not a sales page.
Sources and lineage
This guide is grounded in the public record of the model and in named practitioner accounts of how the work is actually sold and delivered.
Palantir Technologies, "Dev versus Delta: Demystifying engineering roles at Palantir" (Palantir engineering blog): the Deltas nickname, its NATO-alphabet and Delta Force origins, and the company's own description of the role.
Gergely Orosz, The Pragmatic Engineer (2025-08-12): the role's creation at Palantir in the early 2010s, the pre-2016 period when FDEs outnumbered conventional software engineers, and the Foundry inflection.
Tom Hollands, Andreessen Horowitz, "Forward-Deployed Job Titles" (2026-01-27): the 2011 dating of the title, the title-arbitrage argument, and the legitimacy test quoted above.
The 2026 institutional wave, from the primary announcements: OpenAI, "OpenAI launches the Deployment Company" (May 2026: over $4 billion, 19 partner firms led by TPG, roughly 150 forward-deployed engineers via the Tomoro acquisition); IBM newsroom on Forward Deployed Units (2026-05-14); the joint ServiceNow and Accenture forward-deployed engineering program (2026-05-06, both newsrooms); Deloitte's Forward Deployed Engineering service line; AWS APN Partner Blog, "Introducing Forward Deployed Engineering for Partners."
Practitioner accounts, by speaker and venue: Bob McGrew (co-creator of the model at Palantir, later OpenAI) via Y Combinator, on the demo-first origin and the "don't do this at home" warning; Kevin Bai (Palantir, Rippling, Anthropic), "Forward Deployed Engineering 101" at the AI Engineer conference, on the two-by-two existence condition and the platform gate; Colin Jarvis (Head of Forward-Deployed Engineering, OpenAI) via Altimeter, on the trust budget and deterministic checks; Nabeel Qureshi (ex-Palantir) on Lenny's Podcast, on engagement structure and the second, translation-focused FDE profile; Pauline Brunet (Cursor), on the staff-augmentation detector and industry-vocabulary credibility; Vasuman Moza (CEO, Varick Agents), on the observation rule, the operating map, and the audit trail.
Flybridge Capital, "Why 95% of Startups Get the Forward Deployed Engineer Role Completely Wrong": the conditions under which the model creates value, used here as the buyer-side applicability test.
Frederick P. Brooks, "No Silver Bullet" (1986): the argument that the hardest part of building software is deciding what to build, which is the fifty-year-old root of the requirements problem this model addresses.
By Daniel Zivkovic, founder of Magma Inc.