Usual caveat: These are strictly my personal opinions and have nothing to do with my past or present employers.
Almost every discussion about the slow adoption of enterprise GenAI eventually becomes a discussion about deployment. The narrative is familiar: today’s models are remarkably capable, but they start struggling when they collide with fragmented enterprise data, decades-old ERP systems, and the way large organizations actually operate.
The industry’s response has become equally familiar. Build larger customer-facing engineering organizations, embed technical talent inside customer environments, and call them Forward Deployed Engineers (FDEs).
It’s an appealing story.I also think it’s missing the bigger lesson.
Part of the reason this conversation is happening now is that enterprise AI has changed the nature of implementation. Moving workloads to the cloud was largely an infrastructure challenge. Deploying AI agents is increasingly a workflow challenge. The models aren’t failing because they can’t generate text or write code. They struggle because they have to operate inside decades of accumulated enterprise complexity.
That’s a very different problem.
The tech industry is discovering that the era of “touchless” enterprise SaaS—the plug-and-play playbook that defined the last decade—is hitting a structural wall. Deep data heterogeneity means AI cannot be delivered via a standard browser login alone. It requires a return to high-touch, localized execution.
If you’ve spent time building enterprise software or running a professional services P&L, you learn pretty quickly that changing a job title rarely changes the underlying unit economics of the business. The success of the FDE model has less to do with the brilliance of the engineer on-site than what happens to the code after they leave.
That’s the distinction I think much of the industry is missing.
What Palantir Actually Built
Most conversations about FDEs focus on the engineers themselves. I think the more interesting question is why the overall system works.
What Palantir built wasn’t really an implementation organization. It was a product organization that happens to deploy engineers into customer environments.
The company appears to have recognized early that mission-critical enterprise data is messy, political, and full of unwritten business rules. No software platform can anticipate every edge case before it is deployed in the real world.
Its answer was to pair two complementary roles that function less like standard consultants and more like a tightly coupled product-and-implementation team embedded inside the client environment.
Forward Deployed Engineers, internally known as Deltas, solve the immediate technical problems. They write production code, connect fragmented systems, and build what has been described as the initial “gravel road.”
Deployment Strategists, internally known as Echos, operate as domain heretics. Rather than acting as passive change-management advisors, they challenge the client’s existing assumptions, surface institutional constraints, and identify the real operational metrics that justify the deployment in the first place.
But the vital product mechanics happen back at headquarters.
If an FDE team simply copied every customer workflow into the core platform, the software would quickly degrade into an unmaintainable system. To be clear, some enterprise environments are so shaped by legacy decisions that clean abstraction is impossible anyway.
Instead, the central engineering team acts as a ruthless generalization engine. They don’t look to copy bespoke logic; they look across dozens of deployments to isolate the underlying structural friction and abstract those patterns into reusable primitives. What started as a customer-specific gravel road becomes a foundational data abstraction—a paved highway that future customers can use without repeating the same work.
That changes the economics entirely, though it is a long, margin-heavy R&D phase that requires years of organizational patience to bear fruit.
The deployment team isn’t just implementing software.It is teaching the product how to improve itself.
If a customer deployment uncovers a reusable primitive, the next implementation should require fewer integrations, fewer workarounds, and fewer engineering hours. Over time, the platform becomes more capable precisely because it has been exposed to real-world complexity the core team could never fully anticipate in advance.
The engineers are not the moat. The learning loop is.
Why This Is Hard for the Hyperscalers
It’s easy to understand why Microsoft, AWS, and Google are expanding customer-facing engineering as enterprise AI deployments become more complicated.
The question isn’t whether those engineers create value.They almost certainly do.
But hyperscalers are structurally and financially optimized for a very different economic engine. Public markets value them on predictable, high-margin infrastructure consumption. The true FDE model requires a deliberate financial trade-off: accepting heavy human operational costs in exchange for long-term operational dependency. This is fundamentally different from adding raw cloud infrastructure.
Furthermore, their feedback loop is designed to look for different things. When a hyperscaler’s customer engineering unit or partner motion uncovers an integration pattern, the goal isn’t to build a unified operating system; it is to harden infrastructure and developer tooling primitives (like security layers, data pipelines, or vector databases) so *any* developer can build faster.
Even so, the organizational coordination loop remains the hardest part.
Palantir operates around a relatively unified software platform. When deployment teams discover something new, there is a direct path for that insight to become part of the platform.
Hyperscalers operate across sprawling portfolios that include infrastructure, developer platforms, security, databases, AI models, analytics, and enterprise applications. A field engineering team may discover an important pattern around enterprise data orchestration, but where does that insight belong? Which separate product team owns it? Which distinct roadmap gets changed?
That is not primarily a technical problem.It is an organizational coordination problem.
None of this means the model cannot work for them. It simply means the value created by these engineers may end up strengthening localized customer relationships and developer tools more than systematically evolving a unified enterprise platform. Those are two very different feedback loops.
The System Integrator Problem
The challenge for traditional system integrators is different.
It is mostly about incentives.
The economic engine of a traditional consulting business rewards utilization. Success is measured by keeping talented people billable for as long as possible.
A successful FDE model tries to do almost the opposite.
Imagine an engineer builds an abstraction that reduces future data-mapping work by 80%.That is a strong product outcome because every future deployment becomes faster, cheaper, and more repeatable.
It is a much more complicated outcome for a services business whose revenue depends on billable implementation effort.
This is not primarily a technology problem. It is an incentive problem.
Many Global System Integrators (GSIs) will argue they are already navigating this by investing into “asset-based consulting” and proprietary accelerators. But there is a difference between using reusable artifacts to speed up delivery and building a system that continuously abstracts deployment work into a shared product core. If the firm’s P&L is still fundamentally driven by headcount, the incentive to expand labor almost always wins.
If system integrators genuinely want to build an FDE model, they need to change two things.
First, shift revenue toward outcomes rather than hours. The firm must benefit when automation and productization reduce implementation effort instead of losing revenue because fewer consultants are required.
Second, enforce real product discipline. Deployments need to strengthen a shared software platform. If every engagement produces another collection of client-specific, bespoke integrations, the organization gets better at delivering isolated projects but not better at building a scaling product.
Those are two very different businesses.
The Hardest Part May Be the People
There is another constraint that does not get discussed enough. True FDEs are unusually difficult to hire.
You need engineers who can write production systems under pressure while also earning the trust of executives, operations teams, and domain experts.
That is a rare combination.
More importantly, many of these people want to build products, not just complete projects. They want the solution they built for one customer to become part of something used by thousands of customers.
The operating model matters because the best engineers usually care about the structural trajectory of what they are building, not just the immediate engagement.
The Takeaway
Enterprise AI absolutely has a deployment problem. The models are advancing faster than most enterprises can absorb them, and embedding technical talent inside customer environments will often be necessary.
But I do not think the lesson is simply to hire more Forward Deployed Engineers.
The lesson is to build organizations that learn from every deployment.That is what made the model powerful in the first place.
If your deployment teams are helping the platform become smarter with every customer, you are building a compounding moat. If they are primarily helping close deals, retain customers, or deliver custom implementations, they may still create enormous value. But you are running a fundamentally different operating model.
That is why I think the conversation around FDEs is slightly misplaced.Everyone is debating how many engineers to hire.The harder question is whether the organization is designed to learn from those engineers.
Without that feedback loop, an FDE is just another implementation consultant with a more modern title.
Many companies are copying the surface mechanics of the FDE model.
I am not convinced they are copying the system that makes it compounding.
And Vijay Says... 