# Forward deployed engineering engagement checklist From "How to scope a forward deployed engineering engagement" by Sunil Kumar https://sunilkumar.ai/playbooks/how-to-scope-a-forward-deployed-engineering-engagement/ Licence: CC BY 4.0. Copy it, edit it, send it to the vendor before the first meeting. The principle: say yes to the engineers and no to the geometry. Each step moves one piece of the work, the knowledge or the ownership back to your side of the line. Score each step 0 to 3 in the negotiation: 0 = not in the contract 1 = a promise or a policy document 2 = a clause 3 = a clause with a test you can run Anything under 2 on step 3 (ownership) or step 8 (exit) is a rental, whatever the title on the badge. A total under 16 means you are paying for delivery and buying dependency. | Step | Score (0-3) | Notes | |---|---|---| | 1. Outcome as three artefacts, before the price | | | | 2. Access decided before the badge | | | | 3. Ownership of every artefact | | | | 4. Your shadow, owning the refusal list | | | | 5. Your platform, swappable interfaces | | | | 6. Second check on the output | | | | 7. Price the outcome, not the presence | | | | 8. Exit written on day one | | | ## 1. Write the outcome as three artefacts before the price Ask: "What will the agent pass, what must it refuse, and what may a run cost? Show me the three documents before the quote." - [ ] Evaluation set from our 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 - [ ] Definition phase (two weeks) priced by the day; everything after it priced against the artefacts Disqualifying answer: a price quoted before the artefacts exist. ## 2. Decide the access before the badge Ask: "Which systems and which data will your engineer touch, who approves an exception, and how do we revoke access?" - [ ] Access list per system, least privilege, attached to the contract - [ ] Exception process with a named approver on our side and a written log - [ ] One sanctioned platform for anything the engineer builds; nothing outside it - [ ] Credentials issued and revoked by us, with revocation tested on day one - [ ] The engineer works under our identity provider, secrets store and logging, not the vendor's Disqualifying answer: "standard vendor access." ## 3. Settle ownership of every artefact Ask: "List every artefact this engagement produces, and tell me which of them we can run without your tooling." - [ ] Every artefact named: prompts, workflows, connectors, evaluation set, refusal list, runbook, data model and field definitions - [ ] All of them ours (Gartner's rule of thumb is at least 70 percent; ask for all of it) - [ ] Delivered in a format our engineers can read, edit and deploy without the vendor's tooling - [ ] Data model and field definitions co-owned and exportable from day one - [ ] Anything produced by the vendor's own AI agent exported with the instructions that produced it Disqualifying answer: a percentage, or "configuration remains the vendor's." ## 4. Name your shadow, and give them the refusal list Ask ourselves: "Who on our side will spend a third of their week beside the vendor's engineer, starting week one?" - [ ] 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: people certified, changes shipped without the vendor, shadow weeks logged Disqualifying answer: "knowledge transfer sessions at the end." ## 5. Build on your platform, behind swappable interfaces Ask: "What happens to this agent when the model changes? Show me the test." - [ ] 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 evaluation set passes on two models from different providers Disqualifying answer: code that only runs on the vendor's model. ## 6. Put a second check on the agent's output Ask: "Who checks the agent's output on every run, who approves an irreversible action, and can our compliance team open a trace without you?" - [ ] A checking agent on every run, with its verdicts in the trace - [ ] A named approver on our side for every irreversible action, built into the workflow - [ ] Traces readable by our compliance team without the vendor's help, retention set by our regulator - [ ] Guardrail failure rate measured on the evaluation set and reported at handover Disqualifying answer: "human in the loop" with no name. ## 7. Price the outcome, not the presence Ask: "After the definition phase, what is the fixed price for the outcome, and what is it tied to?" - [ ] 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 Disqualifying answer: a day rate with no end. ## 8. Write the exit on day one Ask: "On what date and on what condition does your engineer leave, and what happens if the condition is not met?" - [ ] 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 at the day rate) - [ ] Handover of runbook, kill switch, evaluation set, refusal list and traces as scope, to a named owner on our side - [ ] Our owner has operated the kill switch before the last day Disqualifying answer: "to be agreed." --- Sunil Kumar, co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/