After a canary showed elevated tool-error rates, you need an immediate switch back to the last known-good multi-agent graph and model deployment with minimal DNS-level complexity. Environments already run side by side. Which approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
You need a controlled rollback, not a prayer. Flip traffic back to the last known-good multi-agent graph and model with a blue/green-style swap or equivalent slot swap, since the environments already run side by side. That restores service fast and keeps rollback as a first-class release operation.
Full Explanation
Blue/green-style traffic switching, or an equivalent deployment-slot swap, is the appropriate approach because rollback should be designed as part of release management. When environments already run side by side, you can flip traffic from the failing agent stack to the prior healthy stack with low recovery time objective and minimal DNS-level complexity. Keep infrastructure, prompts, and evaluation baselines versioned so the target environment is truly known-good. Leaving the bad version in place and hoping errors decline is wrong because elevated tool errors need decisive rollback, not passive waiting. Deleting both environments and rebuilding from memory overnight is wrong because destroying both stacks maximizes downtime and recovery uncertainty. Instructing all users to avoid the feature until next quarter without engineering action is wrong because business workarounds do not restore service and skip engineering accountability. After rollback, run a defect analysis using correlated traces from the failed canary.