Part -1 Why Does FDE Exist?

TL;DR

FDE is not unique because it promises customer proximity, iteration or outcome focus other delivery models already do that.

The more useful way to think about FDE is as a model for problems that require customer context, provider engineering capability and production learning to be continuously combined to turn technology into business value.

That distinction matters because FDE is an expensive model. If we define it too broadly, almost every complex technology problem starts to look like an FDE problem.

Agentic AI makes this question more relevant, not automatic. As more agency moves into systems at runtime, business context and engineering become more tightly interdependent.

So the real question is no longer “Why FDE?” but

“Does this problem require the kind of continuous context, engineering and production learning that makes FDE materially better than the alternatives?”

Following the rabbit hole

When I started this deep dive, I thought I had a reasonably good answer to the question.

FDE exists to close the persistent gap between technological capability and realized business outcomes.

It sounded logical. It also aligned with much of the current discussion around Forward Deployed Engineering: get engineers closer to customers, shorten feedback loops, iterate quickly and focus on outcomes rather than simply delivering technology.

Then I started pulling on the thread, and the deeper I went, the less satisfactory that answer became.

The technology-to-outcome gap is not new. Neither are customer proximity, iteration or outcome orientation.

Agile has called for continuous delivery, responsiveness to change and close collaboration between business and engineering for more than two decades.

Professional Services brings technical expertise into customer environments. Customer Success extends attention beyond deployment toward adoption and value realization.

Modern product operating models go further still, bringing business, engineering and operations into persistent cross-functional teams with end-to-end ownership.

So if all of those ideas already existed, why did we need another model called FDE?

That question sent me down a much bigger rabbit hole than I expected, and that journey turned out to be the useful part.

Start with the problem, not FDE

Rather than beginning with what an FDE does, I went back to the underlying problem.

There is a persistent gap between what technology is capable of enabling and the business value organizations ultimately realize from it. A technology can work. It can be deployed successfully. People can even use it. And the expected business outcome can still fail to materialize.

Technology therefore creates potential value. That potential has to propagate through a wider system before it becomes realized business value.

As a working model, I think of that system as:

Technology capability - Solution fit - Workflow integration - Adoption and behavior - Operational impact - Business outcome - Sustained value

These are not rigid stages. Different technologies and use cases will move through them differently. But the underlying point is important: technology does not jump directly to business value.

A technically capable solution might address the wrong problem. A good solution may not fit the customer's real workflows, systems, data or controls. A deployed technology may not change how people work. A change in behavior may not improve operational performance. And an operational improvement may still fail to create the financial or strategic outcome that justified the investment.

So perhaps the problem was not simply technology delivery. Perhaps it was value propagation.

The next hypothesis: fragmentation

Looking across that value-realization chain revealed another pattern.

Different parts of it are usually owned by different functions. Business leaders define outcomes. Product teams build technology. Professional Services implements it. Operations owns the workflow. Change teams and Customer Success support adoption. Business leadership ultimately owns financial results.

The expertise exists, but it is distributed. That means value repeatedly has to cross organizational boundaries, and every transition creates the possibility of context loss, handoffs, delayed decisions, different incentives, fragmented accountability and weak feedback.

When Johnson & Johnson examined its own technology operating model, for example, it found more than six handoffs between a business colleague and the engineer responsible for the relevant technology. Those handoffs slowed delivery and caused important insights to be lost in translation.

That suggested another hypothesis:

Perhaps the technology-to-outcome gap persists because the value-realization system itself is fragmented.

That felt stronger, but it still did not fully explain FDE.

Because existing models already address fragmentation

This became the most important challenge to my thinking.

A mature product operating model is specifically designed to reduce those boundaries. It integrates business and engineering, creates persistent cross-functional teams, reduces handoffs and organizes around outcomes rather than projects.

Agile deliberately tightens the relationship between business and engineering. Professional Services can embed deeply into customer environments. Customer Success can maintain continuity around adoption and value realization.

So it would be too easy and inaccurate to say:

Traditional models are fragmented. FDE fixes fragmentation.

Strong implementations of existing models already solve a lot of that. That forced the question one level deeper:

What remains structurally difficult even when those models are working well?

The provider–customer boundary

This is where the analysis became more interesting.

A technology provider and its customer naturally possess different parts of what is required to create value.

The provider understands what the technology can actually do, how the product is architected, where its limitations are, how it can be configured or extended and what capabilities are emerging.

The customer understands how the business actually operates, where value is created or lost, its workflows and exceptions, its data and systems, its policies and risk tolerance, and its organizational constraints and priorities.

Neither side naturally possesses the complete picture.

Authority is distributed too. The provider controls parts of the technology. The customer controls its business processes, priorities, data, governance, people and many of the decisions needed for value to materialize.

So even with highly capable teams on both sides:

The knowledge required to determine the right intervention and the authority required to execute it remain distributed across organizational boundaries.

Existing delivery models can coordinate across that boundary, but they cannot make the boundary disappear.

The problem is not the boundary. It is crossing it repeatedly.

Distributed knowledge and authority are not necessarily failures. They are often unavoidable.

The problem appears when the two sides have to continuously combine them.

A real deployment rarely follows a clean sequence from requirements to implementation. The customer learns something new. Engineering discovers a constraint. A workflow behaves differently in production. A technical possibility changes how the business thinks about the problem. Production exposes an exception. A missing product capability has to be escalated back into engineering.

Each cycle can create another chain:

[discover] - [explain] - [translate] - [escalate] - [approve] - [engineer ] - [deploy] - [observe] - [learn] - [repeat}

That is where coordination cost accumulates.

And this led me to a much narrower hypothesis for FDE.

So why does FDE exist?

Palantir's description of Forward Deployed Engineering is revealing. The model puts engineers close to real operational problems while keeping them connected to core engineering, so that field learning can influence both the immediate solution and the broader product.

Contemporary FDE models show the same pattern. OpenAI, for example, positions FDE at the intersection of customer delivery and core platform development, with responsibilities spanning discovery, technical scoping, system design, build and production rollout and with field learning feeding back into product and model development.

Seen through the earlier analysis, the important idea is not simply to put engineers near customers.

It is to create a tighter loop:

The provider customer boundary remains. Knowledge and authority remain distributed. But fewer layers are required to continuously bring them together.

That leads to the current working hypothesis:

FDE exists to reduce the repeated coordination required to translate provider technological capability into customer business value by bringing customer context, engineering authority and production learning into one continuous loop.

That is deliberately narrower than saying FDE delivers business outcomes.

It does not.

Leadership, process redesign, incentives, adoption, policy, organizational change and cross-functional execution remain critical customer-side dependencies.

FDE instead addresses a particular part of the value-realization problem: the repeated coordination required where provider capability meets customer-specific operational reality.

So why is FDE gaining so much attention now?

If the underlying problem is not new, this becomes the obvious next question.

Why is a model pioneered years ago becoming increasingly prominent again?

Part of the answer may lie in the way enterprise AI is changing. AI is moving beyond experimentation and isolated copilots toward systems that are expected to perform increasingly substantive parts of real business workflows.

And agentic AI changes the delivery problem in an important way.

Agency changes the system

Traditional software largely follows a path humans define in advance. A developer determines the logic:

If X happens, do Y.

Traditional AI changes how an answer is produced. A model may classify a transaction, predict an outcome or generate a response. But the broader workflow is still usually controlled by the surrounding application or a human.

Agentic AI changes that relationship.

Instead of specifying every step, we increasingly specify a goal: resolve this customer issue, investigate this security alert, reconcile these invoices, optimize our cloud spending.

The agent then determines parts of the path itself. It can plan which steps are required, determine what information it needs and retrieve it, select tools and take actions across systems, and observe what happened before retrying, changing approach or escalating.

The fundamental shift is therefore:

Traditional software largely executes a path determined at design time. Agentic AI moves part of determining that path into runtime.

Agency moves further into the system itself.

But what does “choosing the path” actually mean?

It means the system increasingly has to decide what information matters in a particular situation, which system it should query, which action it should take next, whether a case is normal or exceptional, whether it has enough evidence to proceed, whether it is authorized to perform an action, whether it should retry or change strategy, when it should involve a human and how it should determine whether the result is acceptable.

Those are not purely technical questions.

The answers depend heavily on the customer's business processes, policies, exceptions, permissions, risk appetite, decision rights, data and operating context.

So the delivery problem changes.

It is no longer only:

How do we integrate this technology into the customer's workflow?

It increasingly becomes:

How do we shape an adaptive system so that it chooses appropriate actions while operating inside this customer's business?

That requires much deeper interaction between business context and engineering.

Production becomes part of discovery

Not everything needed to answer those questions can be fully specified upfront.

Real situations expose things design workshops do not. An agent encounters an exception nobody documented. A technically reasonable decision conflicts with an unstated business norm. A permission boundary turns out to be too broad or too restrictive. The agent repeatedly requests information employees assumed was obvious. A workflow that looked sensible during design becomes inefficient when more decisions are delegated to the system. The agent technically completes the task but interprets the actual business objective incorrectly.

Production therefore becomes more than the place where the finished solution runs.

It becomes part of how the system itself is discovered and improved.

The loop increasingly looks like:

Business context - Agent behavior - Production action - Observation - Correction - Adaptation

And adaptation may require changing instructions, tools, available context, evaluations, permissions, approval thresholds, escalation rules, workflow design or even the underlying business policy.

The consequence of being wrong also changes

Agents are not limited to generating recommendations. They can act.

They may update records, communicate with customers, call APIs, execute transactions, trigger workflows or invoke other systems.

That means a misunderstanding does not necessarily end as a poor output. It can become a poor action. And because the agent may operate across multiple steps, one incorrect interpretation can influence the actions that follow.

Questions that once sat mainly around the technology therefore move closer to the center of engineering: what authority should the agent have, which tools should it access, which decisions require approval, where should autonomy stop, and what should happen when confidence is low?

Business policy, governance and technical behavior become more tightly coupled.

And this is the bridge back to FDE

This is where the connection becomes much stronger.

The customer holds much of the knowledge required to determine what good judgment looks like, which exceptions matter, what level of risk is acceptable, what the agent should be allowed to do and when a human must intervene.

The provider holds much of the knowledge required to determine what the technology can reliably do, how the agent should be architected, how tools should be orchestrated, how behavior should be evaluated, which technical safeguards are possible and how the underlying platform is evolving.

Those two bodies of knowledge cannot simply meet once during requirements gathering.

This is the important shift:

Agentic AI makes business context and engineering continuously interdependent.

And that places a premium on precisely the characteristics FDE brings together:

deep customer context + hands-on engineering authority + continuity into production + rapid learning + connection back to core product engineering

That does not mean every agentic AI program needs FDE. A strong internal product team, integrated Professional Services organization or sufficiently capable engineering team may create many of the same conditions.

But it does make FDE a particularly compelling delivery model for agentic AI transformation and helps explain why FDE is receiving renewed attention now.

Why getting the purpose right matters

This rabbit hole changed how I think about FDE.

I started by assuming I understood why the model existed. Each time the hypothesis became too broad, comparing it with existing models forced me to challenge and narrow it.

That matters for more than just academic pursuit.

FDE is an expensive model. It combines scarce engineering capability, deep customer engagement and persistent involvement in individual customer environments.

If we define FDE through generic characteristics such as customer proximity, iteration or outcome orientation, almost every complex technology problem can be made to look like an FDE problem.

And that is exactly how useful operating models become fashionable labels.

Understanding the purpose gives us a much better question.

Instead of asking:

Could we use FDE here?

we can ask:

Does this problem depend enough on continuously combining customer context, provider engineering capability and production learning that an FDE model would materially improve value realization?

Sometimes the answer may be yes.

Sometimes a mature product team, Professional Services engagement, Customer Success model or conventional engineering approach may be entirely sufficient.

Agentic AI makes that question more relevant. It does not answer it automatically.

And that is why understanding why FDE exists matters.

Because it gives us the basis for answering the next question:

When is FDE genuinely the right operating model and when is another model just as good, or better?

That is where I want to go next.