Why AI Companies Need Forward Deployed Engineering
Palantir pioneered it. OpenAI formalized it in early 2025 with a dedicated team. Anthropic is building one now. A growing number of AI-native companies have converged on a delivery model that looks nothing like traditional software distribution.
Forward Deployed Engineering — embedding product-caliber engineers directly inside enterprise environments — has become the default engagement model for AI companies working with large customers. The question worth examining is why.
How technology reaches enterprises
Technology typically reaches enterprises through three types of organizations, each optimized for a different combination of depth and delivery.
Product companies build a focused solution and distribute it at scale. The customer configures, the vendor supports, and the product solves the problem largely as delivered. Microsoft 365, Salesforce, ServiceNow — distribution relies on sales, channel partners, and implementation guides, not dedicated solution engineering on site.
Services companies supply engineering talent to work on the customer’s problems. The engagement is staffing-oriented — revenue is driven primarily by billable headcount, and the business optimizes for the volume and size of placements. Billable utilization rate — the percentage of available staff actually billing — is the key efficiency lever. Delivery quality depends on the individuals assigned.
Product consultancies operate as technology partners for their clients. They bring product engineering capability and deep business delivery expertise to build solutions — often on their own acceleration platforms — at a level of craft and reliability associated with commercial software. They may tie compensation to business outcomes delivered, not just resources placed. And because they are vendor-agnostic, they represent the client’s interest in evaluating technology choices — enterprises turn to these partners not just for execution but for strategic technology guidance.
Forward Deployed Engineering has been the default mode of engagement for mature and successful product consultancies. What is new is that AI product companies are now adopting it, and services companies face a structural challenge getting there.
When traditional distribution works — and when it breaks
The product model works when the product solves a well-defined problem whose variance across enterprises is small enough that configuration bridges the gap. A CRM, an HRIS, a project management tool — these share enough structure across enterprises that a single product can serve many. The distance between what the product does and what each enterprise needs is manageable without dedicated solution engineering.
AI products sit at a fundamentally different point on the abstraction spectrum. A large language model or an AI platform is a base technology — a cognitive, generative capability that does not map to any enterprise workflow out of the box. The distance between what an AI model can do and what an enterprise needs it to do is structural, not configurational. Closing it requires building a solution — often a novel application — that maps the technology to the business’s actual problems, data, workflows, and constraints.
This is why traditional distribution fails for AI. And it is why the question of who builds that bridge, and with what capabilities, matters so much.
The triad: what closing the gap requires
Delivering durable enterprise value from AI requires three capabilities operating simultaneously.
Foundational understanding of the technology. Not just API usage, but how models behave in production — where they hallucinate, what evaluation frameworks reveal about reliability, how to design systems that compensate for non-determinism. Without this, teams build on assumptions that collapse under production workloads.
Enterprise business analysis and delivery. The ability to analyze a business problem, map technology to it, and navigate the full reality of enterprise environments — stakeholder dynamics, security, compliance, existing systems, and change management. Good enterprise decision-makers evaluate partners through layered trust: hedging across relationships, requiring pilots that prove business value, then gradually increasing commitment as risk decreases. Understanding and working within this process is what separates a successful engagement from a technically sound pitch that goes nowhere.
Product engineering depth. The difference between a prototype and a production system. Building solutions with the design, reliability, and user experience that enterprises expect from commercial software. Knowing a technology is not the same as building products with it. Product management, UX design, iterative delivery, and market-informed architecture form their own discipline — one that determines whether a solution achieves adoption or sits unused despite being technically functional. With AI, this discipline extends further: product decisions now include how non-determinism shapes the solution design, when fine-tuning is warranted, and how the system’s behavior will evolve with use.
These three are distinct. Most organizations focus on and are strong in two. The third is understood but not prioritized — and that gap is where delivery struggles.
Why AI is forcing convergence on FDE
With the triad as context, the movement toward Forward Deployed Engineering becomes clear.
Product companies are strong on technology and product craft — they built the models and the platform. What they lack is enterprise business delivery. Understanding a customer’s specific workflow, speaking their industry’s language, navigating their operational constraints requires a proximity that product organizations are not structured for. FDE is the mechanism for acquiring this — embedding engineers who gain first-person visibility into how the technology performs in real conditions, not mediated through the client’s description of the problem. When someone describes a pain point or a value opportunity, the abstraction is severe. First-person contact with the work itself — building the solution, running it in the customer’s environment, understanding firsthand why it fails or succeeds — is what makes FDE effective and what feeds insights back into the core product.
Services companies understand enterprise operations and have scaled organizations for client delivery. Their structural challenge is that revenue driven by billable headcount incentivizes volume over engineering caliber. The economics favor placing large numbers of resources where the client needs general IT staffing. AI delivery demands small, high-caliber teams with deep technology understanding and product-grade craft — the opposite profile. This challenge is compounding: as coding agents make the placement of junior engineers increasingly redundant, the volume-driven model faces pressure from both directions — enterprise AI requires higher caliber, while the traditional base is being automated.
Product consultancies have been operating in this mode — embedding with clients, building solutions at a product level, navigating enterprise complexity firsthand. Their path into AI requires building foundational depth in the technology, which is achievable given the engineering caliber already in place.
What AI changes about the triad
The three capabilities are not new. Product engineering, business delivery, and technology depth have always mattered. What AI changes is how tightly coupled they must be at the team level.
In pre-AI engagements, a product manager could lean on proven patterns — a CRM, a mobile app, a cloud deployment — and work within established design paradigms. The technology was relatively deterministic. Roles could specialize: strong on business delivery but lighter on technology, or deep in technology but less fluent in business context.
AI does not afford that separation. The technology is non-deterministic. Value is realized over the lifetime of the system and increases with adoption and as the system learns through usage — co-pilot interactions, feedback loops, and compounding accuracy over time. Expectations have to be managed around this reality, because enterprise decision-makers are accustomed to products that work as specified from day one.
This means the product manager must deeply understand both business context and technical constraints — what AI can and cannot do, how non-determinism shapes the solution. The solution engineer must understand business outcomes well enough to prototype toward production value, not just demonstrate capability. The program manager must be technically fluent enough to manage risk in a system whose behavior evolves with use.
In practice, this compresses the triad from an organizational property into a team-level — and individual-level — requirement. The teams that succeed in AI delivery are smaller, higher-caliber, and composed so that every member carries meaningful strength across all three legs, with relative depth in one or two. Professionals who thrived in pre-AI environments with strength in one or two dimensions find that the bar has shifted.
What this means for enterprises
The qualification bar for technology partners has risen. AI delivery requires strength across the full triad. Evaluating partners on all three dimensions — not defaulting to existing relationships or familiar engagement models — is a prerequisite for durable value.
Invest in AI as compounding organizational capability. AI systems grow alongside your organization. They learn from your data, workflows, and domain expertise. The learning loop compounds value with use. Deepening internal investment in AI — understanding the technology, shaping the solutions, retaining the institutional learning — is strategically important even when working with strong external partners.
Enable forward deployment as a collaborative model. When partners embed engineers inside your environment, there is often initial resistance from internal teams. Leadership should frame these engagements as one team working toward shared outcomes, and paint the longer-term arc in a way that motivates all participants. The organizations that treat embedded engineering as collaborative rather than intrusive get to value faster.
The takeaway
Forward Deployed Engineering exists because AI is too abstract to be adopted through traditional distribution. The gap between AI capability and enterprise value is an engineering problem — and closing it requires technology depth, business delivery expertise, and product engineering craft operating together.
Successful product consultancies have long operated this way. AI product companies are quickly embracing FDE. And enterprise decision-makers are increasingly focusing on the triad of competencies they need from their partners to extract durable value from AI.