After deploying an agent that performs multi-step database migrations, you notice that when a tool call fails midway through a migration sequence, the agent stops but leaves the database in a partially-migrated state. Subsequent runs fail because they cannot reconcile the partial state. Which design change directly addresses this problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A partial-state failure in a multi-step process is exactly the problem that rollback mechanisms were invented to solve. Think of it like a bank transfer: if you debit one account but the credit fails, you don't just stop — you reverse the debit. For an agent running a migration sequence, rollback means 'if anything fails, undo all the steps I already completed and return to the last known good state.' Idempotency (option D) is useful for retries but doesn't undo already-applied changes.
Full explanation below image
Full Explanation
When an agent executes a multi-step process where each step modifies external state (database rows, file system, infrastructure resources, etc.), it is operating as a distributed transaction. If any step fails, the system may be left in an inconsistent intermediate state that neither reflects the starting state nor the intended end state.
The solution is a rollback mechanism: the agent must maintain a record of the steps it has successfully completed and, upon detecting a failure, invoke compensating actions that undo each completed step in reverse order, restoring the system to a consistent known-good state. This can be implemented as: - A rollback tool registered in the agent's tool set that accepts a transaction log. - Compensating tool calls executed in reverse order (e.g., if step 2 applied migration M002, rollback calls revert-migration M002). - Checkpointing — save state before each step so rollback has a clear target.
Why the other options are wrong:
Option A — Better error messages in the system prompt improve the agent's ability to diagnose failures but do not cause it to take corrective action. The agent still stops with partial state applied — it just produces a more readable error. Diagnosis and remediation are separate concerns.
Option C — Increasing the tool call budget gives the agent more steps to execute, not a way to reverse already-executed steps. If anything, allowing more tool calls without a rollback mechanism increases the risk that more state changes will be applied before a failure aborts the run, making the partial state worse.
Option D — Idempotency ensures that running a step multiple times has the same effect as running it once — it prevents double-application on retry. This is an important design property for tools, but it solves a different problem: safe retries. It does not undo steps that already succeeded before the failure point. Idempotency and rollback are complementary but distinct; this scenario specifically needs rollback to clean up partial state, not safe re-execution of the failed step.