Why Tech Companies Are Investing Billions in Forward Deployed Engineers

The value lies in making prototypes work inside businesses

Forward deployed engineers are drawing major commitments from technology companies because building a first version of an AI tool has become easier. The harder job is making it work with a company’s data, systems and people, while meeting its security and operating requirements. That shift puts the focus on whether software changes a business outcome, rather than simply whether a team can ship it.

On June 30, AWS announced a $1 billion investment in a new unit built around the role. OpenAI had put more than $4 billion behind its Deployment Company in May. Those sums point to a bet on hands-on customer work as a way to turn AI capabilities into systems that organizations can use. They don’t, by themselves, show how quickly those efforts will produce measurable returns.

A forward deployed engineer, or FDE, works inside a customer’s environment to design, build and ship AI or custom software. Palantir helped popularize the title and describes the distinction this way: a conventional engineer builds “one capability, many customers,” while an FDE delivers “one customer, many capabilities.” The second model starts with a specific organization’s needs and may combine several technical components to address them.

The underlying approach has a long history. In the 1950s and 1960s, IBM sent systems engineers to work alongside customers using its mainframes. They wrote code and configured the machines, with that work initially included in the hardware price. IBM began charging for it separately at the end of the 1960s. Later, consultants and implementation teams also worked within client organizations. What’s changed is the speed at which businesses can now make a working model—and the expectations for what happens after.

AI prototypes change the project sequence

For years, business and IT often operated like a client and vendor. Business teams documented requirements; IT then planned and delivered a project that could take six months or a year, with separate development, integration, testing and training work. The distance between the original need and the delivered system could leave important details unresolved until testing, when changes were expensive. The business might also have little ability to change the finished tool without returning to an IT queue.

AI assisted coding, sometimes called vibe coding, changes the early stages. A business user can assemble a working first version of an app in days. That prototype may not be ready for production, but it gives teams something concrete to examine and improve. Instead of trying to settle every process detail before development begins, they can test ideas while they build.

That speed makes experimentation cheaper, but it doesn’t solve the difficult integration work. An early app may not connect to the right data, reflect how another team handles a task, pass a security review or scale across an organization. A prototype can show what users mean; engineers still need to turn that knowledge into a dependable system.

That’s the gap the FDE model is meant to address. Its central task is coordinating technology, data, workflows and people quickly enough to change a business result. The work also shifts accountability: deploying a system is a milestone, but the more useful test is whether it creates measurable value.

Engineering skill and business context belong together

A genuine FDE writes production code, works with customer data and systems, and ships software. A role centered on strategy presentations without that engineering responsibility is closer to consulting. The distinction matters because customers need builders who can address technical constraints directly, not only describe what a solution could do.

Technical depth may include SQL, cloud platforms, Python and experience putting large language models and agents into production. FDEs also need to understand how governance, security and compliance affect the design. The work calls for judgment about what can be built within a customer’s systems and what needs to change before it can operate there.

Functional knowledge matters too, but it doesn’t mean every FDE must hold a professional credential in the customer’s field. An OpenAI healthcare FDE role asks for familiarity with payer workflows, provider operations, electronic health record systems or standards such as HL7 and FHIR. It says clinical credentials aren’t required. The key is understanding how work moves through a function: who approves what, where handoffs happen, which systems and data are involved, and what operating rules apply.

That context differs by assignment. Someone working on healthcare billing needs a different understanding from someone building for supply chain operations. FDEs don’t have to be the subject matter experts; they need to ask informed questions and work effectively with the people who are.

Customer discovery is a substantial part of the job. The source author estimates FDEs spend roughly 60%-70% of their time with customers. They must turn loosely defined problems into a workable scope and explain technical trade-offs in terms business teams can assess. Their performance is tied to outcomes, not the number of tickets closed: the question has moved from whether a system was deployed to whether it created value.

A lean enterprise team might include two or three engineers, a business specialist who knows the function, someone accountable for data and the platform, and a business owner responsible for the target metric. That mix keeps technical decisions connected to how the work is done and how results will be judged.

Build controls into the work from the start

Fast, business led development can raise concerns about shadow IT. The answer in the FDE model is to work within the customer’s existing standards: build in its environment, use governed data and follow established access controls. Security and compliance teams should be involved during discovery, when data classification, residency needs and audit evidence can shape the design.

Teams can also define audit trails from the outset, recording what went into a system, what it produced and why. They should agree which actions an agent may take independently and which require human approval. Clear test cases with pass and fail criteria provide evidence about whether a system stays within its agreed boundaries, and a person should review AI generated code before it ships.

Documentation and maintainability are part of delivery, too. A customer needs to understand and operate the finished system after the FDE team moves on. Otherwise, the work remains dependent on the people who built it, limiting its practical value.

The model’s appeal is the chance to pair faster experimentation with engineering that accounts for real operating conditions. Its test will be whether teams can move from prototypes to systems that fit enterprise data and workflows, meet the controls already in place, and leave customers able to maintain what they use.