Why Your AI Initiative Needs an Embedded Engineer, Not Another Roadmap
Why the forward-deployed model succeeds where pilots fail
Published July 19, 2026 · Last updated July 19, 2026
Freshness note: Reflects the 2026 wave of forward-deployed engineering investments by Amazon, Anthropic, and OpenAI.
By Roy Gatling (RMG Associates)
Most enterprise AI initiatives fail because they are built at a distance from the work they are meant to change. A forward-deployed engineer (FDE), embedded inside your team and building against your real data and workflows, closes that distance. It is the single highest-leverage intervention for getting a stalled AI effort into production.
Why do enterprise AI pilots stall?
Enterprise AI pilots stall because of deployment, not model quality. Gartner projects that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. None of those causes is a model limitation. All three are symptoms of building outside the workflow.
The stalled initiatives we encounter share one structure: the people specifying the system are rarely the people doing the work, and the people building it are rarely in the room at all. Requirements pass from operator to analyst to project manager to vendor and back, losing fidelity at every handoff. What comes out the other side is polished, demos well, and dies on contact with the actual workflow: the broken data feed nobody mentioned, the approval step that lives in someone's inbox, the exception path that occurs 30% of the time but appeared in no requirements document.
The problem is not employee resistance. Your people are already using consumer AI tools on their own initiative. The problem is that official initiatives are structured as software procurement when AI adoption is actually workflow change, and workflow change cannot be specified from a conference room.
What is a forward-deployed engineer?
A forward-deployed engineer is a senior engineer embedded directly inside a client organization for weeks or months. They sit with the teams doing the work, learn the domain firsthand, and ship production software against the client's real data and constraints. The role originated at Palantir and is now the dominant enterprise AI deployment model.
The mechanism is simple: the FDE collapses the translation loop. Instead of handoffs, they watch the actual workflow, build a working version against the messy data that actually exists, put it in front of users the same week, and iterate on real feedback rather than a requirements document. They build under real constraints rather than imagined ones.
The market has now voted decisively on this model. In 2026, Amazon announced a $1 billion investment to expand its use of forward-deployed engineers to accelerate enterprise adoption of AWS AI services. Within the same year, Anthropic disclosed a $1.5 billion enterprise-services venture to embed Claude into mid-market companies, and OpenAI launched its $4 billion Deployment Company, putting 150 engineers into client operations from day one. The companies that build the models have concluded that the bottleneck in enterprise AI is integration, security, and workflow redesign rather than model performance itself, and they are allocating billions accordingly. When the labs themselves buy the embedded model, the argument is largely settled.
How does the FDE model compare to the alternatives?
An FDE engagement outperforms internal builds and traditional consulting on the dimension that decides success: proximity to the real workflow. Internal teams have proximity but usually lack AI implementation depth. Traditional consultants have depth but deliver recommendations rather than running software. The FDE combines both and is accountable for production.
| Criterion | Internal build | Traditional consultancy | Forward-deployed engineer |
|---|---|---|---|
| Distance from real workflow | Low | High | Low |
| AI implementation depth | Varies, usually thin | Medium | High |
| Deliverable | Tool (often stalls) | Deck or roadmap | Running production software |
| Time to first working version | Months | N/A (advisory) | Days to weeks |
| Cost profile | Salaries plus learning curve on company time | High fees, no execution | Premium rate, finite engagement |
| Main risk | Slow iteration, abandoned mid-build | Nothing ships | Dependency if handoff is not planned |
What should a CEO do with a stalled AI initiative in the next 30 days?
Stop funding the pilot as designed and restructure it around embedded delivery. Pick one workflow with clear economic value, put an engineer (internal or external) physically or virtually inside that team, and require a working version in production use within 30 days. Scope down until that is achievable.
Three tests tell you whether your current effort will make it:
The proximity test
Has the person writing the code watched the person doing the work do the work? If not, you are building from assumptions, and the assumptions are wrong in ways you will discover late.
The learning test
Does the tool retain feedback and improve, or does every user correction evaporate? A system with no memory of its mistakes will be abandoned by month three.
The handoff test
Is there a written plan for your team to own the system after the engagement? An FDE model done right transfers capability. Done wrong, it becomes permanent staff augmentation. Insist on the former.
In our work with businesses, the fastest recoveries came from narrowing a sprawling initiative to a single workflow and embedding directly with the team that owns it. First production use typically lands in two to four weeks, and that early win funds the political capital for everything after it.
The labor intensity of the model is real, and it is also the point. The expensive part of enterprise AI was never the software. It was the organizational distance between the model and the work. Pay to close that distance once, deliberately, and the rest of the roadmap gets cheaper.
Related articles
Executive FAQ
Frequently asked questions about embedded engineers and stalled AI pilots.
Why do enterprise AI pilots stall?
Enterprise AI pilots stall because of deployment, not model quality. Gartner projects that over 40% of agentic AI projects will be cancelled by end of 2027, citing escalating costs, unclear business value, and inadequate risk controls — all symptoms of building outside the workflow. Requirements lose fidelity across handoffs from operator to analyst to vendor, producing polished demos that die on contact with broken data feeds, inbox approval steps, and exception paths that occur 30% of the time but appeared in no requirements document.
What is a forward-deployed engineer?
A forward-deployed engineer (FDE) is a senior engineer embedded directly inside a client organization for weeks or months. They sit with teams doing the work, learn the domain firsthand, and ship production software against the client's real data and constraints. The role originated at Palantir and collapses the translation loop: watch the actual workflow, build against messy data, put working software in front of users the same week, and iterate on real feedback rather than a requirements document.
How does the FDE model compare to the alternatives?
An FDE engagement outperforms internal builds and traditional consulting on proximity to the real workflow — the dimension that decides success. Internal teams have proximity but usually lack AI implementation depth. Traditional consultants have depth but deliver recommendations rather than running software. The FDE combines both and is accountable for production: days-to-weeks time to first working version versus months for internal builds or decks from advisory firms.
What should a CEO do with a stalled AI initiative in the next 30 days?
Stop funding the pilot as designed and restructure it around embedded delivery. Pick one workflow with clear economic value, put an engineer physically or virtually inside that team, and require a working version in production use within 30 days — scope down until that is achievable. Apply three tests: proximity (has the coder watched the operator?), learning (does the tool retain feedback?), and handoff (is there a plan for your team to own the system after the engagement?).
Ready to move from pilot to production?
RMG embeds forward-deployed engineers inside mid-market teams to ship production AI against real workflows — not another roadmap.
Learn About Forward Deployed EngineeringFeatured guide
Start with where most AI programs actually break down
Why Your AI Transformation Is Being Overcomplicated (And How to Fix the Partner Problem) — the operating logic for picking partners and pacing transformation so execution matches mid-market realities.
Read the flagship guide