The handover problem, or what "done" means on an AI engagement

There is a version of a successful AI project that is actually a failure with good demo footage. The system works. It is in production. And the only people who can safely change it left when the statement of work ended.

Six months later the model needs updating, the retrieval corpus has drifted, and the client’s team faces a choice between an unfamiliar codebase and another contract. That is not a partnership. It is a dependency, and it was built in deliberately or through inattention.

What we mean by handover#

A handover is complete when the client’s own team can do four things without us: deploy a change, diagnose a failure, evaluate whether a change made things better, and explain the system to somebody who was not there.

Everything we produce is oriented at those four capabilities.

Deploy a change. Their pipeline, their repositories, their credentials, from Prove onwards, not retrofitted at the end. If the first deployment their team performs is after we leave, we have tested nothing.

Diagnose a failure. A runbook written against failures that actually happened, not imagined ones. We keep an incident log through the engagement and the runbook is assembled from it. The generic “check the logs” runbook helps nobody at 03:00.

Evaluate a change. The evaluation suite, the golden dataset, and the documentation explaining why each case is in it. This is the artefact that decays fastest without the reasoning attached, a test case whose purpose nobody remembers gets deleted the first time it fails.

Explain the system. Architecture decision records covering what we chose, what we rejected, and what would make us revisit it. The rejected options matter most. Without them, a future engineer sees an arbitrary choice and re-litigates it.

How we test that it worked#

Claiming a handover is complete is not the same as demonstrating it. In the final phase we invert the working arrangement: the client’s team drives and we watch.

They deploy a real change. They respond to an injected failure in a staging environment. They add a case to the evaluation set and interpret the result. We take notes on where they hesitate, and those places become the last documentation we write.

It is uncomfortable for both sides, and that discomfort is the signal. A handover that feels smooth usually means the client’s team is still watching rather than driving. Expect it to surface at least one thing the build team thought was obvious and was not, because there is always one, and it is much better found in the last week of an engagement than in the first week without you.

Write the exit plan first#

We agree the exit criteria during Frame, in writing, before any code exists. Which capabilities transfer, to whom, by when, and what evidence demonstrates each one.

Two effects follow. It shapes the build. You architect differently when you know a named team will own it. And it removes the awkward conversation at the end, because the destination was agreed when nobody was invested in a particular answer.

What this costs us#

Less follow-on revenue from clients who cannot leave, more from clients who choose to come back. That is a commercial decision we have made deliberately, and it is worth saying plainly rather than dressing up as a philosophy.

It also costs delivery time. Pairing is slower than doing it ourselves. Writing decision records takes hours that could have been spent on features. We think that trade is correct, and we would rather say so than pretend handover is free.

The signal that it went right#

Some months after an engagement ends, someone from the client’s team sends us a question about a change they have already made, not asking permission, just checking reasoning.

That is the outcome. Not a support contract. A team that has taken ownership and occasionally wants a second opinion.