What Forward-Deployed Engineering Does
Why a shared AI platform still needs engineers who can turn its capabilities into owned business workflows.
On this page
Large enterprises can make model access, retrieval, tools, and controls available through a shared AI platform. Those capabilities reduce the cost of starting an application, but they do not complete a business process. A business process still needs local data, rules, decisions, exceptions, and an owner.
Consider transaction screening in an investment bank. The platform may retrieve filings and draft a brief, while analysts still verify the evidence and a senior banker decides whether deeper work is justified. The unresolved work sits between general technical capability and the decisions that the business must make.
Forward-deployed engineering, or FDE, is the function that resolves that connection. FDEs work with a business function to understand its process, connect the required data and systems, and build a proposed solution that people can use. They also return recurring technical requirements to the shared platform team.
This article explains the function through four decisions. It first separates shared platform capability from business-process responsibility. It then shows the engineering work FDEs add, compares several ways companies organise that work, and closes with the conditions for an internal FDE practice. The transaction-screening case is illustrative, not a measured result.
Uber's GenAI Gateway and Walmart's Element show why enterprises invest in shared technical foundations. Uber gives application teams a common route to different models. Walmart provides shared capabilities across machine-learning development and operation. These examples support the platform claim, but they do not show that either company uses an internal FDE practice for every business process. Uber's engineering account, Walmart's engineering account.
This is the first of three articles about an internal FDE practice for a large enterprise. The second article explains how to establish the practice with authority, funding, staffing, and an operating destination. The third explains how to run engagements, review evidence, transfer responsibility, and decide whether to continue or stop.
What does a shared platform leave to the business?
The larger point is that enterprise AI work has two kinds of uncertainty. The platform team can reduce uncertainty about model access or retrieval. It cannot determine what counts as a correct result in every business process. That definition depends on local data, policy, authority, timing, and consequences.
Consider an investment banking team that wants an AI application to prepare a first-pass transaction screening brief for a potential acquisition. The platform may retrieve public filings, approved internal research, and market data. It does not know whether a source is current, whether a document is within the deal team's permissions, which reporting period supports a comparison, or what evidence a senior banker needs before deciding whether to pursue deeper work. A plausible brief can still use the wrong entity, an obsolete figure, or a source that the team cannot use.
The deal team owns those meanings, while the platform team owns capabilities that can help represent them. Somebody must connect the two. An engineer needs to understand the screening process, translate its rules into data selection and application behaviour, and build the review path around the model output. The important result is not a fluent summary. It is a source-linked brief that lets the deal team decide whether further work is justified.
Manufacturing creates the same issue in a different form. A shared platform may extract information from supplier certificates and retrieve related records. The manufacturer still needs to determine which subsidiary a certificate covers, whether it is current, which requirements apply to that supplier category, and who can approve an exception. The local process gives the platform's general capabilities their operational meaning.
These examples illustrate one principle. A central platform can provide technical primitives, but a business process also needs definitions, decisions, permissions, exceptions, and an owner. The FDE function performs the engineering that connects those elements. Its value is measured by the usefulness of the resulting solution, not by model calls or generated summaries.
What FDEs add to the platform
FDEs work at the point where the platform's general capabilities meet a particular operation. In investment banking, they might combine document parsing, market-data retrieval, entity matching, and evidence presentation for transaction screening. In manufacturing, they might combine document extraction, source validation, and exception routing for supplier onboarding. The combinations differ because the business rules differ, even when the underlying primitives are shared.
The platform should expose primitives with clear interfaces. Useful primitives might include permission-aware retrieval, model access, document parsing, workflow state, tool execution, and evaluation services. The purpose of a primitive is not to impose one process on every business unit. It is to provide a reliable capability that several applications can use without rebuilding it.
The FDE practice makes those primitives more valuable in two ways. First, it combines them with local requirements to complete a workflow that the platform team could not specify in advance. Second, it gives the platform team evidence about which local requirements recur often enough to deserve shared support.
Suppose the transaction-screening and manufacturing applications both fail because retrieval returns a document without its source owner, effective date, or entity identifier. An FDE team can bring the platform team concrete cases, the decisions those omissions affect, and a tested proposal for returning the missing metadata. The platform team can then decide whether to add a shared capability. That is more useful than a general request to make retrieval better, because it connects a product change to observed business consequences.
The distinction also protects the platform from absorbing every local rule. The banking definition of a comparable peer or a permitted screening source may belong to the deal team. The manufacturing definition of an acceptable supplier certificate may belong to procurement. A shared retrieval service can expose dates, ownership, and provenance without pretending to decide what those facts mean in every process. FDEs help locate that boundary through real deployments.
How companies organise this work
Palantir's 2019 account makes the two responsibilities easy to see. Product engineers developed capabilities intended for use across customers. Forward-deployed engineers combined those capabilities with the data, systems, and operating requirements of a particular customer. The FDE could also contribute a change to the shared product when a local deployment revealed a broader need. Palantir's account.
The significance is not the job titles. It is the location of responsibility for the unfinished work. A product team can deliver a retrieval feature while a customer's screening remains incomplete because its source systems are different or its review rules are specific to that organisation. The FDE gives those remaining requirements an engineer who can resolve them, while preserving a route for general lessons to return to the product.
Current deployment organisations make different choices about how much of that work they include. OpenAI's deployment announcement describes engineers working with customers to select workflows, build applications, and deploy them with relevant data, tools, and controls. In that model, application delivery is part of the engagement because the customer needs a working system, rather than advice about how to build one. OpenAI's announcement.
Anthropic now describes a related model through Ode with Anthropic, a separate enterprise AI services firm that combines Anthropic models with experienced AI engineers and operators. The point of the arrangement is to provide implementation depth and business understanding for organisations that need help turning models into operational systems. It places deployment capability in a specialist partner while keeping the connection to the model and product teams. Ode with Anthropic.
PostHog describes a more bounded version of the work. Its handbook emphasises an agreed result, the engineering required to reach it, and a clear point at which the engagement ends. That arrangement makes sense when the main need is a defined integration rather than continuing transformation support. PostHog's handbook.
These examples matter because they show that FDE is a function, not one organisational template. One company may need engineers to build complete applications. Another may need a partner that supplies specialist delivery capacity. Another may need a bounded integration that ends when a defined result is in operation. The right arrangement depends on what remains unresolved after the general product or platform is available, and on who can own the work after deployment.
When an enterprise should consider an internal FDE practice
An enterprise should consider an internal FDE practice when a recurring class of valuable workflows needs close engineering work across business and technology teams, and no existing team can own the complete result. The signal is not that business teams have many AI ideas. The signal is that platform capabilities exist, the workflows matter, and delivery repeatedly stalls on the connection between general software and local data, rules, systems, or operating responsibilities.
The case becomes stronger when the same pattern appears in several business units. Investment banking may need engineers who can work through source meaning, confidentiality controls, and review. Manufacturing may need engineers who can connect supplier evidence to procurement decisions. If each team encounters the same delivery gap, an internal practice can provide a repeatable way to resolve it and return useful platform improvements.
The case is weaker when an established product team already understands the workflow, controls the relevant data, and can operate the application after release. It is also weaker when the work is routine configuration, a one-off demonstration, or a missing shared primitive that should be built centrally. In those situations, adding an FDE team may create another handoff instead of resolving the underlying problem.
The question is therefore not whether every enterprise needs a separate FDE team. The question is whether the enterprise has a repeated delivery problem that requires engineers to work across organisational boundaries and complete business workflows.
The test is simple to state. The platform supplies shared capability. The FDE function resolves recurring local delivery gaps. An internal practice earns consideration when existing teams cannot own the complete result.
The next article explains how to diagnose that problem and design an internal AI FDE practice with the authority, funding, and operating destination it needs.