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
C is the lower-risk path. Release methodologies include DTAP, blue/green, and canary. For risky orchestrator routing changes with session stickiness, canary a fraction of sessions, watch quality/errors, then promote or roll back. Laptop-as-prod is not a methodology. Big-bang maximizes blast radius. Multi-agent graphs can and should be progressively released with eval gates.
Full Explanation
Correct Answer — C
Choosing a release methodology includes DTAP, blue/green, and canary. Canary/progressive exposure for a new orchestrator graph limits blast radius while metrics and eval gates decide expansion or rollback—appropriate for high-risk routing changes.
Why A is wrong: Developer environments are not production release control.
Why B is wrong: Simultaneous full cutover maximizes impact of routing regressions.
Why D is wrong: Multi-agent systems can use progressive delivery with session affinity.
Exam tip: Risky orchestrator changes → canary sessions + metric gates + rollback.