Flagship essay

Forward-Deployed Engineering Is New. The Work Underneath It Is Not.

August 8, 2026 · 19 min read · The frame: Start Here

The filling line chugged rhythmically as my colleagues and I walked out onto the manufacturing floor. I can still smell the isopropyl alcohol and the bleach we used to sanitize our boots.

In 2014, implementing a Laboratory Information Management System (LIMS) meant wiping my clipboard with isopropyl alcohol, gowning up in my blue bunny suit, and walking into ISO 8 and ISO 7 manufacturing areas.

The site made injectable IV bags across multiple lines: saline, Lactated Ringer’s, and other terminally sterilized products. I was helping implement some of the LIMS workflows for biological and chemistry quality on what was then Lonza’s MODA platform.

That meant locating the environmental monitoring points across the actual plant - from physical tank-sampling valves to viable and total-particulate monitoring locations - and determining how frequently each one needed to be sampled.

Each physical location had to map to the correct sample identity. The BQ and CQ teams needed to know what to collect, where, and when. Microbial alert and action levels had to become sampling plans, assignments, limits, exceptions, and inspectable records.

Those answers had to line up across the physical process, the SOP, and the LIMS configuration. If one was wrong, the software was wrong.

The implementation also had to survive pharmaceutical software validation and hold up during an FDA audit.

It taught me one of the most valuable lessons of my career:

None of that work started in code. It started with walking the floor.

Today, I would probably describe much of that as forward-deployed engineering. My badge actually said engineer. We just did not call the work FDE. We called it implementation.

I am not making the old-man-on-the-internet claim that we secretly invented FDE first. The title is useful, and the current tooling genuinely changes what one person can build. My point is that the discipline underneath it already had a name, a method, and consequences long before the current label arrived.

Andreessen Horowitz now calls the forward-deployed engineer “the hottest job in startups” (Schmidt, 2025). The Financial Times reported, using Indeed data, that monthly listings for the title rose more than 800% between January and September 2025 (PYMNTS, 2026). I could not reproduce the underlying series from published data, so I treat that as a strong signal that employers are reaching for the title, not a literal census of the underlying work. The job description, when you read one, goes something like this: embed with the customer, live inside the operation, wire the software into messy reality, and stay until it works.

There is a name for this work and it has been on invoices for thirty years: implementation consulting. I know the suitcase version of that life pretty literally. For a couple of years, I traveled more than forty weeks a year. At one point I was Diamond with Hilton and Platinum with Marriott at the same time… which sounds better until you think about how you earn both.

The ERP wave ran on that kind of work. SAP and Oracle shipped platforms; large implementation teams lived out of suitcases making those platforms true inside specific companies, one messy site at a time. The systems integrators built entire billion-dollar practices on the premise that software does not deploy itself into an operation - someone has to go to where the operation is. Pharma had its own regulated flavor of the same job, the one I did: implementation plus validation, software wired in and proven in, with an evidence trail an FDA inspector could walk.

So when the current wave tells me forward-deployed engineering was born at Palantir and came of age with LLMs, my reaction isn’t that the wave is wrong about the job mattering. It matters enormously; it always did.

My reaction is that the wave has no memory - and markets with no memory repeat things that are expensive to repeat.

The job-description test

Here’s the test I keep running. Take a 2026 FDE listing and strip the company names. Then put it next to what an ERP implementation consultant did in 1999, or what I did in a pharma plant in 2014:

The overlap isn’t superficial. It’s the implementation job. What changed between 1999 and 2014 was the industry vertical; what changed between 2014 and 2026 is the software layer being wired in - and the compensation. The role is old enough to rent a car. What’s new is the packaging around it.

The translation discipline

The title comparison is fun, but it is not why I care about the lineage.

The lineage matters because implementation is a discipline, and the current conversation keeps treating it like physical proximity plus the ability to code quickly. Embedding with a customer is useful. Shipping a prototype in a week is useful. Neither one tells you whether the person can translate an operating problem into a system that changes the operation.

The translation I mean has a direction:

Software is one stage in that chain. If you enter at the software stage, you are accepting every upstream assumption as settled: that the process should exist, that the handoff is necessary, that the user asking for a screen is the right user, that the exception is actually exceptional, that the metric attached to the project is connected to the P&L.

Often, one of those assumptions is the bug.

This is why the work has always required more than requirements gathering. You have to understand enough of the business to ask which economic lever is supposed to move. You have to walk the process closely enough to see what people actually do instead of what the procedure says they do. You have to identify who makes which judgment, what evidence they use, what happens when the happy path breaks, and what the downstream user needs to trust the result. Then you have to express that in a form an engineer can build and an operator can reject when it is wrong.

In 2017, we built client-facing functional specifications and technical specs that did exactly that translation. Before the FDE title, agents, or cheap code generation, companies still needed people who could turn business process and user behavior into rules, interfaces, exceptions, and acceptance criteria an engineer could implement. That translation decided whether the build meant anything once it reached the operation.

The feedback arrow at the end matters just as much as the P&L arrow at the beginning. A functional specification is not a ceremonial handoff. Once the system reaches the operation, you learn which exception was common, which rule was fictional, which field nobody could supply, and which technically correct output no operator would trust. The translator carries that evidence back into the next version. The job crosses the boundary in both directions.

Once you name the work as translation rather than proximity, Palantir’s contribution becomes easier to see: it moved the function inside the product company, packaged it as engineering, and changed which economics could sit around it.

What Palantir repackaged

The origin story the market tells is that Palantir created the forward-deployed engineer. As history of the title, that’s right: Palantir coined it in the early 2010s and called the people who held it “Deltas.” For a stretch of its life the company had more Deltas than it had conventional software engineers - the field outnumbered the factory until around 2016 (Orosz, 2025).

But look at what the Deltas were doing: living at customer sites, configuring a vendor platform against live operations, translating between the client’s reality and the product team. A large systems integrator would have recognized the staffing pattern immediately. The function was not the invention.

The public record supports a narrower claim than “implementation at software multiples.” Palantir’s 2025 filing says its contracts include hosted subscriptions, on-premises software with operations and maintenance, and professional services such as interface configuration, training, and ontology and data-modeling support. It also says software engineers working with existing customers often manage deployments and identify new uses. At the same time, the company explicitly describes a “product-based business model” and says its platforms are offered on a productized basis to reduce acquisition, maintenance, and deployment time (Palantir, 2026).

What the filing does not provide is an FDE-specific P&L. I cannot separate the margin on embedded implementation from the platform around it. What we can observe is the combined model: subscription software, operations and maintenance, deployment, and professional services inside a company that reported an 82% consolidated gross margin in 2025.

The filing shows what that packaging made possible: embedded implementation could live inside a scalable product company instead of appearing only as a consulting project.

I do not mean that cynically; the current wave says the economics out loud. The a16z essay that crowned the FDE the hottest job is explicitly an argument about margin - trade gross margin today for control of the deployment layer, because the companies that owned implementation (Salesforce, ServiceNow, Workday) started margin-ugly and ended up as systems of record (Schmidt, 2025). Owning the last mile may be worth paying for, but that is an investment thesis, not proof that every hour of forward-deployed work behaves like software revenue.

Why AI widened the last mile

AI made that packaging newly urgent because it widened the distance between a convincing demo and a dependable operation.

An ERP rollout was brutal, but it was brutal in a legible way. The software was deterministic. Configuration was the hard part; once configured and tested, the system did the same thing every day, and the remaining risk was organizational - process change, data migration, people.

An AI deployment inherits all of that and adds a layer ERP never had: the core component is probabilistic. It behaves differently on your documents than on the demo’s. Its failure modes are quiet. Its correctness is statistical, so “does it work” stops being a question you answer once and becomes a question you answer continuously. (That difference is genuinely new, and it gets its own essay later in this series - it’s the one thing this wave cannot copy from the last one.)

Put a component like that in front of an enterprise buyer and the distance between demo and deployed value becomes enormous - larger than the model vendors’ product teams can close from headquarters. So the market did what it did in the ERP era: it sent people. It also gave the job a name that software companies and investors read differently. Implementation consultant is associated with a services business. Forward-deployed engineer puts the same last-mile work inside the product-engineering story.

The reported listings spike tells me employers are reaching for the title. It cannot tell us that the underlying body of work grew 800%, because title adoption and demand can rise together. I believe the need is real; I also think the market has forgotten that implementation businesses have followed this playbook before.

The earlier implementation-market cycle

If implementation is once again the bottleneck, the old market is more than history. ERP gives us a useful comparison, even if AI changes the ending.

ERP implementation produced a recognizable playbook for how scarce delivery capability becomes legible and scalable. I am using that history as a conceptual model, not claiming the figure below is a measured industry margin curve:

The curve is mine. The pieces underneath it are not. SAP’s ASAP methodology codified implementation into repeatable phases, deliverables, templates, and quality gates. Research across 96 ERP projects documented the expectation that consultants transfer implementation knowledge so clients can maintain the system independently. Infosys’s 2003 filing described splitting work between client sites and offshore centers, training deployable staff, reusing knowledge, and executing components where they were most cost-effective. Accenture’s 2025 filing still describes standardized methods, global delivery, and cost advantages as the machinery behind price-competitive services.

That gives me receipts for method, knowledge transfer, talent scaling, and rate arbitrage. It does not give me the timing, slope, or inevitability of the curve.

The stages may not arrive neatly in order this time. We already have scarce practitioners, rapidly forming methods, agent factories, vendor-led delivery programs, partner networks, and early compression in the generic build layer at the same time. The market may mature from the middle out.

I think AI implementation is moving through a related curve, but not because every deployment will remain a bespoke snowflake. The build layer is already industrializing faster than ERP’s did. Salesforce Agentforce, Google’s Vertex AI Agent Builder, Microsoft Agent Factory, and ServiceNow AI Agent Studio all package some combination of building, testing, deploying, governing, and operating agents. The model providers are compressing the layer from below: OpenAI and Anthropic both ship agent SDKs. Process-intelligence products such as Skan are trying to turn observed work into agent procedures, controls, and deployed agents. Adjacent workflow-capture tools such as Scribe are mapping how work happens, surfacing waste, and pointing teams toward what to improve or automate. Those are examples, not a complete market map.

That makes the likely shape look less like permanently bespoke software and more like RPA circa 2017 blended with ERP. The factory at the center gets cheaper: prebuilt agents, low-code builders, managed runtimes, connectors, observability, evaluation, and governance become product features. Around it, companies still have to map the actual work, decide which exceptions and controls matter, connect the existing estate, validate the result, redesign roles, and operate it. Even if construction standardizes, each implementation still has to fit a local operation.

Microsoft’s Agent Factory is almost too perfect as a receipt: the same offering combines agent platforms, training, forward-deployed engineering support, and a partner marketplace. A vendor absorbing the tool layer does not necessarily eliminate the services market. It may create the conditions for one.

The implementation gap became part of the business model

The tooling market is betting that the factory gets cheaper. The frontier labs are placing a second bet: that the remaining implementation gap is large enough to justify institutions of its own. OpenAI’s Deployment Company embeds FDEs inside organizations to connect models to customer data, tools, controls, and core business processes. Ode with Anthropic is an enterprise AI services firm built from Anthropic engineers and the acquired Fractional AI team; its offer runs from roadmap through deployment rather than ending at model access.

DeployCo launched with more than $4 billion of initial investment. Ode was reported as a $1.5 billion company, although Ode and Anthropic’s official launch materials do not disclose that figure. The measures are not directly comparable or additive, but both are evidence that better models do not cross the implementation gap by themselves.

The last mile did not disappear. It became part of the business model.

For the frontier labs, implementation may make money in two places. There is the services revenue itself, and there is the customer adoption it can create for the model business upstream. Both OpenAI and Anthropic meter model usage by token. When a deployment arm moves a model from an experiment into a recurring core workflow, the project can create continuing inference consumption.

Or, less delicately: the implementation arm may earn revenue of its own. It may also be how the token business gets embedded.

Neither DeployCo nor Ode discloses enough unit economics to say how much value sits in each layer, or whether token pull-through is the primary motive. I am inferring that second incentive from the business model, not attributing it to a disclosed strategy. Treating the delivery institution only as a consulting-margin business still ignores the usage it may create for the model provider.

The dollar figures got my attention, but the organization design is the stronger receipt. Both companies are putting a dedicated deployment institution between frontier models and customer operations. The capital does not tell us whether either one will work. It tells us the last mile is important enough that they are building a business around it.

Here is what would prove me wrong: platforms commoditize the translation layer along with construction; operating context becomes portable without high-judgment implementation; domain depth stops commanding a premium; or providers absorb the whole lifecycle without creating another delivery ecosystem around it. All of those are plausible. AI’s probabilistic core also makes continuous evaluation and control more important than they were in deterministic ERP. I am using the last market for questions and base rates, not pretending it guarantees this one’s ending.

What remains scarce

If construction gets cheaper, the premium moves toward the parts that are harder to standardize. Three things can remain expensive for good reasons.

A named method. Not a branded slide deck - a way of working that reliably moves from economic objective through process, system, validation, adoption, and feedback. A buyer should be able to see how the team makes decisions, what artifacts survive the engagement, and where the method changes the result.

Domain and regulated depth. This earns its keep when someone knows which assumptions are dangerous, which evidence an operator or examiner will ask for, and which technically convenient shortcut creates a downstream control problem. You learn that depth slowly, usually by living through the consequences.

Capability transfer. A good implementation leaves the client able to operate, challenge, change, and eventually extend the system. Lock-in can look like a moat on a revenue slide; from inside the operation, it looks like asking permission every time your own process changes.

Why the talent pool changes

Over the next two years, I think many excellent new FDEs will come from business analysts, operators, domain practitioners, and automation engineers - not only from conventional software engineering.

AI is compressing the time required to turn a well-understood behavior into working software much faster than it is compressing the time required to understand the behavior.

You can teach a strong domain practitioner a new coding tool. You cannot compress twenty years of seeing how a plant, a P&L, a claims process, a quality system, or a finance operation really behaves into a prompt and call the transfer complete. The tools are explicit. Much of the judgment is path-dependent: exceptions seen, incentives misunderstood, controls failed, operators watched, and consequences lived through.

Automation engineers deserve an explicit place in that feeder pool. Many already know how to decompose a body of work, separate deterministic rules from exceptions, integrate across ugly system boundaries, and own what happens after an automation meets production. That does not automatically make someone ready to own a probabilistic system, but it is a much closer starting point than the current job titles imply.

None of this is permission to hand production architecture to anyone who can generate a demo. Security, reliability, data design, performance, deployment, and operability remain engineering disciplines. A business analyst still has to understand those constraints, just as an engineer still has to find the business decision the system should improve. Sitting at the customer site does not fill either gap.

The hiring inversion

The HR mistake would be to read this as “hire fewer engineers.” I mean something more specific: stop writing every FDE role as a conventional software-engineering requisition with customer proximity added, then treating operating and domain judgment as nice-to-have.

I would build the role around four observable competencies:

• operating and domain judgment
• process translation
• production engineering
• evaluation and control

The four competencies are not enough by themselves; I would also hire for how someone learns. The ERP version of this job could hire for a decade of depth in one relatively stable manufacturing or quality module. An AI FDE is working while model behavior, frameworks, provider features, and operating patterns change underneath them.

Can they pick up a new capability quickly, test it against the operation, discard it when the evidence changes, ask for help before confidence outruns understanding, and stay accountable while the playbook is incomplete? I want someone curious without chasing every new thing, and adaptable without hand-waving past what they do not know.

Candidates can start stronger on one side of the bridge. The staffing plan should name what they already bring, what they have to build, and who reviews the work until the gap closes.

The person I would look for is the analyst-builder: someone who can find the economic objective, map the work, make the decisions and exceptions explicit, use modern tools to build the smallest useful system, and know where deeper engineering judgment has to enter. The scarce skill moves up the chain. Less time translating a clear specification into syntax; more time making the specification true.

If I were building an FDE population, I would not start by asking who can produce code fastest. I would ask who can cross the translation chain without losing the operating intent, then build the missing technical or domain depth, review structure, and paved roads around them.

The team matters just as much as the individual. Searching for one mythical person with twenty years of domain experience, senior production-engineering depth, perfect customer instincts, and every current agent framework just recreates the same unicorn requisition under a newer title. Make the competency gaps explicit, pair people around them, and give the operation, the software, and the controls clear owners.

HR, engineering leadership, and the business have to design that system together. Changing the title on an old requisition will not do it.

Widen the pool. Keep the bar.

So I modeled what happens when a recruiting funnel stops treating software engineering as the only valid source pool. Public labor data can size adjacent occupations, while the conversion assumptions make the unknowns explicit.

The default numbers are deliberately illustrative. Move the assumptions and the answer moves with them: who is reachable, what each lane already knows, how many people can be trained, who passes the same rubric afterward, and who can be placed inside the planning horizon. Today it is a staffing hypothesis; measured inputs could turn it into an operating instrument.

The public labor data provides scale for adjacent occupations. Readiness, interest, availability, and overlap among those populations remain unknown.

The hiring and buying test

So here is the test I would use for a person or a firm selling forward-deployed capability.

Give them one body of work and ask them to walk the whole chain:

• Which P&L lever or operating outcome are we trying to move?
• Which parts of the current process should disappear before anything is automated?
• Who are the actual users, and which decisions do they make?
• Which rules are stable, which boundaries can be learned, and which paths genuinely require runtime judgment?
• What exceptions carry the real risk?
• What would prove the software works in the operation, not merely in the demo?
• What will the client be able to operate and change without the embedded team?

Listen for where the answer starts. If it starts with the model, the framework, or how fast the team can code, you are still upstream of the important work. If it starts with the business outcome but never reaches architecture, validation, or production ownership, you have strategy without delivery. If it reaches production but leaves no capability behind, you bought an expensive dependency.

The best answer crosses every layer and knows where its own competence stops.

The people worth hiring

That is the job I recognize from 2014. The tools are better and the title is much cooler, but the test is still whether you can understand an operation deeply enough to build something it can trust - and leave the people running it able to own what comes next.

I’ve watched this movie from the inside twice, once with a validation binder and once with a migration cutover plan. The third screening has better effects. I would still rather not watch us relearn all of the expensive parts.

-T