You are releasing a new orchestrator graph that changes tool-routing logic. Full big-bang production cutover is considered too risky. Traffic is sticky per session. Which release methodology best fits?
Select an answer to reveal the explanation.
Short Explanation
Canary it. Route a small slice of sticky sessions to the new orchestrator, watch quality and error metrics, then expand or roll back. Big-bang and laptop-as-prod don't control risk.
Full Explanation
The canary or progressive release option is correct because release methodologies include DTAP, blue/green, and canary. For a risky orchestrator routing change with session stickiness, you canary a fraction of sessions, watch quality and error metrics, then promote or roll back based on gates. This limits blast radius while metrics and eval gates decide expansion or rollback, which is appropriate for high-risk routing changes.
The developer-laptop-as-production option is wrong because developer environments are not production release control.
The simultaneous full production replacement option is wrong because big-bang cutover maximizes blast radius and the impact of routing regressions.
The skip-staging-because-multi-agent-graphs-cannot-be-canaried option is wrong because multi-agent systems can and should use progressive delivery with session affinity and eval gates.
Exam tip: Risky orchestrator changes mean canary sessions plus metric gates plus rollback.