Why forward-deployed engineering
Every enterprise I work with has a model that works. The demo ran. The pilot scored well. Leadership saw it. And then months pass and nothing is in production, or something is in production and nobody will rely on it. The model works and the system does not, and the distance between those two states is where most enterprise AI spend goes to die.
In brief:
- A working model is not a running system. The distance between them is organisational before it is technical: workflow, data boundaries, evaluation, review and ownership.
- Advisory ends with a document and vendors end with a product. Neither is built to close that distance.
- Forward-deployed engineering closes it: an engineer inside the client's systems, writing the code, until the result runs and a named owner can keep it running.
Forward-deployed engineering is the practice built for that distance. The term comes from Palantir, which sent engineers into customers' operations to make its software do the customer's actual work rather than waiting for the customer to adapt to the software. The method generalises. For AI it means an engineer inside the client's environment, close to the real workflow, who finds the problem, designs the architecture around the client's data and systems, builds in evaluation and review from the start, and stays until the result runs and a named person can keep it running.
On the left, a working model in a demo. On the right, a running system in the operating workflow. Between them, the gap: data access, integration boundaries, evaluation, review controls, ownership, handover. The forward-deployed engineer works inside the gap.
What lives in the gap
The gap is not technical difficulty in the usual sense. The hard model work was done by a lab. What lives in the gap is specific to the organisation, and it has to be done inside it.
The real workflow is not the one in the slide. The use case was described by someone who does not do the work. The person who does it has exceptions, workarounds and a second system the slide never mentioned. Finding the real workflow is the first job, and in my experience it is rarely done well from a distance: the exceptions come out when you sit beside the person and watch, not when you ask.
The data is where the systems are, not where the demo was. The pilot ran on an export. The system has to run on the live source, with its access controls, its latency, its missing fields and its two definitions of "customer". Most pilots cannot cross this boundary because nobody with the authority to open it was in the room.
Evaluation was never designed. The pilot was judged by whether the output looked right. Production needs a written definition of right, a set of real cases with the correct outcome recorded, and a way of knowing when the system has drifted. That is a design task, and it has to come before the build.
Review was bolted on. Human review was added at the end as a safety net, so everything goes to a person and the system saves no one any time. Review designed in at the start goes where the confidence is low, and nowhere else.
Nobody owns it. The pilot was a project. A running system is an operation, with a named owner, a runbook and someone who will be called when it misbehaves. If that person does not exist on the day the engagement ends, the system tends to stop running within a few months, usually at the first upstream change nobody was watching for.
Why the usual models stop short
Two kinds of help are normally on offer, and both stop at the edge of the gap for structural reasons.
Advisory ends with a document. A good advisory engagement produces a recommendation, and I run one myself: the AI Delivery Readiness Review ends with a written readout, and sometimes the recommendation is to pause. But a recommendation is not a running system, and the people who wrote it are not there when the integration fails at two in the morning.
Vendors end with a product. The platform works as designed; the problem is that the design did not include your order system. A vendor's engineer is optimising for the product's success across many customers. The forward-deployed engineer is optimising for one system running in one organisation.
Neither is wrong. They are simply not built to close the gap, and the organisations that assume one of them will are usually the ones I meet a year later, with the pilot still in a slide.
What the forward-deployed engineer does
The role is defined by where the work happens and when it ends, not by a job title.
Inside the client's environment. On the client's systems, with the client's data, alongside the client's engineers. Not in a lab building something to be handed over.
On one bounded use case. Scope, responsibilities and acceptance criteria are written down before the build starts. Breadth is the enemy; a single workflow running in production is worth more than five in pilot.
Writing the code. The forward-deployed engineer is not a diagrams-only architect. I write the code and the evaluation harness myself, because the architecture decisions that matter are the ones you discover when the integration does not behave as documented.
With responsible AI built in, not added later. Evaluation, human review and data boundaries are designed before the first prompt is written. They are part of the architecture, not a compliance step afterwards.
Until it runs, and then handing it over. The engagement ends with working software, evaluation results against agreed tests, a runbook, and a named owner who has operated the system before the engineer leaves. The handover note is a deliverable, not a courtesy.
One engagement, in outline
An example makes the gap concrete. For one of India's largest two-wheeler manufacturers I designed the AI system behind its dealer and customer operations. The brief as it arrived was an AI-led buying experience for customers. The work that made it possible was mostly in the gap: deciding, with the client, which models would run locally and which through API model gardens, given where the data could and could not go; modelling the historical data properly before anything predictive was built on it, so that the analytics product produced signals the business could act on rather than charts; integrating a custom model into the enterprise platform rather than beside it; and running the whole build through specification-driven development so that every piece had written acceptance criteria before it was made. I am not going to attach numbers to it here, because the ones that matter belong to the client, but the shape is the point: the model was the smallest part of the system, and the system is what ran.
The four situations
In practice I am called into four recurring situations, and each is a different face of the same gap.
- The pilot works, but nobody knows how it fits the operating workflow. The work is to clarify ownership, system boundaries, evaluation and the conditions for deployment. Often the answer is a smaller system than the pilot promised, running where the pilot never could.
- The architecture debate began before the business decision was clear. Model versus model, platform versus platform, while nobody has written down the outcome that matters. The work is to establish the outcome, the constraints and the evidence first, and only then make the technology choices.
- Prototypes cannot cross enterprise data and integration boundaries. The work is to design retrieval, agents, APIs and review controls around the real security and legacy-system constraints, which usually means getting the right people to open the right doors.
- The engineers know the tools but cannot yet own delivery in a client context. The work here is not a system but a capability: building forward-deployed engineers through realistic scenarios, applied labs, architecture defence and operational handover. This is the part of my practice that has become the FDE cohort.
Key point: The forward-deployed engineer is defined by where the work happens and when it ends, not by a job title. Inside the client's systems; until it runs; then hand it over.
What shaped this approach
I did not arrive at forward-deployed engineering through Palantir. I arrived at it through twenty-six years of engineering, most of it enterprise systems before any of it was AI, and through watching the same thing happen to AI projects that used to happen to integration projects: the technology worked in isolation and the organisation could not absorb it. Three kinds of work taught me the specific lessons on this page.
Building inside the client's systems. The two-wheeler engagement above, AI automation on top of an infrastructure company's SAP processes, machine learning for a bank's credit-card operations, predictive models and virtual-reality applications for Whirlpool and Zeiss in Italy and Switzerland. In every one of them the model was the easy part and the system boundary was the work. That is where the rule "evaluation and data boundaries written down before the build starts" comes from: each time they were not, the build stalled at the boundary.
Building forward-deployed teams for a services firm. With Tredence, the work went beyond upskilling into designing how its deployed engineers would actually operate inside clients: the capability programme on Google Cloud, the platform that ran its residential cohort, and the delivery processes around them. That is where I learned that the method has to be taught as judgement under realistic conditions, not as tools, which became the four gates and the five artefacts in the Framework.
Training more than three thousand engineers. Across India, Singapore and the Gulf, including teams at three Fortune 500 companies. The pattern I kept meeting was engineers who knew the tools well and could not yet own delivery in a client's context. That gap, not a knowledge gap, is what the FDE cohort is built to close, and it is why I assess what people produce rather than what they attended.
Where I would be honest about the limits: the method is mine, the four situations are a distillation of what I keep meeting, and I have not run a controlled comparison of forward-deployed delivery against the alternatives. The evidence I have is engagements that ran and systems that stayed running, with named owners. The checklist for companies is the closest thing to a reproducible instrument I can offer, and I will publish a comparison of engagements that held against ones that did not, unnamed, when I have enough of them to say something defensible.
Why it is worth it
The objection I hear is cost. An engineer inside your organisation for weeks is more expensive than a licence or a report. The arithmetic I put back is this: the pilot already cost you, the licence is already running, and neither is producing anything. The forward-deployed engagement is the only one of the three whose price buys a running system and a team that can keep it running. It is also the only one that ends. Advisory tends to become a retainer and a platform becomes a subscription; a forward-deployed engagement has a defined output and an end date, and if the right answer turns out to be "pause", that is what the readout says.
Sometimes the right advice is to pause the pilot. Sometimes the right advice is to build the system. In both cases the work has to happen inside the organisation, by someone who writes the code and stays until it runs. That is why forward-deployed engineering, and it is why I do it this way.
The method is written up in full on the Framework page, and the questions to ask before you build a forward-deployed team of your own are in the checklist for companies.
Common questions
What is a forward-deployed engineer?
An engineer who works inside the customer's environment, close to the problem, rather than building a product at a distance and handing it over. For AI, the forward-deployed engineer finds the real workflow, designs the architecture around the client's data and systems, builds in evaluation and human review from the start, and stays until the system runs and a named person can operate it.
How is forward-deployed engineering different from consulting?
Consulting usually ends with a recommendation, and a good readiness review should. Forward-deployed engineering goes on to the running system: the code, the evaluation results, the runbook and a team that can own it. The engagement ends when the system runs, not when the document is delivered.
How long does a forward-deployed engagement take?
It is scoped to one bounded use case with written acceptance criteria and an end date. A readiness review is two weeks; an architecture sprint two to four; a delivery engagement is scoped per use case and paid by milestone. Breadth is the enemy: one workflow in production is worth more than five in pilot.
What does the client keep at the end?
Working software inside their own systems, evaluation results against agreed tests, the recorded architecture decisions, a runbook, and a named owner who has operated the system before the engineer leaves. The model is a configuration value; the harness, the definitions and the evaluation set are what the organisation accumulates.