1 min lesson
Recover from failed agent edits
Match partial application, conflicts, stale anchors and repeated failures to a visible recovery path.
Step 1 of 2
Failure handling
A multi-file edit can fail after some changes have landed, conflict with newer user work or repeat the same unsuccessful action. Give each case a visible recovery path.
- Failure
- Partial application
- What goes wrong
- A later tool fails after earlier files changed
- Recovery
- Show what changed, restore the Agent checkpoint when needed and retry a smaller step
- Failure
- Conflicting edit
- What goes wrong
- The user changed a region during the run
- Recovery
- Detect the mismatch, read the current buffer and regenerate the affected change
- Failure
- Stale anchor
- What goes wrong
- The target lines moved after the edit was prepared
- Recovery
- Anchor to surrounding content or syntax nodes and verify the matched location
- Failure
- Repeated failure
- What goes wrong
- The loop proposes the same unsuccessful action
- Recovery
- Detect repetition, cap attempts and return the evidence and blocker
| Failure | What goes wrong | Recovery |
|---|---|---|
| Partial application | A later tool fails after earlier files changed | Show what changed, restore the Agent checkpoint when needed and retry a smaller step |
| Conflicting edit | The user changed a region during the run | Detect the mismatch, read the current buffer and regenerate the affected change |
| Stale anchor | The target lines moved after the edit was prepared | Anchor to surrounding content or syntax nodes and verify the matched location |
| Repeated failure | The loop proposes the same unsuccessful action | Detect repetition, cap attempts and return the evidence and blocker |
Interview move
Trace one action through plan, act, observe and verify. Then show how the user reviews the diff, how current buffer changes are protected and what an Agent checkpoint can restore. Keep checkpoint claims within the documented limit that they cover Agent changes only.