A platform team must release a new orchestrator prompt and tool graph for a customer-facing multi-agent app with minimal blast radius. They need progressive exposure, quick rollback if quality or safety metrics regress, and no big-bang cutover. Which release approach fits best?
Select an answer to reveal the explanation.
Short Explanation
Correct answer: B. Canary releases are the dimmer switch for multi-agent changes—new prompt and graph see a slice of traffic first. If safety or quality dips, you roll back to the last good revision instead of hoping a VM snapshot from midnight saves the day.
Full Explanation
For multi-agent solutions, release methodology choices include DTAP, blue/green, and canary. Option B is correct: canary (or progressive cohort) exposure limits blast radius for prompt/tool-graph changes, couples promotion to observed quality/safety/cost metrics, and preserves fast rollback to the previous revision.
Option A is incorrect: single-window big-bang cutover maximizes blast radius; VM snapshots are coarse, slow, and poorly suited to prompt/config/agent graph rollback.
Option C is incorrect: randomly disabling agents on any error is not a controlled canary strategy and can break orchestration invariants unpredictably.
Option D is incorrect: prompts and agent graphs are production configuration; skipping staging and controlled release violates multi-environment release hygiene.
Exam tip: Match “minimal blast radius” and “quick rollback” to canary or blue/green with automated rollback—not big-bang production-only deploys.