Build
Handover docs your team will actually read
Tobiloba Odejinmi · 21 Apr 2026 · 6 min · 958 words
Direct answer
Handover docs your team will actually read are one operating note plus a call. The note says what the AI employee does, what it must not do, where it writes, where the logs are, who owns an escalation, and how a case reenters after a person decides. Day 7 of the week is this. A binder nobody opens is not a handover.
- Write for the person who is awake when it breaks.
- Include exits, gates, and the reentry path, not a product story.
- The call walks one clean case and two ugly ones.
- Docs rot unless someone owns the date on them.
What belongs in a handover people will open?
Purpose in one paragraph. The trigger. The tools. The actions it is allowed to take. The hard gates. The escalation payload. The named owner and backup. Where to see what it did. How to pause it. How to rerun a case. The date it was last true. That is the page. If you need more, you probably need a second page for builders, not a longer page for operators.
I write like I write a runbook for a payment path. Can someone who did not write the code say why it failed without opening six tabs? If the answer is no, the doc is for me, not for them. Day 7 is for them.
Who is the document for?
The person who will get the Slack ping when a customer waits, a candidate is stuck, or a lead note looks wrong. They are not the CTO. They may not want a diagram of agents. They want to know whether to pause, escalate, or ignore. Write in their nouns. Ticket. Lead. Role. Clinic. Not 'orchestration.'
A second reader is the person who will change a prompt or a connection later. They need the map, the test set location, and the service identity. That can be a linked note. Do not make the night reader wade through it.
What do you leave out?
The sales story. The history of the week. Every prompt version. Screenshots of the happy path that already works. Motivational language about AI. Anything you would be embarrassed to read out loud to the person who still does the leftover 10 to 15 percent by hand.
I also leave out fake certainty. If a gate is new, the doc says it is new. If a tool is flaky, the doc says it is flaky. Handover is not a performance. I have sold companies. Buyers open cost, uptime, and whether you can explain the database. Your team will open the same kinds of facts when the employee misfires.
What does the handover call cover?
We run one clean case from trigger to write-back. We run a missing-field case. We run a hard gate so they see the decision brief. We open the monitor. We pause and unpause. We show where the logs are. People remember what they just did with their hands. They do not remember a slide that said 'human in the loop.'
The call is also when we name week-two watchers. The $7,500 week includes 30 days of support, but support is not a substitute for a person in the company who cares if the queue looks wrong. If nobody will watch, we should not have gone live. That is a day-1 problem that sometimes only becomes honest on day 7.
How do you keep the docs from rotting?
Put a date on the page and change it when the map, the gates, or the tools change. Rerun the test set after a prompt change and write the miss rate down. If you cannot point to a date, assume the doc is lying. I would rather a short stale warning than a long confident antique.
On several-workflow work at $15,000+, I treat the docs as part of the architecture. Someone owns the pattern: same page shape, same payload, same pause switch. That is how you avoid seven little novels. The first week still starts with one page. Do not skip to a documentation programme before you have one live employee.
Where should the write-up live?
In the tool the team already searches. Notion, Google Doc, Confluence, the help desk internal note. I do not care, as long as it is the same place they look for the refund rule. A beautiful portal with a new login is a new religion. We already refused that for the employee. We should refuse it for the docs.
Link the page from the monitor and from the queue. Two links. When someone asks 'what does this thing do?' the answer is a URL, not a person. If the answer is still a person, the handover failed, even if the call went well.
Questions people ask
How long should the write-up be?
Short enough to read before you touch the queue. If it needs a table of contents, you wrote a wiki. Split the architecture notes out and keep the operating page thin.
Where should it live?
Next to the work. A pinned doc in the same place the team already looks, plus a link from the monitor. Not a new documentation product.
Who owns it after the week?
The queue owner. I will update it during the 30 days of support on the $7,500 week. After that, if nobody owns the date, it is already wrong.
Do you record the handover call?
If the team wants a recording, yes. The recording is a backup. The page is the source. People do not search a 40-minute video at 2am.
What if leadership wants a longer deck?
They can have a one-page summary of hours saved and miss rate. That is not the handover. Mixing the two is how the operating note fills with slogans.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
