Home / How I Can Help / Forward Deployed Engineering
Service · Embedded delivery
Forward deployed engineering for agentic AI
A forward deployed engineer works inside your environment, on your data and your constraints, and stays accountable after go-live. The label is new. The operating model is what has always been required to get this work into production.
Between May and July 2026, four of the largest AI companies committed roughly nine billion dollars to variations of the same idea: put your own engineers inside the customer. Anthropic, OpenAI, AWS and Microsoft all reached for it inside a nine-week window. The model itself was pioneered at Palantir in the early 2010s, where forward deployed engineers outnumbered regular software engineers for years.
What the money is admitting is that a capable model and an API do not become a working system on their own. Somebody has to fit the thing to your actual data, your permissions model, your workflow exceptions and your definition of done, and that fitting is done best by an engineer sitting inside the operation rather than writing recommendations from outside it.
The part that separates this from consulting is simple. A consultant produces a document. A forward deployed engineer produces production code in your environment and is still accountable when it runs. I did this work for a decade before the industry gave it a name.
This is for you if
- → You have bought or built agentic AI capability and it has not turned into a working system.
- → Your data, permissions and workflow exceptions are the hard part, and no external team has been willing to get into them.
- → You need somebody who will write code in your repo, not produce an assessment of your repo.
- → You want the engagement to end with your team self-sufficient, and you want that written into the scope.
Where I am not the right fit
- × You want staff augmentation, or a body to fill a headcount gap. This is outcome work with a defined end.
- × You cannot give an external engineer access to a realistic environment. Without that this model has no advantage over any other.
- × You want the engineer embedded indefinitely. The exit is part of the design, and I will keep raising it.
- × The problem is organizational rather than technical. Embedding one engineer does not fix a decision nobody will make.
- 01
Get inside the workflow
Not the process diagram, the actual workflow. Where the decisions are, where the exceptions go, which handoffs are informal, and which step everyone routes around. This is where the agent boundary comes from.
- 02
Work on your real data
Real records, real permissions, real edge cases, in a realistic environment. A system proven on sample data has proven almost nothing, and the gap between the two is where most pilots die.
- 03
Ship production code in your repo
Your stack, your standards, your review process. Evaluation, cost ceilings, security boundaries and observability built in from the start, because retrofitting them is how a pilot becomes permanently a pilot.
- 04
Own it through go-live
A named owner for the outcome after the system is live, not just until handover. Runbooks, the escalation path, and the on-call rotation that answers when it misbehaves at an inconvenient hour.
- 05
Leave properly
An explicit self-sufficiency exit: your engineers own the system, understand the decisions behind it, and can change it without me. If maintenance is wanted afterwards it is a separate, clean contract.
- → Production code in your repository, on your stack, passing your review process.
- → A system validated on your real data and permissions, not a sample set.
- → Evaluation built from your own cases, with the answer key reviewed by a person.
- → Cost ceilings, security boundaries and observability designed in rather than added after the first incident.
- → A named outcome owner after go-live, with runbooks and a defined escalation path.
- → A written self-sufficiency exit, so the engagement ends with your team able to carry it.
Forward Deployed Engineering: Why Agentic AI Doesn't Ship Itself
The long version of why roughly nine billion dollars went into this model in nine weeks.
Read it → ArticleThe AI Agent Production Readiness Checklist
The gates an embedded engagement is aiming at, and which four cannot be compensated for.
Read it → ArticleWhat an AI Agent Actually Costs Per Resolved Customer Issue
What the business case looks like once you count all of it and divide by the right outcome.
Read it →Frequently asked
Quick answers
- What is a forward deployed engineer?
- An engineer who embeds inside a customer organization to design, build, deploy and operate a production system on the customer own infrastructure, rather than selling a tool and leaving the customer to integrate it. The role was created at Palantir in the early 2010s. The defining feature is that a forward deployed engineer ships real production code in the customer environment and owns the outcome after go-live, which is what separates the role from a consultant who produces recommendations.
- How is this different from consulting or staff augmentation?
- A consultant produces documents and recommendations. Staff augmentation fills a seat and takes direction. Forward deployed engineering produces working software inside your environment and stays accountable for whether it works once it is live. In practice that means you get code in your repo, a named owner for the outcome, and an engagement that is scoped to end rather than to continue.
- Do you work on site or remotely?
- Remotely by default, which is how most of this work is done now, with the embedding being about access and involvement rather than geography. What actually matters is being inside your systems, in your team channels, in the standups, and looking at the real data. If a specific engagement genuinely needs time on site, that is a conversation rather than a policy.
- How long does an embedded engagement last?
- Long enough to land a working system and short enough that the exit stays in view. Every engagement is scoped in writing with a fixed deliverable and a defined end, because open-ended embedding is how an external engineer becomes load-bearing infrastructure. If maintenance is wanted after the exit it runs as a separate, clean continuation contract.
Start a conversation
Bring the problem nobody has been willing to get inside.
A 30-minute call. Tell me what is built, what it touches, and where it stops working. If there is a fit we will scope it tightly in writing, with the exit defined from the start.