An agentic system uses Claude as an orchestrator directing 4 subagents to complete a complex software deployment task. The orchestrator issues tool calls to: code_analyzer, security_scanner, test_runner, and deploy_executor. During a deployment, the orchestrator calls deploy_executor after test_runner returns success. Midway through deployment, the orchestrator loses its context window (OOM error in the hosting environment). The deployment is now in an indeterminate state — partially complete. What architectural feature should have been implemented to handle this failure mode?

The saga pattern with compensating transactions is architecturally correct for deployment orchestration. Deployments are not idempotent — you cannot simply replay 'deploy to production' if it partially succeeded. The saga pattern: (1) each deployment step registers both the forward action and its compensating rollback action, (2) if the orchestrator fails at any point, the saga manager (running independently) executes registered rollbacks in reverse order, (3) this restores a known-good state regardless of how far deployment had progressed. This pattern is the industry standard for distributed transactions. Option A (checkpoint-and-resume) is insufficient for deployment: resuming from checkpoint A assumes the state before A is consistent — but if deploy_executor partially executed before failure, resuming mid-deployment may cause conflicts (service running two versions, database migration half-applied). Option B (idempotent tool calls + replay) is incorrect for deployments — most deployment operations are inherently non-idempotent (e.g., 'restart service' called twice causes a second restart, 'run database migration' called twice fails). Designing deployments to be idempotent is possible but requires significant tool redesign. Option D (heartbeat restart) doesn't solve the indeterminate state problem — restarting the orchestrator doesn't resolve what happened to the in-progress deployment.