A multi-agent pipeline partially completes a production database migration before Agent 3 fails mid-task. The team attempts to recover, but discovers there is no mechanism to reverse Agent 1's and Agent 2's already-completed changes. The database is now in a partially migrated, inconsistent state. Which recovery pattern was MISSING from this pipeline's design?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Imagine renovating a house where the electrician and plumber finish their work, then the drywall contractor fails halfway through — and you have no way to un-do the walls that were already closed up. In multi-agent pipelines touching shared state, every partially completed state must be reversible. That means snapshots before each agent runs, or wrapping the whole operation in a transaction.
Full explanation below image
Full Explanation
Partial failure is an unavoidable reality in complex multi-agent pipelines, especially those that touch external state like databases, cloud infrastructure, or file systems. The critical design question is: when Agent N fails after Agents 1 through N-1 have already applied changes, can the system return to a known-good state?
Why B is correct: Two rollback patterns apply here: (1) Transactional rollback — wrap the entire multi-agent operation in a database transaction (if the datastore supports it) so that an uncommitted failure at any point automatically reverts all changes within that transaction boundary. (2) Checkpoint-based rollback — before each agent applies changes, capture a snapshot of the current state (a database dump, a Git commit, an infrastructure state file). On failure, the orchestrator triggers a revert to the most recent snapshot. Both patterns require designing rollback into the pipeline from the start — it cannot be retrofitted after a failure has occurred.
Why A is wrong: Retrying Agent 3 might fix a transient failure, but it does not address the state left by Agents 1 and 2. If Agent 3's failure is not transient — for example, it fails due to a logic error or incompatible schema — retrying it repeatedly still leaves the database in an inconsistent partial state.
Why C is wrong: Paging an on-call engineer is an escalation mechanism, not a recovery mechanism. It gets a human aware of the problem but does not provide them with a way to actually reverse the damage if no rollback infrastructure was designed. Alerting without rollback capability is detection without recovery.
Why D is wrong: Staging environment testing reduces the likelihood of failure in production but does not eliminate it. Any failure that slips through to production still leaves the system without a recovery path if rollback was not designed in. Staging is a risk-reduction strategy, not a recovery pattern.
The exam takeaway: multi-agent pipelines that mutate shared state must design rollback in from the start — either via transactions that auto-revert, or checkpoints that enable controlled restoration. Recovery patterns cannot be added as an afterthought.