The handover is the product, not the agent

The most expensive AI build is the one your team cannot operate without the studio that wrote it. The agent works. The numbers go up. And then the contract ends, the studio moves on, and the system slowly drifts because nobody internal can change it.

This is the failure mode AI procurement is starting to wake up to — and it is the failure mode we built the studio to avoid. Everything we ship comes with a handover, and the handover is the actual product. The agent is just what the handover describes. Below: why reading it matters, and where the bar gets harder.

The agent is just a snapshot

Every workflow agent we ship is a snapshot of a process at a moment in time. The team’s policies on day one. The tone of voice they want today. The systems that exist this quarter. The exceptions worth flagging given current volumes.

None of those things stay still. Policies change. Tone evolves. Systems get replaced. Exception thresholds need tuning when volume doubles. So if the agent is a snapshot, the question is who can take the next snapshot.

If the answer is “only the studio that built the original,” the client has bought a system with a permanent dependency. That dependency is rarely visible at the point of purchase. It is very visible eighteen months later.

An AI build that the client cannot operate, change, or turn off without the studio is not a build — it is a subscription with extra steps.

What the handover actually contains

A handover that does its job is not a one-page user guide. It is the entire scaffolding the next engineer or operator needs to take ownership. We typically deliver six things:

1. The repository

All code, in the client’s source-control account, on day one of go-live. Not in our private repo with deploy keys we control. The branch protection, CI rules and review process are theirs to set.

2. Every prompt, in plain text

Inline-edited and version-controlled. Not embedded in proprietary tooling. Not tucked behind a vendor’s chat-prompt UI. We have shipped enough of these to know that the team will, eventually, want to change “tone is professional” to “tone is professional but warmer for first-time customers.” That edit should not require us.

3. The runbook

A written document that covers: what the agent does, what it does not do, how to read its logs, how to interpret its escalation flags, what to do when it goes down, how to add a new edge case, how to roll back. Step by step. With screenshots. As if the next person reading it has none of the context we built up over six weeks.

4. Credentials and access

Every API key, secret and shared account, transferred to the client’s secret manager on day one. We do not retain operational access by default. If the client wants us on retainer, we get re-issued credentials scoped to the retainer.

5. The off switch

A documented, single-action way to take the agent out of production and fall back to the human-only version of the process. The off switch matters most for the situation where the agent starts behaving in a way that is not obviously wrong but is subtly off-policy. The team needs to be able to pause, investigate, and resume without an emergency call to us.

6. The next-engineer letter

A short prose document — usually two or three pages — that explains the design choices we made and the alternatives we rejected. Why we used a queue here instead of a webhook. Why the prompt has the line about not committing to delivery dates. Why the human review threshold is set at the value it is. The kind of context that would otherwise live in the head of whoever scoped the build.

Six artefacts. None of them are the agent. The agent is the easy part — it is what the artefacts describe.

If the studio is in the loop on every change six months later, we did not finish the work.

Reading the handover before signing off

Here is the harder part. A handover that the client never actually reads is the same as no handover at all. We have shipped builds where every artefact was in place, the credentials were transferred, the runbook was written — and a year later the client phoned us because nobody had ever opened the runbook and now the agent’s failure mode looked like magic.

So the handover ends with a session, not a document drop. We sit with the team that will own the system, walk them through the runbook line by line, get them to make a real edit (small but real — change a prompt line, redeploy, watch it land in production). The handover is not signed off until somebody on the client’s side has changed something and watched it work.

This is the moment most “we delivered the docs” handovers fall apart. The docs are right. The team has not actually used them. So the first time anything needs to change, the team’s instinct is to call us — because they have not yet built the muscle memory of changing the system themselves.

The handover sets the ceiling

There is a specific failure mode worth naming. It is the build that runs beautifully for the first quarter, then plateaus — not because the agent broke, but because the team never extended it.

New use cases come up that the existing agent could obviously handle with small adjustments. But adjusting it requires the studio. Calling the studio requires a budget conversation. So the team works around the gap manually instead. A year later the agent is still doing its original job, and the team is back to manual on the edges.

The agent has not failed. The handover has. The ceiling on the build’s value is set by how much of it the client team can extend on their own — and that ceiling is set by what is in the handover, not by what is in the agent.

This is why, when we scope a build, we scope the handover at the same time. Not as a tail-end deliverable, but as a co-equal artefact. The agent and the runbook are written together, by the same people, in the same week. The runbook is reviewed by the team that will own it before the agent ships, not after.

What this looks like in a contract

We write three things into every fixed-price contract:

• Day-one ownership clause. All artefacts (code, prompts, runbook, credentials) transfer at go-live. No grace period. No “we will get to it next month.”
• Off-switch acceptance. The client cannot accept the build until they have demonstrated they can take it down and bring it back up without us in the room.
• Optional retainer, never default. A retainer is something the client picks up if they want; never something the build silently requires. We make the build operable without us first, and offer ongoing help separately.

The retainer thing matters. There is a version of this work where every studio shapes its handover just loosely enough that the client effectively has to renew. We do not do that, on purpose. About 60% of our clients pick up a retainer in the first year — but it is for new work, not maintenance of the existing build. That ratio is a leading indicator of whether the handover did its job.

The harder version of the same idea

Everything above is the easy version of “shipping a system someone else can own.” The harder version is shipping a system someone else can improve — not just operate.

An operable system maintains its current performance. An improvable system gets better as the team that owns it learns more about its actual usage. Improvability is a different bar. It needs the runbook, but it also needs:

• A logging layer the team can actually read, with structured events the team can group and chart, not raw stack traces.
• Observability into the prompt — which versions ran on which conversations, with the input and output captured for review.
• A clear point in the architecture where new use cases are added without rewriting the rest of the system.

We do not always hit the improvable bar. The operable bar is non-negotiable; the improvable bar is something we deliberately scope towards on builds where the team is capable of running with it. Roughly half the time it is the right call, depending on the team. But the question — operable or improvable — is one we ask out loud at scoping, not one we leave to chance.

The short version

If the team that owns the work cannot read, change, run and turn off what we built — without us — we have not finished the job. The agent is just what the handover describes. The handover is the actual deliverable, and it is what we are asking the client to evaluate at sign-off.

That is the standard. We will keep writing about the cases where it is harder than it sounds.