Module 15 · Lesson 04

Defining Done — Handoff Standards That Actually Stick

Reading time: 15 minutes Track: Yungsten Tech Employee Curriculum · Required for all staff

The handoff failure mode

The most common Yungsten engagement failure: we deliver something technically excellent that the client can't maintain six months later. Not because the client is incapable — because we didn't leave the right things behind.

A handoff isn't complete when you hand over credentials and documentation. It's complete when the client demonstrates they can operate it independently.

The handoff standard: three artifacts

Every agent or system handoff requires three artifacts:

1. The Runbook

A runbook is not a technical manual. It's the document an operator reads when something goes wrong at 9pm when you're not available. It answers:

• What does this agent do? (One paragraph, plain language)
• How do I run it / trigger it? (Step by step, assuming zero context)
• What does success look like? (How do I know it worked?)
• What do I do when X breaks? (The three most likely failure modes and their fixes)
• Who do I call if I can't fix it? (Escalation chain)

Write runbooks for the actual operator — the person who will be paged at 9pm. If that person is the CFO's executive assistant, write for them. If it's a junior developer, write for them.

2. The Wiki Entry

The wiki entry lives in the client's Obsidian wiki and covers:

• What this agent is, what problem it solves, and who owns it
• The prompt architecture (what system prompt does it use, why)
• How it connects to other systems or agents in their stack
• Change history: what's been updated and when
• Training notes: common mistakes and how to avoid them

3. The Demonstration

Before handoff is complete, the client operator must demonstrate they can:

• Start or trigger the agent from scratch
• Interpret a successful output
• Identify a failure
• Follow the runbook to address at least one failure scenario

The demonstration is not an evaluation — it's a practice run that surfaces gaps in the documentation while Yungsten is still there to fill them.

Writing for the actual reader

The single biggest handoff documentation mistake: writing for yourself instead of the actual reader.

When you write a runbook, you know all the context. The reader knows none. Test your runbook by sharing it with someone on the client's team who didn't participate in building the system. Watch them try to follow it. Every place they get stuck is a gap.

Setting the handoff expectation

Tell clients at the start of the engagement: "By the time we hand this off, you'll be able to run it yourself. We'll demonstrate that together before we call it done."

This sets the right expectation (capability transfer is the goal, not just tool delivery), gives the client something to work toward, and creates an objective completion criterion that everyone can agree on.