Forward deployed engineering: an operating model for AI delivery inside client teams

Background

Most software services are delivered at a distance. A business analyst gathers requirements, a team builds against them, and the result is tested and handed back. For many systems this works well enough.

AI systems are different in one important way. Their behaviour depends on detail that is hard to write down. Which supplier always sends invoices with the GST number in the footer. Which customer abbreviations mean the same product. When a claims officer overrides the policy rule and why. That knowledge sits with the people who do the work, and much of it never reaches a requirements document.

Forward deployed engineering puts the builders where that knowledge is. Engineers and strategists work inside your team, in your codebase and on your systems, and ship to production from there.

Approach

This paper is based on analysis of public documents and the practices we use in delivery. We used the NIST AI Risk Management Framework 1.0 and ISO/IEC 42001:2023 to check that an embedded model still meets the governance expectations those documents set, particularly on roles, accountability and documentation. Where personal data is involved, we considered the obligations of a data fiduciary and a data processor under the Digital Personal Data Protection Act, 2023 (India).

The operating model itself comes from how we run our own Forward Deployed Engineering (FDE) engagements, in which forward deployed engineers and forward deployed strategists work as part of the client team. No client data, names or results are used.

Findings

1. Context is the scarce input

In AI work, the model and the tooling are increasingly available to everyone. What differs between a system that works and one that does not is how well it reflects the real process. Engineers who sit with the accounts team for a week learn things that a month of remote calls would miss.

2. Two roles are needed, not one

An engineer embedded alone tends to build what is asked for. A strategist alongside them asks whether it should be built, what result the business needs and how it will be measured. In our model the strategist maps the problem and the result. The engineers build, connect and run it. Without the strategist, embedded teams drift into becoming extra hands. Without the engineers, strategy stays on slides.

3. Embedding is not staff augmentation

Staff augmentation supplies people who take direction from the client. Forward deployed teams own an outcome and bring their own methods, review and quality checks. The difference shows up when something goes wrong: an augmented developer waits for instructions, while a forward deployed team is expected to propose the fix.

4. Access and security have to be designed in

Working inside client systems means production access, which raises real risk. Embedded engineers need named accounts, least privilege, logged access and clear rules about where data can go, including which model providers may receive it. These controls are what make embedding acceptable to a security team.

5. Handover is where value is kept or lost

An embedded team that leaves without transferring knowledge leaves behind a system nobody understands. Handover has to be planned from the first week, with client engineers pairing on the work and documentation written as the system is built.

A framework

We call this the Embed, Prove, Run, Transfer model. Each phase has entry conditions, working practices and an exit test.

Phase 1: Embed (typically 1 to 2 weeks)

Entry: a named client owner with authority over the process, agreed access to systems and people, and a written problem statement.

Practice:

• Sit with the people who do the work. Observe the process end to end at least once.
• Collect real examples, especially exceptions and failures.
• Map data sources, systems and integration routes, and note who owns each.
• Agree the success measure and the evaluation approach with the client owner.

Exit test: a one page brief the client owner signs, stating the use case, success measure, data sources, risks and a first evaluation set.

Phase 2: Prove (typically 2 to 3 weeks)

Practice:

• Build the smallest version that runs on real data in the client environment.
• Run it in shadow mode alongside the existing process.
• Report weekly against the success measure, including bad weeks.
• Start security, privacy and integration approvals in parallel.

Exit test: the system meets the agreed score on the evaluation set and holds up in shadow use, and the client owner decides to proceed.

Phase 3: Run

Practice:

• Harden integrations, add monitoring for quality, cost and failures, and put human approval in front of risky actions.
• Roll out to users in waves.
• Pair client engineers with the forward deployed team on every change.
• Write runbooks in the language the client team uses.

Exit test: stable operation at the agreed quality for an agreed period, with incidents handled under a written process.

Phase 4: Transfer

Practice:

• Client engineers lead changes with the forward deployed team reviewing.
• Hand over documentation, evaluation sets, monitoring dashboards and access.
• Agree the ongoing arrangement: full client ownership, a managed service, or a smaller retained team.

Exit test: a client engineer can make a routine change, run the evaluation set and respond to an alert without help.

Criteria to decide whether to embed at all

• The problem is not fully defined and needs shaping with the people who do the work.
• The system must integrate with several internal systems that only insiders understand.
• The client can give named access and a named owner.
• There is an intention to own or co-own the system afterwards.

If none of these apply, a conventional output based engagement against a written specification is usually simpler and cheaper.

Recommendations

1. Name the client owner before the team arrives. Without one, the embedded team has nobody to make decisions with.
2. Send a strategist with the engineers. Even part time, the strategist keeps the work tied to a business result.
3. Treat access as a deliverable. Agree accounts, permissions and data rules in writing during Embed.
4. Pair from the start. Client engineers who join only at Transfer will struggle to take over.
5. Keep the evaluation set as a shared asset. It is the most useful thing to hand over, because it lets the client check every future change.
6. Set an end date for embedding. Open ended embedding tends to turn into staff augmentation by stages.

Limitations

The model reflects our practice and the governance frameworks we cite. It has not been tested against a controlled comparison with other delivery models, and we make no claim that embedded delivery is always faster or cheaper. It assumes the client can host engineers, physically or through remote access to internal systems, which some regulated organisations cannot easily allow. It also assumes a client team that wants to own the system in the end. Organisations with no internal engineering capacity may be better served by a managed service from the start. Finally, phase durations are indicative and vary widely with integration complexity.

Sources

• NIST AI Risk Management Framework 1.0
• ISO/IEC 42001:2023
• Digital Personal Data Protection Act, 2023 (India)
• OWASP Top 10 for Large Language Model Applications