What is forward deployed engineering?

01Where the term comes from and what it means now

The role is usually traced to Palantir, which found that its software only became useful once engineers sat with customers and worked through their real data and constraints. Those engineers were not support staff or consultants writing reports. They wrote production code against the customer's systems, inside the customer's approved processes.

The term has spread quickly with AI, for a plain reason: AI features are easy to demo and hard to deploy. A model can answer a question in a notebook in an afternoon. Getting it to answer correctly inside a live product, with the right tenant's data, the right user's permissions and a release process that protects paying customers, is a different job. That job needs people who know the product well, and most product teams are already at capacity.

So today the phrase covers a range of setups, and buyers should ask which one they are getting:

• A vendor's engineer who configures the vendor's own platform for you.
• An implementation engineer who integrates a tool and then leaves.
• An engineer who joins your team, works in your codebase and owns one outcome under your engineering leadership.

The third version is the one that matters for a SaaS company adding AI to a product its customers already use, and it is the one we mean when we use the term.

02Why embedding matters more for AI than for ordinary features

When an AI capability lives inside a mature product, most of the work is not the model. It is everything around it. That includes the data model the AI reads from, the integrations that feed it, the permission rules that decide what each user may see, and the release process that keeps customers safe. An outside team working in its own repository cannot see those things clearly, and it tends to rebuild them in simplified form. That is how AI pilots end up running on a copy of the data, with no permission model, and then stall when someone tries to connect them to the real product.

An embedded engineer works against the real thing from day one. That changes several outcomes:

The code review row is the one we would weigh most. Code review exists so that someone other than the author checks the code before it reaches the product. When your own engineers review every change from an embedded engineer, knowledge transfer happens continuously, quality stays at your standard, and there is no risky handover at the end.

03How we run a forward deployed engagement

We start from the product, not from the model. Before any AI code, the engineer maps how the product already handles the data and the workflow the AI will touch. Then the work follows a fixed order:

1. 01

   Agree on one outcome.

   One AI capability, owned end to end, with a clear definition of done that your CTO or VP of Engineering signs off on. Not a backlog of loosely related tickets.

2. 02

   Join your process, not the other way round.

   Access to your repositories, your ticketing, your environments and your review rules. The engineer follows your branching model and your definition of done.

3. 03

   Map the existing system before changing it.

   Data model, integration points, permission checks and the release pipeline. This is where most surprises are found, and finding them early is cheaper than finding them in production.

4. 04

   Test assumptions against real behavior.

   Third-party systems rarely behave exactly as their documentation says. We test with real events and compare the results before we build the production path.

5. 05

   Ship small changes through your pipeline.

   Each change goes through your pull request review and your release process, with tests your team can run.

6. 06

   Leave the knowledge in the team.

   Because your engineers reviewed every change, they can run the capability after the engagement without a separate handover project.

Two practical checks help a CTO judge whether this is working. First, look at who approves the pull requests: if it is always the outside team, the engineer is not really embedded. Second, look at where the decisions are written down: they should be in your tickets and your documentation, not in a vendor's slide deck.

04What we see in production

One engagement shows this model clearly. Since early 2023, our full stack AI engineers have worked inside the engineering team of an established communication intelligence platform for dental and veterinary practices. The client leads the product and owns it. Our engineers deliver inside it, under the client's processes, repositories and pull request reviews. The engagement is still running more than three years later.

The platform was already live when our engineers joined. It carried call data and practice context, integrated with many practice management systems and phone providers, and had its own API, a published API client package and a cloud function pipeline. All work had to fit those pieces, its permission model and its HIPAA-aligned boundaries.

The first integration with a cloud phone system shows why embedding mattered. Call data arrives as streams of raw events, and each phone provider exposes those events differently. This provider offered two subscription models that behaved differently, its API changed during the work, and its documentation did not answer every question.

Our engineers did not start by writing the integration. They first mapped the product's existing data model and audio pipeline. Then they tested both subscription models side by side with real test calls, compared the event streams, and raised the gaps with the vendor's support team. Only after that did they build the production path. It covered webhook intake, validated event models, a cloud function that turns raw events into the product's own call records, and an updated release of the client's API client package with test coverage.

None of that would have been possible from a separate codebase. The work depended on the client's own data model, its own client library and its own cloud environment, and every change passed the client's review before it shipped. That is the practical meaning of forward deployed engineering: the engineers carry the outcome, and the client keeps control of the product.

05When forward deployed engineering is the right choice

It is not the answer to every AI project. It fits best when:

• The product is established, with real customers, real data and integrations that took years to build.
• Your team knows what it wants the AI to do but does not have the hours to build it alongside the roadmap.
• The AI must respect existing permissions, tenancy and compliance boundaries.
• You want to keep ownership of the code and the knowledge, not license a separate system.

It fits less well when you need a whole new product from nothing, or when nobody on your side can review code. Embedding depends on a reviewer who knows the product. If that person does not exist yet, the first step is to name one.

There are also trade-offs to plan for. An embedded engineer needs onboarding time and real access, which means your security team has to agree on scope early. Your reviewers will spend time on pull requests. And the engagement works only if the outcome is narrow enough to own. We usually see the best results when one engineer, or a small group, owns one capability with a clear boundary, rather than spreading across many small requests.

06How to evaluate a forward deployed engineering partner

When you speak with a possible partner, ask questions that test whether the engineers will really work inside your product:

• Will the engineers commit to our repositories and follow our pull request rules from the first week?
• How do they learn an unfamiliar codebase, and what do they produce in the first two weeks?
• How do they handle a third-party system whose behavior does not match its documentation?
• Who owns the code and the work product? It should be you.
• What happens to our data? Ideally the engineers work inside your boundaries, with access scoped to what the outcome needs.

If you want more context on why so many AI features stall between demo and production, our piece on why AI agents fail in production covers the failure patterns we see most often. For the wider question of adding AI without a rebuild, see how to add AI agents to existing SaaS without rebuilding.

Much of the day to day work follows the approach in adding AI agents to an existing SaaS product without rebuilding it.

Frequently asked questions