An agent executes a three-step pipeline: (1) update a configuration file via MCP tool, (2) push the change to a branch via MCP tool, (3) merge the branch via MCP tool. Step 2 succeeds, but step 3 fails with a merge conflict error. What rollback strategy should the agent implement?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A merge conflict is not a data integrity failure — it's a coordination problem. The branch and the change are safe; the only issue is that main moved while your agent was working. Rolling back completed steps wastes work. The right call is to preserve what succeeded, address the conflict directly or escalate, and only undo completed steps if explicitly instructed.
Full explanation below image
Full Explanation
Rollback strategy in agentic pipelines depends on the nature of the failure. A merge conflict is not a signal that previous steps were wrong or harmful — it is a signal that concurrent changes created an incompatibility that requires resolution, not undoing.
Option A is wrong. Deleting the branch removes valid, completed work without cause. The configuration update and branch push succeeded; those steps produced correct output. Starting over from step 1 wastes work that was already completed correctly and may introduce new inconsistencies if the environment changed between runs.
Option B is correct. When step 3 fails with a merge conflict, the correct posture is: preserve the work from steps 1 and 2 (the branch with the configuration change is safe and correct), do not roll back completed steps (there is nothing to roll back — the prior steps are not the cause of the failure), and address the conflict. The agent should attempt programmatic conflict resolution if it has the context and capability to do so safely. If the conflict requires human judgment (e.g., overlapping semantic changes), escalate to a human rather than guessing.
Option C is wrong. Reverting the configuration file change from step 1 is unnecessary — that change is correct. Pushing a revert commit to resolve a merge conflict with main does not fix the conflict; it just changes the content on the branch. And it destroys the intended change that the entire pipeline was built to make. This conflates "addressing a merge conflict" with "abandoning the task."
Option D is wrong and dangerous. Force-pushing main to a previous commit overwrites repository history for all collaborators, deletes any commits that merged to main after the agent's branch was created, and is a destructive irreversible action. This is never an appropriate automated agent action and would require explicit human authorization even if attempted manually.