Capability transfer in AI delivery: what actually transfers, and how

Last updated: July 2026

Capability transfer is the operational spine of the build-with-you delivery model. Our pillar on build-with-you named the market thesis and positioned it against pure build, pure buy, and Big 4 Alliance delivery. This post is the operational answer to the next question buyers ask: what actually transfers, mechanically, from the partner's engineers to the in-house team, and how does the partner know when to leave. The Build-Operate-Transfer (BOT) model has been running in software delivery for two decades. Adapting it to agentic AI delivery in 2026 means transferring artefacts the offshore-GCC playbook did not have to worry about — eval pipelines, prompt versioning, agent registries, model provenance. This post walks through the six categories of artefact that transfer, the pair-working pattern that makes the transfer stick, the exit signal that says the transfer is done, and the failure modes when a partner cuts corners.

Key takeaways

• Capability transfer is six categories of artefact, not a wiki page. Code, prompts, eval datasets, infrastructure-as-code, runbooks, and pair-working knowledge. All six transfer, or none of them meaningfully transfer.
• The BOT model is not new — the artefact list is. Classic BOT transfers people, processes, and a running operation. AI delivery transfers eval pipelines, prompt versioning discipline, agent registries, model provenance. The engineering artefacts are what agentic delivery adds.
• Pair working is the transfer, not a nice-to-have. Documentation transfers what you already know how to look up. Pair working transfers what you did not know to ask.
• The exit signal is operational, not calendar-based. The transfer is complete when the in-house team ships a production change without the partner's involvement. Not on a date, not at a budget threshold, not at a milestone review.
• The failure mode is a "handover event" at the end. Handovers concentrated in a single week never work. Transfer distributed across the whole engagement does.

The six categories of artefact that transfer

The transfer manifest is not one repository. It is a set of six discrete categories, each with its own transfer mechanism and its own way to verify the transfer landed.

Code. The obvious one. Source code, tests, CI configuration, deployment scripts. Transferred through git repositories the in-house team owns from day one — not a partner-owned repo that gets pushed at the end. The transfer verification is the in-house team's first pull request that merges without the partner's review.

Prompts and prompt versioning. Agentic systems live and die by prompt discipline. Every prompt is versioned, every prompt change goes through the eval pipeline, every deployed prompt maps to a specific commit. The transfer artefact is the prompt registry — a versioned store, sometimes an internal service, sometimes a directory in the repo with a specific structure — and the CI checks that gate prompt changes on eval regression. Verification is the in-house team modifying a prompt, running the eval, and shipping the change.

Eval datasets. Golden datasets in CI. Adversarial cases for context contamination. The rubric definitions the LLM-as-a-judge evaluator uses. The human review cases that fed the last golden update. All of this is data the in-house team has to be able to extend. Transferred as datasets in the repo (or in a designated data store) with clear ownership and clear rules for when new cases get added. Verification is the in-house team adding a new eval case in response to a production failure and closing the loop.

Infrastructure as code and secrets. The infrastructure the agent runs on — Kubernetes manifests, Terraform, cloud IAM, database migrations, secret management — all as code, all in a repo the in-house team owns, all deployable without the partner. Secrets rotate through the in-house team's secret management (Vault, cloud KMS, whatever they use) from Phase 2. Verification is the in-house team deploying a new environment from scratch.

Runbooks and on-call. The playbooks for what to do when something goes wrong. Incident response procedures. The list of dashboards to check. The escalation tree. The recurring failure modes and their fixes. Transferred as documentation the in-house team maintains (not the partner's wiki), and refined by pair working during Phase 3. Verification is the in-house team handling a real production incident without paging the partner.

Pair-working knowledge. The part that does not fit in a document. Why we picked this retrieval architecture over the other one. What happens when the confidence threshold drops. Which prompt patterns work well with Claude versus GPT. The trade-offs we already tried and rejected. This category transfers through the pair-working mechanism below — it does not transfer any other way.

Pair working is the transfer mechanism

Documentation transfers the parts you already know how to look up. Pair working transfers the parts you did not know to ask. Every serious capability-transfer engagement runs on pair working through Phase 2 and Phase 3.

The pattern. Partner engineer and in-house engineer are paired on a specific piece of work — a new agent, an integration extension, a prompt refactor, an eval-set expansion. They work at the same screen (or same VS Code Live Share session, or same paired repo branch), and the partner narrates decisions as they make them. The in-house engineer questions choices they would not have thought to make. Over the course of the engagement, the balance shifts: the partner does more of the driving early, the in-house engineer does more of the driving later, and by month four to six the partner is a reviewer rather than a driver.

Two things make pair working work. First, the in-house engineer has real capacity for it. Capability transfer without dedicated in-house time is theatre. Second, the partner engineer is genuinely senior. A junior partner engineer transfers a junior's understanding, which is not what the buyer is paying for.

This is where the partner-selection question we covered in the build-with-you pillar actually shows up in practice. Senior engineering depth is not a nice sales-page claim. It is what determines whether pair working is a transfer mechanism or an expensive shared-screen exercise.

The exit signal is operational

Every capability-transfer engagement needs an exit criterion that is not "the calendar says we are done." The signal we use is operational: the in-house team has shipped a production change without the partner's involvement.

What that looks like specifically. The in-house team writes a new tool definition for an agent. They write the schema for its arguments and its return type. They write the eval cases that cover the new tool's behaviour. They ship the change through CI, the eval passes, the agent uses the new tool in production correctly. The partner reviewed the pull request but did not write the code. That is one signal.

The next change after that, the partner does not review. The change after that, the in-house team has shipped three production changes without any partner involvement. That is the signal that the transfer is done.

The signal usually arrives between month four and month nine, depending on the team's starting expertise and the complexity of the system. When it arrives, the partner steps out. Not on a date, not at a budget threshold. On the operational reality that the team can run the system.

The failure modes when transfer is done badly

Three patterns account for most of the transfer failures we have seen or heard about across the industry.

The "handover event" at the end. The partner runs the whole engagement, then schedules a week of "knowledge transfer" at the finish. The wiki gets written. The team gets briefed. The partner leaves. Two months later the in-house team encounters a failure mode the partner would have recognised in a heartbeat and cannot resolve without paging them back. This pattern fails because transfer is a distributed practice across many decisions, not a concentrated event.

The one-way dependency on partner infrastructure. The partner's monitoring dashboard, the partner's eval runner, the partner's staging environment. All of it convenient during the engagement. All of it a hostage situation when the partner leaves. The fix is to make the in-house team's tooling primary from Phase 2, even when the partner's tools would be faster in the short term.

Undocumented tacit knowledge. The partner senior engineer holds the model of why this specific retrieval architecture was picked, why the confidence threshold sits at that value, why this prompt pattern works and that one does not. If the tacit knowledge never gets pair-worked out, the in-house team inherits a system whose choices they do not understand. Six months later they revert one of the choices because they do not know why it was made, and the system regresses.

What has to be true at engagement start for transfer to work

Two conditions determine whether capability transfer succeeds, and both have to be true in Phase 1.

The in-house team exists and has bandwidth. Transfer requires attention. If the receiving team is also running production for the existing systems, and there is no dedicated time booked for pair working and code reviews, the transfer will not happen. Honest bandwidth planning in Phase 1 is what makes Phase 3 possible.

The partner is engineering-led, not delivery-management-led. Transfer happens through pair working with senior engineers. If the partner's model is to send a delivery manager and staff junior engineers under them, the tacit knowledge does not transfer. The seniority of the people doing the actual work is the strongest predictor of whether the exit signal ever arrives.

Both conditions surface in Phase 1 discovery. Neither can be manufactured mid-engagement. Buyers that get these two right end up with the working system and the team that can run it. Buyers that get either one wrong end up with a working system that the partner has to keep running.