---
title: "How to scope a forward deployed engineering engagement"
description: "Eight contract steps for a forward deployed engineering engagement - outcome, access, ownership, shadow, platform, checks, price and exit. With a checklist."
type: Playbook
url: https://sunilkumar.ai/playbooks/how-to-scope-a-forward-deployed-engineering-engagement/
author: Sunil Kumar (https://sunilkumar.ai/about/)
datePublished: 2026-09-23
lastReviewed: 2026-09-23
version: "1.0"
pillar: Governance and risk
tags: [forward-deployed-engineering, vendor-management, procurement, governance, delivery]
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
---

# How to scope a forward deployed engineering engagement

Eight contract steps for a forward deployed engineering engagement - outcome, access, ownership, shadow, platform, checks, price and exit. With a checklist.

## In short

- A forward deployed engineering engagement is a contract for finishing the product in your environment. Scope it as one, with the outcome, the artefacts, the access, the ownership and the exit date in writing before the first engineer arrives.
- Gartner's controls for the model, outcome-based SLAs, IP ownership, a shadow engineer, composable architecture and an exit plan on day one, belong in the price, not in an annex.
- The vendor is trading margin for moat, and the moat is your dependency. Every clause that keeps the artefacts and the knowledge on your side is a clause the vendor's investors would rather you did not write.
- Score the engagement from 0 to 3 on eight questions. Anything under 2 on ownership or exit is a rental, whatever the title on the badge.
- MIT found that tools bought from outside reached deployment about twice as often as tools built inside, 66 percent against 33 percent. The point of this playbook is to keep that upside and remove the geometry risk.

## Steps

1. **Write the outcome as three artefacts before the price** An evaluation set with an agreed pass rate, a refusal list enforced in code, and a budget per run and per month. The price comes after these, never before.
2. **Decide the access before the badge** Least privilege, a written list of the data the engineer may touch, an exception log, and one sanctioned platform for anything they build.
3. **Settle ownership of every artefact** Prompts, workflows, connectors, evaluation set, data model and runbook are yours, in a form your own team can run. Gartner suggests at least 70 percent; ask for all of it.
4. **Name your shadow, and give them the refusal list** One engineer of yours beside every engineer of theirs, owning the refusal list and the evaluation cases rather than watching.
5. **Build on your platform, behind swappable interfaces** Standard model APIs, refusals in the tool layer, and a model change that is tested by re-running the evaluation set rather than by rewriting code.
6. **Put a second check on the agent's output** A checking agent on every run, a named human approver for anything irreversible, and a trace your compliance team can read without the vendor.
7. **Price the outcome, not the presence** A fixed price for the outcome, with time and materials only for the two-week definition phase, and a renewal that does not depend on the engineer staying.
8. **Write the exit on day one** A date and a condition, both in the contract; a handover of the artefacts as scope, not as support; and your own named owner ready to inherit.

Every AI platform now comes with an offer of engineers. The frontier labs, the data platforms and the large system integrators all sell some version of the same thing: their people, inside your building, until the agent runs. Gartner's March 2026 guide to the model lists the controls a good engagement needs. This playbook turns those controls into eight steps you can put in a contract, a scorecard for the negotiation, and a checklist you can send to the vendor before the first meeting.

I have written about [why the model exists](/writing/forward-deployed-engineers-are-a-symptom/) and [what a forward deployed engineer is](/ideas/forward-deployed-engineer/). This is the practical part. If you already know you are going to say yes, this is how to say yes.

> **Forward deployed engineering engagement**: A contract under which a vendor's engineers work inside your environment to take a product, usually an AI agent, from a signed deal to a running process, measured on the outcome and on your adoption of the vendor's platform rather than on hours.

The principle behind all eight steps is one sentence: say yes to the engineers and no to the geometry. The engineers are usually excellent. The geometry, a person paid by the vendor holding your production credentials and the only understanding of what was built, is what every risk in the model follows from. Each step below moves one piece of the work, the knowledge or the ownership back to your side of the line.

## Step 1. Write the outcome as three artefacts before the price

Gartner's first prescription is an outcome-based SLA measured at the business level rather than at the model or feature level. That is right, and it is too abstract to sign. An outcome becomes signable when it is written as three artefacts.

The evaluation set: a fixed collection of real cases from your operation, with the expected outcome for each, including the cases where the right outcome is a refusal or an escalation, and an agreed pass rate. The refusal list: the actions the agent must never take and the requests it must decline, enforced in code rather than in a prompt. The budget: the cost per run and the ceiling per month, with the behaviour at the ceiling written down.

Those three documents are the SLA. They are also the first two weeks of the engagement, and they should be the only part of it that is bought by the day. A vendor who quotes an outcome before the artefacts exist is guessing, and the guess is priced in your favour only by accident. The [vendor evaluation playbook](/playbooks/how-to-evaluate-an-agentic-ai-vendor/) has the questions to ask about each artefact; this step is about getting them into the contract.


- [ ] Evaluation set from your real cases, with refusals and escalations in it, and a pass rate agreed in writing.
- [ ] Refusal list enforced at the tool layer, with reason codes and a human path for a wrong refusal.
- [ ] Cost per run and monthly ceiling, with the behaviour at the ceiling implemented, not described.
- [ ] The definition phase priced by the day; everything after it priced against the artefacts.


## Step 2. Decide the access before the badge

A forward deployed engineer needs deep access to be useful, and Gartner is blunt about the consequences. Privileged access to production and to sensitive data. Compliance drift, when someone circumvents your procurement or security process to move fast. And the risk that nobody can say afterwards who owns the code that was written. The fix is boring and it works: decide the access before the person arrives, and write it down.

Least privilege, per system, with the list of data the engineer may read and write attached to the contract. An exception process with a named approver on your side and a log, so that "we needed it to make the demo work" becomes a recorded decision rather than a habit. And one sanctioned platform for everything they build, so that every agent, prompt and connector is discoverable and auditable by your own team. Gartner calls the alternative shadow AI. I call it the thing your auditor finds in month nine.

One more clause that costs nothing: the vendor's engineer works under your security controls, not theirs. Your identity provider, your secrets store, your logging. If the vendor's tooling needs its own credentials to your systems, those credentials are yours to issue and yours to revoke, and the revocation is tested before the engagement starts, not on the day it ends.


- [ ] Access list per system, least privilege, attached to the contract.
- [ ] Exception process with a named approver on your side and a written log.
- [ ] One sanctioned platform for anything the engineer builds; nothing outside it.
- [ ] Credentials issued and revoked by you, with revocation tested on day one.


## Step 3. Settle ownership of every artefact

Gartner's rule of thumb is that at least 70 percent of the code and integration patterns a forward deployed engineer produces should go back into your own platform rather than stay as a one-off script. I have never seen a good reason for the other 30 percent, and I would ask for all of it. The list of artefacts is longer than most contracts admit: the prompts, the workflows, the connectors, the evaluation set, the refusal list, the runbook, and the data model with the meaning of your fields. Gartner calls that last one the ontology layer. It is the artefact most often left inside the vendor's platform, where only the vendor can change it.

Ownership has a second half that the word "IP" hides. It is not enough to own the artefacts; you need them in a form your own team can run. A workflow that exists only as configuration inside the vendor's product is yours on paper and theirs in practice. So the clause is two sentences: every artefact is the client's, and every artefact is delivered in a format the client's engineers can read, edit and deploy without the vendor's tooling.

This is the step where the vendor's incentives show. In June 2025 Andreessen Horowitz told founders to trade margin for moat: to accept the cost of forward deployed engineers because the customisation they do becomes a durable advantage, the way it did for Salesforce and ServiceNow before their margins recovered. Read from your side of the table, the moat is your dependency. A vendor who resists this step is not being difficult; they are following investor advice. Write the clause anyway.


- [ ] Every artefact named in the contract: prompts, workflows, connectors, evaluation set, refusal list, runbook, data model.
- [ ] All of them the client's, not 70 percent.
- [ ] Delivered in a format your engineers can run without the vendor's tooling.
- [ ] The data model and field definitions co-owned and exportable from day one.


## Step 4. Name your shadow, and give them the refusal list

Gartner's answer to talent atrophy is a shadow engineer: for every vendor engineer, one of yours, working beside them so that the knowledge is being built on your payroll while the work is done. That is necessary and it is not sufficient. A shadow who watches learns what was built. A shadow who owns something learns why.

So give the shadow the two artefacts that decide whether the agent is allowed to run. They own the refusal list: they write it with your risk and compliance people, they approve every change to it, and the vendor's engineer implements it. They label the evaluation cases, because only your people know what a correct answer looks like in your operation. By the end of the engagement the person who can say what the agent may do and the person who can prove whether it does are both employees of yours, and the vendor's engineer has been their implementer rather than their oracle.

Make the knowledge transfer measurable, because "knowledge transfer" is the phrase that appears in every statement of work and is measured in none. Gartner suggests counting the internal people certified on the system. I would add two more: the number of changes to the agent that your shadow has shipped without the vendor, and the number of weeks the shadow has spent at least a third of their time on the engagement. If the third number is zero, the first two will be too.


- [ ] One named shadow per vendor engineer, at least a third of their week, from week one.
- [ ] The shadow owns the refusal list and approves every change to it.
- [ ] The shadow labels the evaluation cases and signs the pass rate.
- [ ] Knowledge transfer measured: certified people, changes shipped without the vendor, shadow weeks.


## Step 5. Build on your platform, behind swappable interfaces

Gartner's most interesting warning is about maintainability. A forward deployed engineer's work is mostly hand-coded domain knowledge, and hand-coded domain knowledge is the part of any AI system that the next generation of models tends to make redundant. What was clever integration work in one year is a feature of the model in the next, and the client is left with a codebase that has to be reworked or thrown away.

The protection is composable architecture, which sounds like an engineering preference and is actually a commercial one. Standard model APIs, so that the model can be swapped when the price or the quality moves. Refusals enforced in the tool layer, so they survive a model change untouched. The workflow and the refusal list kept as the two hand-written things you would want to survive anyway, and everything else kept thin. Then the test of whether a model change is safe is mechanical: swap the model, re-run the evaluation set from step one, read the pass rate. If a model change needs a rewrite, the architecture was the vendor's, not yours.

The [reference architecture](/playbooks/agentic-ai-reference-architecture-for-enterprise/) sets out the layers. For the contract, one clause does most of the work: the agent must pass its evaluation set on at least two models from different providers before handover.


- [ ] Standard model APIs; no code that only works with one provider's model.
- [ ] Refusals in the tool layer, not in the prompt.
- [ ] Model change tested by re-running the evaluation set, and the result recorded.
- [ ] Handover condition: the set passes on two models from different providers.


## Step 6. Put a second check on the agent's output

Gartner recommends that forward deployed engineers deploy guardian agents, a second model that checks the primary agent's output for hallucination and bias, so that a human does not have to read every result. I agree, with one addition that matters more than the guardian: a named human approver for anything irreversible. A second model can catch a wrong answer. It cannot take responsibility for a payment, a deletion or a message to a customer, and someone in your organisation has to.

Those two checks, plus a trace of every run, are three of the four tests in [Agentic in Production](/ideas/agentic-in-production/). The fourth is the budget from step one. Write all four into the engagement as acceptance criteria rather than as good practice. The agent is not accepted until the checking agent runs on every case in the evaluation set, the approver's step exists in the workflow for every irreversible action, and your compliance team has opened a trace on their own screen without the vendor in the room.


- [ ] A checking agent on every run, with its verdicts in the trace.
- [ ] A named approver on your side for every irreversible action, in the workflow, not in a policy document.
- [ ] Traces readable by your compliance team without the vendor's help, with retention set by your regulator.
- [ ] Guardrail failure rate measured on the evaluation set and reported at handover.


## Step 7. Price the outcome, not the presence

Most forward deployed engineering is sold by the day or bundled into a platform subscription, and both shapes have the same flaw: the vendor is paid whether the agent runs or not. Gartner's phrase for the alternative is results as a service, value measured by observable business actions rather than by model performance. In a contract, that is a fixed price for the outcome defined in step one, with the definition phase as the only part bought by the day.

Fixed price changes the vendor's behaviour in ways that no clause can. A vendor on a day rate has no reason to finish. A vendor on a fixed price has every reason to define the outcome precisely, keep the unit of work small, and leave. That is the argument in [fixed price for agentic AI](/writing/fixed-price-for-agentic-ai-how-pods-make-it-possible/), and it applies with more force here because the engineer is inside your building and the meter is running in your budget.

Watch the renewal too. In the vendors I meet, forward deployed engineers increasingly report into post-sales, which means the engineer in your building is measured on whether you renew the platform. That is not sinister, but it is a conflict, and the contract should not make the renewal depend on the engineer staying. If the agent passes its evaluation set inside its budget and your people can run it, the renewal is a decision about the platform, not about the person.


- [ ] Definition phase by the day, two weeks, ending in the three artefacts.
- [ ] Outcome at a fixed price, quoted after the artefacts exist.
- [ ] Payment tied to the pass rate, the budget and the handover, not to days present.
- [ ] Platform renewal independent of the engineer's continued presence.


## Step 8. Write the exit on day one

Gartner's last control is the one most engagements skip: an exit plan defined before the engagement starts, both value-bound and time-bound. Without it, the note says, forward deployed engineers quietly become permanent staff augmentation. Since 2017 I have watched this happen from both sides of the table, and it never happens by decision. It happens because nobody wrote the date.

The exit has two parts. The condition: the agent passes the evaluation set at the agreed rate, inside the budget, with the refusals enforced; the checking agent and the approver step are live; your shadow has shipped changes without the vendor; and every artefact from step three is in your hands in a form you can run. The date: the day the engineer leaves whether or not the condition is met, with what happens next written down. Usually that is a second, smaller definition phase and a new fixed price, which is honest; what it must not be is an automatic extension at the day rate.

Then the handover is scope, not support. The runbook, the kill switch, the evaluation set, the refusal list and the trace tooling go to a named owner on your side, who has operated the kill switch during the engagement and not for the first time on the last day. Gartner expects the internal forward deployed engineer, an engineer on your payroll who bridges IT and a business unit, to be the shape of enterprise AI teams in regulated industries. The exit is where that person is made. If you have not got one, the engagement is the cheapest place to grow one, provided the shadow from step four was real.


- [ ] Exit condition written: pass rate, budget, refusals, checks live, shadow independent, artefacts delivered.
- [ ] Exit date written, with the consequence of missing the condition (a new definition phase, never an automatic extension).
- [ ] Handover of runbook, kill switch, evaluation set, refusal list and traces as scope, to a named owner.
- [ ] The owner has operated the kill switch before the last day.


## The scorecard

Score each step from 0 to 3 in the negotiation: 0 for not in the contract, 1 for a promise or a policy document, 2 for a clause, 3 for a clause with a test you can run. Add the eight scores.

| Step | What a 3 looks like | Disqualifier |
| --- | --- | --- |
| 1. Outcome | Three artefacts named, with the pass rate and the budget as numbers | A price quoted before the artefacts exist |
| 2. Access | Access list per system attached, revocation tested | "Standard vendor access" |
| 3. Ownership | Every artefact yours, delivered in a form you can run | A percentage, or "configuration remains the vendor's" |
| 4. Shadow | Named, a third of their week, owns the refusal list | "Knowledge transfer sessions at the end" |
| 5. Platform | Evaluation set passes on two models from different providers | Code that only runs on the vendor's model |
| 6. Checks | Checking agent, approver step and readable traces as acceptance criteria | "Human in the loop" with no name |
| 7. Price | Fixed price after definition, tied to the pass rate and the handover | A day rate with no end |
| 8. Exit | Date and condition in the contract, handover as scope | "To be agreed" |

Anything under 2 on step three or step eight is a rental, whatever the title on the badge, and a total under 16 means you are paying for delivery and buying dependency. The [downloadable checklist](/downloads/fde-engagement-checklist.md) has the grid and the questions for each step.

## When the vendor's engineer is an agent

Two things Gartner predicts are already visible. AI agents are taking over the junior part of the forward deployed engineer's job, the API mapping, the boilerplate data plumbing and the first round of troubleshooting, and Palantir now ships an AI FDE inside Foundry, an agent that builds pipelines, edits the data model and writes functions from conversational instructions. That is good news for speed and it sharpens step three. Work that an agent produces inside a vendor's platform, from a conversation nobody wrote down, is the hardest artefact to take with you when you leave.

So when part of the forward deployed work is done by the vendor's own agent, add one line to the ownership clause: everything the agent produced is exported in a form your engineers can read and re-run, and the instructions that produced it are kept with it. The rest of the playbook does not change. A shadow who owns the refusal list, an exit with a date, and an evaluation set that passes on two models are worth exactly as much when the engineer is a model as when the engineer is a person.

## How this looks in an AI Velocity Pod

I should say where these eight steps come from, because they are not a reading of Gartner's note; the note confirmed a contract we had already been signing. An [AI Velocity Pod](/ideas/ai-velocity-pods/) at Ailoitte is three to five people embedded with a client for the length of one outcome. The definition phase is two weeks and produces the evaluation set, the refusal list and the budget; the price is fixed after that, never before. The client's domain reviewer, part-time, owns the refusal list and labels the cases. Everything is built in the client's environment on the client's stack, and every artefact is theirs. The pod leaves when the agent passes the set inside the budget, and the runbook and the kill switch go to a named owner who has used them.

That is the eight steps with the vendor's name filled in. I would rather a client sent this playbook to us than took our word for it.

## If you are doing this in your company

Send the checklist to the vendor before the first meeting and ask which of the eight steps they will put in the contract. Score the answer. Insist on the definition phase before any price, and on the three artefacts as the definition of done. Name your shadow this week, and make the refusal list theirs. Put the exit date in the first draft of the contract, not the last. And when the vendor's engineer arrives, treat them as what the good ones are, a colleague for a season, and make sure the season has an end.

If you would like a second pair of eyes on a forward deployed engineering proposal before you sign, that is the kind of review I do, and the [work with me](/work-with-me/) page has the shape of it.

## Sources

- Chandrasekaran, A. and Thanaraj, R., _An AI Leader's Guide to Forward Deployed Engineering to Scale AI_, Gartner, 5 March 2026 (G00847066). Paraphrased throughout; the note is available to Gartner clients. The 59 percent prototype figure it cites comes from the 2024 Gartner AI Mandates for the Enterprise Survey (432 respondents, October to December 2024).
- Schmidt, J., [Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups](https://a16z.com/services-led-growth/), Andreessen Horowitz, 4 June 2025.
- MIT NANDA, _The GenAI Divide: State of AI in Business 2025_, July 2025: 52 interviews, 153 survey responses and 300 public AI initiatives; 66 percent deployment success for externally sourced tools against 33 percent for internal builds.
- Palantir, [AI FDE overview](https://www.palantir.com/docs/foundry/ai-fde/overview), Foundry documentation.


## Questions people ask

**Is it wrong to accept forward deployed engineers at all?**

No. The engineers are usually good, and MIT's 2025 research found that tools sourced from outside reached deployment about twice as often as tools built inside. The problem is never the engineer; it is where the work, the knowledge and the artefacts end up. Accept the engineers and scope the geometry.

**What if the vendor will only sell forward deployed engineers by the day?**

Then buy the two-week definition phase by the day and nothing else until the three artefacts exist. Once the evaluation set, the refusal list and the budget are written, ask for a fixed price for the outcome. A vendor who cannot price it after the definition phase does not know how to build it.

**Our shadow engineer does not have time. Can the vendor's engineer just document everything?**

Documentation written by the person leaving is the weakest form of knowledge transfer there is. If your engineer cannot spend a third of their week beside the vendor's, the engagement is too big for your team to inherit, and it should be smaller. Gartner's point stands - without a shadow, the engagement quietly becomes permanent staff augmentation.

**How is this different from a normal statement of work for professional services?**

A services statement of work buys effort against a specification. This buys an outcome against artefacts, with the vendor's engineer inside your environment and incentivised on your renewal. The eight steps exist because that geometry needs controls a services contract does not have - access, ownership, a shadow and an exit.

**Does Ailoitte sign contracts like this?**

Yes. An AI Velocity Pod is scoped exactly this way - definition phase, three artefacts, fixed price, a domain reviewer from the client who owns the refusal list, and an exit when the agent passes the set inside the budget. This playbook is that contract with the vendor's name left blank.


---
Sunil Kumar, Co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/about/