If you only have a minute, here is what you need to know.
- The market has quietly defined a Forward Deployed Engineer as "an engineer who is good at agentic AI." That is a skill, not a role, and it is why the title now means almost nothing.
- The tempting fix, "a consultant advises, an FDE builds," is wrong. Consultants build. Your firm builds. The difference was never the person.
- "Forward deployed" gets read as a location, the engineer sent out to the client. Read that way, any engineer on a client site qualifies. Read it instead as a direction of value.
- The real definition: an FDE is an engineer whose work compounds in two directions. Backward into the firm as reusable capability, and forward into the client as capability they own and can run without you. The engineer is the conduit. The compounding is the point.
- Consulting's own economics fight both directions. Utilization punishes the unbillable time that builds reusable assets. The annuity instinct prefers a dependent client to a capable one. A real FDE practice beats both. Most of the ones being announced right now beat neither.
- If you are the client, you are not funding their R&D. A firm that compounds shows up with assets earlier clients already paid for, so you get a cheaper, more proven result. What compounds is craft, not your data or your edge.
The definition everyone is using, and why it is empty
Ask five firms what a Forward Deployed Engineer is and you will hear a version of the same thing: a strong engineer, embedded with the client, who is fluent in building with AI agents.
That sounds like a role. It is a skill. "Good at agentic" describes a capability your best people can learn, the same way they once learned cloud, or mobile, or the web. Naming a job after a skill is how you get a title that means nothing, which is exactly where "FDE" has landed. It now stretches to cover almost anyone technical who shows up at a client with AI in the conversation.
So let me try to give the term back some meaning, because underneath the hype there is something real, and it matters most to the people who buy and sell consulting.
The easy answer is wrong
The tempting way to make the role sound distinct is to say a consultant advises and an FDE builds. Tidy, and false.
Consultants build. Your firm builds. Delivery teams write production code, integrate systems, and ship working software every day, and they have for years. If "builds things at a client" were the bar, every delivery engineer in the industry has been an FDE the whole time. The difference was never advice versus building, and any definition that leans on it insults the people doing the work.
So if the person is not the difference, what is?
"Forward deployed" is not a location
Here is the move that unlocks it. Everyone reads "forward deployed" as a place: the engineer sent forward, out of the office and into the client. Read that way the title is meaningless, because sitting at a client site is the most ordinary thing a consultant does.
Read it instead as a direction. Not where the engineer sits, but which way the value moves.
The definition that means something
A Forward Deployed Engineer is an engineer whose work compounds in two directions. Backward into the firm, as reusable capability. And forward into the client, as capability they own and can run without you.
The engineer is the conduit. The compounding is the point.
Backward means the system they build for one client makes the firm's next build faster and cheaper, because the hard-won pattern becomes a reusable asset instead of evaporating when the engagement ends. Forward means the client is left genuinely more capable, holding a working system their own people understand, not a black box only the firm can touch.
If value only flows one way, out of the client and onto an invoice, you do not have a Forward Deployed Engineer. You have staff augmentation with better tooling.
The two-way test
This gives you something you can actually check, whether you are buying the work or selling it.
Backward: does it make the firm's next build better? After the engagement, is there a reusable asset, a pattern, an accelerator, a harness, that the next client benefits from? Or was it a bespoke one-off that taught the firm nothing?
Forward: can the client run it without you? When the team leaves, does the client own a system their people understand and can change? Or is every future tweak another invoice?
Fail either direction and the title is a relabel. Pass both and you have the real thing, and it is genuinely worth paying for.
If you're the client, the fair objection
There is a reasonable worry buried in all of this. If your engagement makes the firm better at its next one, are you just funding their R&D? Paying premium rates to build assets they will resell to the company down the street?
Fair question, and the answer is that the flywheel runs in your favor, not against it.
You are not the first client. You are downstream of every one before you. A firm that compounds shows up with accelerators, patterns, and harnesses that earlier engagements already paid to develop, so you get a faster, cheaper, more proven result than the first client ever did. You are not funding the R&D. You are renting an R&D budget a hundred clients already paid for, and adding one brick the next hundred will rent from you. The firm that compounds is the cheaper option. The expensive one is the firm that bills you, at premium rates, to reinvent what it has already built ten times.
Be clear about what actually compounds, too. It is craft, not your secrets. The firm gets better at the generic, unglamorous work: deploying an agent against a twenty-year-old database, passing a security review, wiring into legacy systems. Your data, your business logic, your competitive edge, those never leave, and they are not what makes an asset reusable. If a firm is compounding your proprietary advantage into a product for your competitors, that is not an FDE practice, it is a breach, and your contract should treat it as one.
The forward direction is your guarantee the whole thing stays honest. You end up owning a working system your people can run. The firm ends up better at its craft. Both sides come out ahead, which is the entire difference between a partner and a vendor. If only the backward half happened, you would be right to walk. The forward half is what makes the backward half fair.
Why consulting's version is different on purpose
This part matters, because the firms copying the model are copying the wrong template.
At a product company like Palantir or OpenAI, the loop runs backward only. The field work feeds the product, and the client getting locked in is the goal. Lock-in is the moat. That is a perfectly good strategy when you sell a product.
Consulting is not that. When a consulting client gets locked in, the client got a bad deal, and eventually they figure it out. So a consulting FDE has to compound in both directions, and the forward one, leaving the client capable, is the half that separates a partner from a vendor. Copy the product-company version into a services firm and you have just built a more sophisticated way to create dependency.
What gets in the way
The reason most "FDE practices" being announced this year will not produce real ones is that consulting's own economics fight both directions.
The backward direction is killed by utilization. Turning this engagement's learning into a reusable asset is unbillable time that helps the next project, not this one's margin, so it never gets done. The forward direction is killed by the annuity instinct, because a client who can run it themselves is worth less next quarter than one who cannot. Both incentives are quiet, both are rational, and both point the wrong way.
A real Forward Deployed Engineering practice is one that has decided to beat both. It funds the asset-building that utilization punishes, and it measures success by the client's capability instead of their dependence. That is a leadership choice, not a hiring one. It has almost nothing to do with how good your engineers are at agentic anything.
The bottom line
Stop judging an FDE by the title, the tools, or the seat at the client. Judge it by which way the value moves. A real one leaves two things behind: a firm that is better at its next build, and a client who no longer needs them for this one. Everything else is an engineer who is good at agentic, billed at a premium.
If you are buying it, ask the two questions before you sign: what becomes reusable, and what can we run ourselves when you leave. If you are selling it, know that the title is the easy part. The compounding is the job.
Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss building a forward deployed practice that actually compounds.
References
- Bloomberry. "What I learned analyzing 1K forward deployed engineer jobs." November 2025. bloomberry.com
- First Round Review. "So You Want to Hire a Forward Deployed Engineer." review.firstround.com
- Andreessen Horowitz. "Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups." June 2025. a16z.com
- The Pragmatic Engineer. "Forward Deployed Engineers, and why they are so in demand." pragmaticengineer.com
