What is forward-deployed engineering? A guide for mid-market companies

Forward-deployed engineering is a way of delivering software in which engineers work alongside a customer’s team to solve problems inside the business. They learn how the work gets done, connect the relevant systems, build the software and help people use it in production. A forward-deployed engineer, often shortened to FDE, stays close enough to the work to see where the software succeeds and where it needs to change.

The model started at Palantir in the early 2010s, where the role was known internally as Delta. For several years, the company employed more forward-deployed engineers than conventional software engineers. The approach has since spread across the AI industry. OpenAI and Anthropic now back services firms that use it. A study reported by TechCrunch in July 2026 found that 70% of companies surveyed planned to hire forward-deployed engineers by mid-year.

For a mid-market company adopting AI, that is a useful arrangement. A promising demonstration still leaves practical questions unanswered. Where does the data come from? Which numbers should the system trust? Who checks the output, and how does it reach the person who needs to act on it?

Those questions are the substance of the engineering work. In my view, they are also why an embedded team can be so useful.

What does a forward-deployed engineer do?

A forward-deployed engineer needs to understand the business well enough to build something that fits. That can mean sitting in the weekly operations meeting, watching finance close the month, or asking why the controller keeps a separate spreadsheet when the company already has an accounting system. There is usually a reason.

The answers shape the software. An engineer building a contract review workflow needs to understand how pricing is agreed, where amendments are stored and how billing works. Extracting a price from a document is one task. Establishing whether that price applies to a particular invoice takes more context.

The engineer then connects the data, builds the workflow and tests it with the people who will use it. Once it is live, they investigate errors, handle exceptions and adjust the software as the team learns what works. That continued involvement is a defining part of the model.

The work can happen on site or remotely. What matters is access to the people doing the job and regular opportunities to see the software in use.

Why does the model suit mid-market companies?

Consider a company whose customer records sit in a CRM, invoices in an accounting package, job schedules in a field operations tool and contract terms in shared folders. Each system serves a purpose. Answering a question that crosses all four can still require someone to assemble the evidence by hand.

The difficulty is rarely just moving data. The same customer may have a different name in each system. A contract amendment may explain a billing exception. The operations manager may know that one crew’s reported utilization excludes a category of work that another crew records. Those details determine whether an answer is useful.

A mid-market company may have experienced finance and operations teams without spare engineers to turn that knowledge into software. Its IT team may already be occupied with the systems the business depends on. An embedded engineering team provides the capacity to work through these problems with the people who understand them.

The economics depend on the problem. A recurring billing error or a reporting process that consumes several people’s time may justify a custom implementation. An occasional inconvenience may not. The starting point is the value of fixing the workflow.

How does it compare with consulting or buying AI software?

An off-the-shelf product is a sensible choice when it already fits the task. It can provide a well-tested workflow at a lower cost than building one. The work to assess is what remains after purchase: connecting data, configuring the product, assigning ownership and helping people adopt it.

Forward-deployed engineers can take responsibility for that implementation work. They may use existing products, build custom applications, or combine the two. Buying software and hiring an embedded team can therefore be parts of the same project.

Consulting covers a wide range of services. Some firms advise on strategy; others build and operate software, including through embedded teams. The useful distinction is in the engagement itself. Who will write the code? Who is responsible for getting it into production? What happens when an integration breaks or the business changes its process? The answers matter more than the job title.

What does a forward-deployed engagement look like?

At DealSage, we organize the work around four steps: connect, centralize, implement and decide. We start with a defined business problem and build the foundation it needs, extending it as more workflows come into scope.

1. Connect the relevant systems

The engineers establish access to the systems and documents needed for the first workflow. For a billing review, that might include customer contracts, invoice records and job data. They check how records match across sources, how often the data changes and who should be able to see it.

The aim is to work with the systems the company already runs. Starting with a focused workflow also gives the team a concrete way to test whether the connections are complete and accurate enough.

2. Centralize the business context

The connected information needs a consistent meaning. The engineers define the customers, contracts, jobs and invoices involved, establish how they relate, and agree which source is authoritative for each fact. They also document relevant business rules and exceptions with the people responsible for them.

This shared model is sometimes called an ontology. It gives the software a way to understand that a contract, an invoice and a job record belong to the same customer. Our guide to a firm ontology explains the same principle in the context of deal teams.

A shared model makes the relationships explicit, but it still needs validation. Missing records, conflicting definitions and outdated terms have to be resolved or made visible to the user.

3. Implement the workflow

The engineers build the application or AI agent around the task the team needs to complete. Where practical, it fits into the tools people already use. A contract review application, for example, might flag a difference between agreed pricing and actual billing, show the supporting evidence, and route it to finance for review.

Before release, the team tests real examples and exceptions, agrees which actions need approval, and checks the output against the underlying records. After release, the engineers watch how the workflow is used and adjust it. Support, maintenance and any eventual handover should have clear owners.

4. Improve the decision

The workflow should help someone decide what to do. A billing flag needs enough context for finance to establish whether a correction is due. A crew productivity view needs consistent measures that an operations manager can use when planning work.

That is the test of the preceding steps: can the person responsible reach a sound decision with less effort, and can they trace the evidence behind it?

What does this look like in practice?

In our work with a PE-backed field services company, the team connected the data warehouse, finance, billing, HR and customer contracts. We then assessed opportunities across the business and used their estimated value to prioritize the builds.

A contract review application compared customer agreements with actual billing and flagged pricing differences. A crew productivity view gave operations managers and finance a shared set of numbers. Reporting drew on the connected business model, while an agent prepared the weekly operations review for the leadership meeting.

Each workflow served a recurring decision: which accounts needed a billing review, where operations needed attention, and what leadership should address that week. The connected data supported several uses because those decisions drew on overlapping information.

What should the engineers build first?

Choose a recurring decision with a measurable consequence and someone responsible for acting on it. Recovering missed revenue, reducing the time spent closing the books or identifying unbilled work are useful starting points because the business can describe both the problem and the desired result.

Before building, establish a baseline. How often does the task occur? How much time does it take? What do errors cost? Which systems and people are needed to improve it? An estimate is enough to begin prioritizing, provided its assumptions are clear.

The first workflow should be valuable enough to justify the effort and narrow enough to test. It should also have an agreed production milestone. Timing will depend on access, data quality and the checks required before people can rely on the output. For the four points where most pilots stall, see why most AI pilots never reach production.

How do you know it is working?

Start with adoption. The intended users should return to the workflow when the task comes around, whether that is daily, weekly or at month-end. If they still maintain the old spreadsheet alongside it, find out why. They may be checking the output during a transition, or they may know something the new system has missed.

Then measure the business result against the baseline. For contract review, count confirmed billing corrections and revenue recovered. For month-end reporting, measure the time spent preparing and checking the reports. Include the effort required to review AI output and fix mistakes, as well as the cost of running the system.

Usage tells you whether the workflow has found a place in the business. The outcome tells you whether that place is worth paying for.

When is forward-deployed engineering the wrong choice?

A standard tool may be enough for a self-contained task such as expense management or meeting transcription. Custom engineering adds cost and ongoing responsibility, so it needs a reason.

A company with an internal engineering team may also be able to do the work itself, provided that team has the capacity and access to the business. External engineers are most useful when they fill a specific gap.

The company must be able to participate. Engineers need people who can explain exceptions, resolve conflicting data and make decisions about how the workflow should operate. A senior sponsor helps, but the people doing the work need time to contribute too. Without that access, the team will struggle to build software the business can trust.

Who does forward-deployed engineering for mid-market companies?

The field has grown quickly, but most providers were built to serve companies larger than the mid-market. The table summarizes each provider’s published offering as of October 2026.

Provider	Built for	What it offers
Palantir	Large enterprises and governments	Foundry and AIP with its own forward-deployed engineers. Its UK price list puts engineering at £150,000 per person per quarter
Ode (with Anthropic)	Mid-sized companies across sectors	Embedded engineers working with Anthropic’s applied AI team; Claude-first. Absorbed Fractional AI
OpenAI Deployment Company	Large business customers	Forward-deployed engineers for OpenAI models, including about 150 from its Tomoro acquisition
Distyl AI	Fortune 500	Platform plus embedded engineers on multi-year programs
Tribe AI	Enterprise	Small senior teams drawn from a network of 600+ engineers; model-agnostic
Phos AI Labs	Companies with $5 million+ revenue	Embedded AI practice with published prices, from $10,000 for discovery
Forward Deployed	PE portfolio companies	Founder-led; one workflow in 30, 60 and 90-day phases
Lunon	Private capital and complex enterprises	Founded 2025; diligence work alongside embedded builds
DealSage	PE firms and mid-market companies	Engineers plus a platform that holds one model of the business, so each workflow builds on the last

Compare providers on three questions. Does the provider leave behind a shared model of your business or a set of separate projects? Is it tied to one AI model vendor? Who owns and runs the software after the engagement ends? Our guide to Palantir alternatives for mid-market companies explains how the platform options compare.

How does this work across a private equity portfolio?

A private equity firm faces the same problem across its portfolio. Each company runs its own systems and reports its numbers differently. The firm’s team then assembles a portfolio view every month from spreadsheets and board materials.

Forward-deployed engineering applies at both levels. At each portfolio company, engineers connect systems and build workflows that advance its value creation plan. At the firm, the same structured model supports portfolio monitoring. KPIs have consistent definitions and can be traced to their source without retyping the data. Each new company builds on integrations and definitions proven at the previous one, making the second and third deployments faster than the first.

How DealSage does forward-deployed engineering

DealSage embeds engineers with your team to connect your existing systems, build a shared model of the business on our platform and put AI workflows into production. We were built by alumni of J.P. Morgan and Palantir, and we are not affiliated with Palantir. Throughout the engagement, our engineers work with the people who use the software and refine it as it becomes part of daily operations.

We started in finance, working with private equity firms and the companies they back, and apply the same approach to mid-market operating businesses. The work starts with a decision and the information needed to make it well.

If your team spends more time assembling the evidence than acting on it, talk to us about the workflow and what improving it would be worth.