A tool migration canary should run accepted scenarios on bounded traffic, compare contract and task events with the prior path, stop on named failures, and preserve a tested route back to the old supported version.
Define the comparison before sending traffic
A canary is useful only when the team knows what it is comparing. The plan should name the eligible callers, supported tasks, percentage or count of traffic, duration, and required evidence. It also defines failures that stop the release, including tool-not-found events, validation errors, unauthorized actions, changed side effects, unrecoverable loops, and missing operator visibility.
Google's Site Reliability Engineering workbook describes canarying as a partial and time-limited deployment whose results are evaluated against a control. For an agent tool migration, the control can be the prior supported contract running the same deterministic fixtures or a matched set of production-shaped tasks. The buyer chooses which real traffic may participate.
Observe contract events and task outcomes
The comparison should inspect more than final text. It records the tools presented, selected action, validated arguments, authorization decision, tool result, retries, terminal state, latency, and any external side effect. A task can appear successful while using a retired fallback or issuing an extra write, so contract events and destination receipts belong beside task completion.
Stop rules should map directly to observable events and route the affected callers back to the supported path. A subjective quality concern can trigger review, but invalid requests, permission violations, unexpected side effects, and missing trace evidence should block mechanically. The canary record must remain readable after a rollback so the same failure is not rediscovered.
Rehearse rollback while both paths remain available
Rollback should be rehearsed before the old contract or adapter is removed. The rehearsal switches the selected caller set back, confirms registry and cache propagation, runs the accepted smoke scenarios, and records the restored version. Data or side effects created by the canary need a separate reconciliation plan because changing code does not reverse completed external actions.
Reality Contact, LLC can build the canary suite, stop gates, visibility, and rollback procedure. The buyer authorizes traffic, chooses acceptable behavior, controls production release, and decides when the old contract may be retired. The canary provides evidence for the exercised conditions without predicting every model response.
Where the service stops
Reality Contact, LLC implements and tests the migration, but does not invent target semantics, weaken authorization, approve external side effects, select production traffic, or retire a contract without buyer approval. The buyer approves the target semantics and caller set, runs the accepted canary scenarios, and retires the old contract only after compatibility and rollback gates pass. This is software migration and technical testing, and it does not replace legal, security, privacy, compliance, or professional advice. The buyer owns tool semantics, credentials, permissions, caller communication, canary authorization, production release, and contract retirement.