Forward deployed engineer vs solutions engineer: who to hire

01Forward deployed engineer vs solutions engineer, side by side

The titles get used loosely, so compare the jobs, not the labels. Here are both roles beside the two models buyers most often confuse them with.

The cleanest proof that these are different jobs comes from the AI labs themselves. Anthropic hires a pre-sales Applied AI Architect who partners with account executives, runs technical discovery and builds prototypes and proofs of concept. It hires a separate Staff Forward Deployed Engineer who embeds with strategic customers, works inside customer systems to build production applications and agent components, and owns engagements end to end. One role helps a customer decide. The other helps a customer ship.

02Where the forward deployed model came from

The title started at Palantir. In a January 2026 a16z piece on forward deployed job titles, Tom Hollands describes how Palantir, in 2011, took its solutions and integration engineers, gave them the title forward deployed engineer and called the team Deltas. Palantir still hires for the role, and its Forward Deployed Software Engineer posting describes engineers who work with customers, often on site, lead from system design and prototyping, and see projects through from beginning to end.

AI labs adopted the model as their customers hit the gap between a capable model and a working system. In June 2025, Joe Schmidt of a16z wrote in Trading Margin for Moat that OpenAI and Anthropic had been hiring forward deployed engineers and solutions engineers, and counted 22 of 311 open roles on OpenAI's careers page in those categories. eWeek reported in November 2025 that OpenAI set up its own forward deployed engineering team at the start of 2024, and that Anthropic intended to grow its applied AI team, which includes forward deployed engineers, fivefold that year.

Two lessons for buyers follow. First, even the companies with the best models found that a model alone does not deliver an outcome: someone has to build it into the customer's systems. Second, a lab's forward deployed engineer builds on that lab's model, for the lab's largest accounts. If you run an established product on your own stack and want an AI feature that fits your code, your permissions and your release process, you need someone whose only stake is your outcome. Our pillar guide to forward deployed engineering covers the model in more depth, and the piece on what the forward deployed engineer role involves day to day covers the work itself.

03How both differ from staff augmentation and consultants

Staff augmentation rents you people. You direct their work, you pay a rate per person each month, and the result is still yours to deliver. That works when you have a clear plan and a manager with time to supervise. It fails when the real gap is ownership, because adding hands to a project nobody owns makes it slower.

A consultant tells you what to do. That is valuable when you do not yet know which problem to solve, but a slide deck does not merge into your main branch.

A solutions engineer, as above, helps you evaluate and adopt a vendor's product. Their incentives are tied to that product, which is fine as long as you know it.

Our forward deployed engineers work differently from all three. Our engineer joins your team, works in your repositories, your tickets and your release process, and owns one outcome until it is live. It is not staff augmentation: there is no monthly rate per person and no headcount to manage. You pay a fixed quote for the outcome, not for hours, which is why the fixed price vs time and materials question matters so much here. When the outcome ships and your team can run it, the engagement ends.

04Signs your AI project needs a forward deployed engineer

You likely need a forward deployed engineer, rather than a solutions engineer or more contractors, when several of these are true:

1. 01

   The outcome is clear, but nobody owns it.

   You can name the feature, the users and what done looks like, yet it has sat in the backlog for two quarters.

2. 02

   The work lives in an established codebase.

   The AI feature has to respect existing logins, roles, data models and release gates. That is a brownfield problem, not a greenfield one, and it rewards someone who works inside the code rather than beside it.

3. 03

   Your proof of concept stalled.

   A demo worked, but turning it into a production feature with evaluations, monitoring and permissions never happened. Our guide to the AI proof of concept explains why that gap is so common.

4. 04

   Your team is strong but fully booked.

   Your engineers can review and maintain the work, but cannot also lead a new AI build.

5. 05

   Vendor help stops at the integration boundary.

   The platform's solutions engineer helped you choose it, but the hard part is connecting it to your own product, and that is outside their remit.

6. 06

   You want a fixed answer on cost.

   Leadership wants a price for the outcome, not an open-ended monthly burn.

If you are still choosing a platform, start with the vendor's solutions engineer. If you are not sure what to build yet, start with a short planning step.

05What to ask before you engage a forward deployed engineer

Before signing, ask the provider these questions. Vague answers are a warning.

• What exactly is the outcome? It should be written down as one feature or capability with a test for done, agreed by your tech lead.
• Where will the code live? The answer should be your repositories, your cloud accounts and your environments, never theirs.
• How does work get merged? Through your pull requests and your code review, with your engineers approving.
• How is it priced? A fixed quote per outcome or a rate per person per month. Only the first puts the risk of delivery on the provider.
• How will we know it works? Look for evaluations or tests that run in your pipeline, so a model upgrade becomes a routine change.
• What happens when the outcome is live? Expect documentation and runbooks in your repositories, and a handover your team can run without them.
• What if the outcome cannot be defined? A good provider will say so early and propose a planning step rather than start building on guesswork.

06What we see in production

On Coast Technology, which sells a customer intelligence and engagement portal to RV, auto, powersports and marine dealers, our engineers and analysts work as part of Coast's product team, in its accounts and its sprint rhythm. We rebuilt the original portal module by module in weekly sprints while dealers kept using it, then added a CRM layer, integrations with dealer CRMs and messaging providers, email campaigns, white label brands and an in-portal AI chat assistant. Everything runs in Coast's own AWS and Google Cloud accounts, and API documentation and support guides let Coast's own team maintain each module. The portal grew from a reporting tool into a CRM and engagement platform without a core rewrite.

On CleanHaus, a live platform for short-term rental turnovers, our forward deployed engineers worked in CleanHaus's own repositories and accounts, with code reviewed by its CTO and shipped through its pipelines. They built role-aware agents that act through CleanHaus's APIs under each user's login, in app chat, text, Slack and voice, and replaced the Ionic and Vue mobile app with one React Native codebase. Tiered tests and evals run in CleanHaus's CI on every push, and runbooks, tests and traces stayed in its accounts. CleanHaus reported its app and AI agent live, and the work continues.

On Assembly Software, a B2B SaaS company selling to professional firms, customer and prospect data sat in five systems that disagreed about the same account. Our engineers work inside Assembly's data team and its own Azure environment, under direction from its IT and business systems lead. We set survivorship rules first, then built master account, contact and activity layers in Azure SQL with entity resolution, documenting each layer as it was built so the model stays with Assembly's team. That work is in progress.

The pattern is the same each time: the work happens in the client's own accounts, under the client's direction, and leaves documentation behind so the client owns what was built.

Our forward deployed engagements start with a one-week Outcome Sprint for $2,500, which ends with an outcome your tech lead has agreed and a definition of done. After that, you get a fixed quote per outcome, delivered in two-week sprints, and the Outcome Sprint fee counts toward the engagement.

Frequently asked questions