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?

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 a later agent fails after earlier agents have already applied changes, can the system return to a known-good state?

The correct recovery pattern is a transactional or checkpoint-based rollback mechanism: either wrap the entire multi-agent operation in a transaction that auto-reverts on failure, or capture state snapshots before each agent runs so any agent failure triggers a controlled revert to the last known good state. Two rollback patterns apply here: 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. Checkpoint-based rollback — before each agent applies changes, capture a snapshot of the current state, such as a database dump, a Git commit, or 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.

The retry mechanism on the failed agent so it can re-attempt the migration step up to five times before giving up is wrong because retrying the failed agent might fix a transient failure, but it does not address the state left by the earlier agents. If the 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.

The notification step that pages an on-call engineer when any agent fails, so they can manually assess the damage, is wrong because 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.

Running the pipeline in a staging environment first so failures can be caught before production is wrong because 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.