On this page
- Key Takeaways
- What Is a Forward Deployed Engineer?
- Why Do AI Pilots Stall Before Production?
- Step 1: How Do You Prepare Your Team Before Forward Deployed Engineers Arrive?
- Step 2: How Should Forward Deployed Engineers Work Inside Your Team?
- Step 3: How Do You Move an AI Pilot to Production With Forward Deployed Engineers?
- Step 4: How Do You Take Ownership When the Engagement Winds Down?
- How Do Strong Teams Get the Most From Forward Deployed Engineers?
- Checklist for Evaluating Your Forward Deployed Engineering Engagement
- Ship AI to Production With PressW Forward Deployed Engineers
- FAQ
Key Takeaways
- Forward deployed engineers close the gap between a working pilot and a production system. They work inside your environment, with your people, until the system runs on your real data and your team can run it.
- Prepare before they arrive. Pick one workflow, define what production means for it, clear access and security review, and name a business owner and a technical owner.
- Put them where the work happens. Bring them into your standups, your tools, and your code review, and give them time with the people who do the work today.
- Promote to production through written gates. Evals, integration, security, monitoring, rollback, cost, and a runbook, each signed off with evidence.
- Plan the handoff from day one. Code, evals, and runbooks belong in your repositories, and your engineers should pair on the work every sprint.
The pilot worked. The demo got nods in the steering committee, the outputs looked right on a few dozen hand-picked examples, and everyone agreed it should go live next quarter. Six months later it still runs in a sandbox, waiting on a security review, a data pipeline nobody owns, and an integration with the system of record that was never scoped.
That pattern is common enough to measure. In an S&P Global Market Intelligence survey reported by CIO Dive, the average organization scrapped 46% of AI proof-of-concepts before they reached production, and the share of companies abandoning most of their AI initiatives jumped to 42%, up from 17% the year before. Respondents named cost, data privacy, and security risks as the top obstacles.
None of those obstacles show up in a demo. They show up when the system meets your real data, your access policies, and your release process. Forward deployed engineers are built for that moment: senior AI engineers who work inside your environment, alongside your people, until the system runs in production and your team can own it.
This guide covers how to work with forward deployed engineers to ship AI to production in four steps: preparing your team before they arrive, embedding them in the first sprints, promoting the pilot through production gates, and taking ownership when the engagement winds down.
What Is a Forward Deployed Engineer?
A forward deployed engineer (FDE) is a software engineer who works inside a customer's environment, on the customer's real problem, and stays with it until the solution runs in production. In AI work, that means a senior engineer who joins your standups, works in your repositories, sits with the people who do the work today, and ships the AI system through your own release process.
The role is most closely associated with Palantir, whose job posting for Forward Deployed Software Engineers describes engineers who work directly with customers, often on-site, to understand and solve their problems. AI companies picked up the model as their products moved into enterprise workflows, and a16z called the forward deployed engineer the hottest job in startups in 2025.
How is a forward deployed engineer different from a consultant, a dev shop, or staff augmentation?
Each model puts people on your AI project. They differ in who does the work, where it happens, and what you are left holding at the end.
| Model | Who does the work | Where the work happens | What you have at the end | Where AI pilots tend to stall |
|---|---|---|---|---|
| Strategy consultancy | Advisors and analysts | Workshops and interviews | A roadmap and a business case | Nobody is accountable for building it |
| Dev shop or outsourced build | Engineers working from a spec | The vendor's environment | Code built to the spec | Business context gets lost in requirements, and integration happens late |
| Staff augmentation | Individual contractors you direct | Your environment | Extra capacity | You still supply the AI architecture, the evals, and the production plan |
| Forward deployed engineers | Senior AI engineers embedded with your subject matter experts | Your repos, tools, and release process | A production system, its evals, and a team that can run it | Ownership, if the handoff is not planned from day one |
Tip: Our methodology page lays out why most AI initiatives stall, from roadmaps without execution to pilots that do not scale, and how PressW keeps strategy and engineering under one roof.
Why Do AI Pilots Stall Before Production?
A pilot answers one question: can this work? Production asks harder ones. Does it work on all of our data, inside our access rules, at a cost we accept, with someone on call when it breaks?
Most stalls trace back to one of six gaps. Each one is easier to close from inside your environment than from outside it.
| Stall point | What it looks like | How forward deployed engineers close it |
|---|---|---|
| Data reality | The pilot ran on a clean sample. Production data is messy, scattered, or locked in a system nobody connected | They work against your real data from the first sprint and surface quality problems early |
| Integration | The demo ran on uploaded files. The real workflow lives in the CRM, the ERP, or the document system | They build connectors in your stack, under your access policies |
| Security and compliance review | The review starts after the build and sends it back | Access, tooling, and security review come first, before the code |
| No definition of correct | Nobody can say whether the output is good enough to ship | They build an eval set of gold-standard examples alongside the system |
| Cost | Run costs were never modeled at production volume | Cost per task is measured and tuned before rollout |
| No owner | The pilot team moves on and nobody runs the system | Your engineers pair on the work and own the runbooks before handoff |
Outside builders help, with a condition attached. MIT research reported by Fortune found that buying from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded about one-third as often. A partnership only pays off if the system ends up in your hands, running in production. The four steps below are how you set it up that way.
Step 1: How Do You Prepare Your Team Before Forward Deployed Engineers Arrive?
Much of the time lost in an embedded engagement is lost before the first commit: waiting on laptops, VPN access, repository permissions, and a security questionnaire. Do this work before day one.
Pick one workflow and define what production means
Choose one workflow with a clear owner and a measurable output, such as a document triage queue, a monthly reconciliation, or first drafts of support responses. Then write one sentence that defines production for it: "The agent drafts a response for every inbound ticket in the queue, and the support lead approves each one in the existing tool." That sentence becomes the target for every sprint.
Clear access and security review in advance
List the systems the engineers need, the data they will touch, and the approval each one requires. Start your security team's review before the engagement begins. PressW engagements start with access, tooling, and security reviews so that engineers are working in your repos within the first sprint.
Name two owners
A business owner decides whether the output is good enough. A technical owner on your team will run the system after launch. Name both before kickoff, and expect the technical owner to pair with the forward deployed engineers every week.
Book time with your subject matter experts
Forward deployed engineers learn the workflow from the people who do it. Put recurring time on those people's calendars for the first sprints. If the experts are too busy to meet, the project will stall on the same bottleneck the pilot did.
Step 2: How Should Forward Deployed Engineers Work Inside Your Team?
The value of forward deployment comes from proximity. Engineers who sit in your rituals and talk to your experts build around how the work actually happens, which is usually different from the process document.
Bring them into your rituals and your tools
Invite them to standups and sprint planning. Give them accounts in your ticketing system, your chat, and your code host. Their pull requests go through your code review, and their releases follow your release process. This keeps the system inside the controls your platform team already trusts.
Start with the people who do the work
The first week should include time watching the operator do the task: the claims processor, the controller, the analyst. Collect three or more real examples of a finished output. Those examples become the format the system targets and, later, the gold-standard cases you grade it against.
Ship a thin, end-to-end slice early
Aim for a rough version of the whole workflow running in a staging copy of your environment in the first sprints, before anyone polishes a demo on sample data. A thin slice exposes data, integration, and access problems while they are still cheap to fix.
Demo every sprint on real inputs
Sprint demos keep progress visible and let priorities shift when the business learns something. The business owner should see real outputs on real inputs, failures included.
Tip: See how PressW embeds senior AI engineers in your standups and your codebase on our Forward Deployed AI Engineering capability page.
Step 3: How Do You Move an AI Pilot to Production With Forward Deployed Engineers?
Promotion to production should be a decision with evidence behind it. Agree on the gates before the first sprint ends, and treat each one as a box the business owner and technical owner both sign.
| Production gate | Core question | Evidence before promotion | Common risk if skipped |
|---|---|---|---|
| Evals | Is the output correct often enough? | A pass rate on a gold-standard set that mirrors real inputs, edge cases included | Errors surface in front of customers or executives |
| Integration | Does it run on live systems? | End-to-end runs in staging against production-like data | The system works on uploads and fails on real feeds |
| Security and access | Can we defend what it touches? | Approved access scopes, logging, and a completed security review | The review blocks launch, or finds a problem after it |
| Monitoring | Will we know when quality drops? | Dashboards and alerts on errors, latency, eval drift, and cost | Quality degrades for weeks before anyone notices |
| Rollback | Can we turn it off safely? | A tested rollback path and a manual fallback | One bad release takes the workflow down |
| Cost | Can we afford it at full volume? | Cost per task measured at expected volume | The bill grows faster than the value |
| Runbook | Who responds when it breaks? | A runbook and an on-call owner on your team | Incidents land on the vendor, or on nobody |
Build evals from real work
Anthropic's guide to defining success criteria and building evaluations recommends criteria that are specific and measurable, and test sets that mirror your real task mix, edge cases included. The examples you collected in Step 2 are the start of that set. Add the cases the system got wrong in sprint demos, so every fix stays fixed.
Roll out in stages
Start with a small group of users, or run the system in shadow mode, where it produces output next to the person doing the work and nobody acts on it yet. Compare the two, fix the gaps, and widen the rollout when the evals hold.
Harden for operations
Production AI needs the same plumbing as any other service: CI/CD, logging, alerting, and a rollback path. It also needs a few things most services do not, like tracking eval pass rates over time and watching token spend per task. Build these in the stack your platform team already supports, so they can run them later.
Step 4: How Do You Take Ownership When the Engagement Winds Down?
The goal of a forward deployed engagement is a system your team runs without the engineers who built it. Plan for that from day one, because it changes how the system gets built.
| Artifact | Where it lives | Who owns it after handoff |
|---|---|---|
| Source code and configuration | Your repositories | Technical owner |
| Eval set and grading criteria | Your repositories, next to the code | Business owner approves changes, technical owner runs them |
| Prompts, agent instructions, and model settings | Version control | Technical owner |
| Runbooks and architecture decisions | Your documentation system | On-call team |
| Monitoring dashboards and alerts | Your observability stack | Platform or on-call team |
| Improvement backlog | Your ticketing system | Business owner sets priorities |
Transfer knowledge every sprint
A single handoff meeting at the end rarely works. Have your engineers pair with the forward deployed engineers on real tickets, review each other's code, and lead at least one feature from design to release before the engagement ends. PressW builds so your team can own the system: code, documentation, and evaluation harnesses live in your repos, and knowledge transfer happens every sprint.
Decide what support looks like after handoff
Some teams take the system over completely. Others keep a smaller ongoing arrangement for model upgrades, cost tuning, and new features. Decide which you want before the last sprint, so the backlog and the on-call rotation reflect it.
Tip: If your team needs to build skills before it takes over an AI system, our AI Training capability covers hands-on training tailored to each role.
How Do Strong Teams Get the Most From Forward Deployed Engineers?
Teams that get AI into production with forward deployed engineers prepare early, keep the experts involved, and gate releases on evidence. The ones that stall tend to hit the same few problems.
Common pitfalls
- Treating them as extra hands. Forward deployed engineers add the most when they own a production outcome. Assigning them a ticket queue turns them into staff augmentation.
- Starting before access is ready. Every week spent waiting on permissions is a week of the engagement spent idle.
- Keeping experts out of the room. Without the people who do the work, engineers build to the process document, and the system misses the steps nobody wrote down.
- Demoing on sample data. A polished demo on clean inputs repeats the pilot. Real inputs show what production will look like.
- Defining production at the end. If the gates are agreed after the build, every gate becomes a negotiation.
- No owner on your side. If nobody on your team is ready to run the system, the engagement either never ends or ends with an orphan.
Checklist for Evaluating Your Forward Deployed Engineering Engagement
Use this before kickoff and again before the engagement winds down.
- One workflow is chosen, with a one-sentence definition of production
- Access, tooling, and security review are complete or scheduled before day one
- A business owner and a technical owner are named
- Subject matter experts have recurring time blocked for the first sprints
- The engineers are in your standups, your tools, and your code review
- At least three real examples of finished output are on file
- Production gates are written down and agreed before the first sprint ends
- An eval set with a pass threshold exists and grows with every demo
- Monitoring, rollback, and a runbook are in place before rollout
- Code, evals, prompts, and runbooks live in repositories you control
Ship AI to Production With PressW Forward Deployed Engineers
Forward deployed engineers get AI out of the pilot stage when your team prepares the ground, puts them where the work happens, promotes on written gates, and plans the handoff from the start. Get those four right and production becomes a milestone you schedule.
PressW is an Official Anthropic Partner that embeds senior AI engineers directly with your team. Our forward deployed engineers join your standups, work in your codebase, and ship production AI systems with the code, documentation, and evals in your repos. For an AI-focused venture capital firm, we built a data room assistant integrated directly into the firm's FIS DX data room, estimated to save its fundraising team 60+ hours a month on LP questions. Read the data room case study or see how our Forward Deployed AI Engineering engagements work.
If you have a pilot that stalled, or one you want to keep from stalling, we will look at it with you and tell you what it needs to reach production. Book a Discovery Call.
FAQ
A forward deployed engineer works inside your environment to build and ship a system for your specific problem. In AI projects, forward deployed engineers join your team's rituals, work in your repositories, learn the workflow from the people who do it, and take the system through your release process into production. They also transfer the knowledge your team needs to run it.
Staff augmentation adds capacity that you direct, so your team still supplies the architecture, the evals, and the production plan. A forward deployed engineer brings that AI engineering depth and is accountable for a production outcome. The forward deployed model works best when the engineers own a defined workflow end to end.
The timeline depends mostly on how fast access is granted, how clean the data is, and how many systems the workflow touches. A single, well-scoped workflow with access cleared before day one moves much faster than one that waits on security review mid-build. Agreeing on production gates early also removes the long negotiation at the end.
Have one workflow chosen, a written definition of production, named business and technical owners, and access and security review underway. Block time for the subject matter experts who do the work today. Forward deployed engineers move fastest when they can start in your repos and talk to your experts in the first week.
At the end of a forward deployed engagement, your team should own the code, the eval set, the prompts, the runbooks, and the monitoring, all in systems you control. Your engineers should already have paired on the work and led a feature themselves. Some teams then keep a smaller ongoing arrangement for upgrades and tuning, and others run the system on their own.
