FG-0512 Error Recovery Protocol
Description
Defined procedures for detecting, containing, and recovering from agent errors during execution. Agents will produce incorrect output, corrupt state, exceed scope, and misinterpret instructions, and they will do so regularly. Error recovery protocols ensure that when failures occur, the response is systematic rather than ad hoc: detect the error, stop propagation, assess blast radius, restore to known good state, and document the incident for prevention.
Implementation
Define error categories (output quality failure, state corruption, scope violation, resource exhaustion) with specific detection criteria and recovery procedures for each. Implement checkpoints at natural boundaries in complex tasks. Establish rollback procedures for every operation that modifies shared state. Document recovery steps so they can be executed by any team member.
Success Indicators
- Errors are detected within minutes rather than discovered days later
- Recovery from any error category takes less than 15 minutes
- Rollback procedures exist and have been tested for all state-modifying operations
- Error frequency decreases over time as patterns are identified and prevented
Failure Modes
- No checkpoints: errors compound through long execution chains before detection
- Recovery procedures that exist on paper but have never been tested
- Panic response: overreacting to errors by rolling back more than necessary or adding excessive process
- Root cause neglect: recovering from the symptom without investigating why the error occurred
Sub-Methods 3
If an automated or AI-driven approach has not produced results within a defined time window, stop and reassess. The timeout prevents the sunk-cost trap where teams invest hours debugging an approach that should have been abandoned in minutes. Define timeouts per task type: 15 minutes for routine operations, 30 minutes for complex debugging, 60 minutes maximum before mandatory reassessment.
Sometimes the correct engineering answer is to do it by hand. When automation fails repeatedly, when the debugging time exceeds the manual execution time, when the edge case is genuinely unique, the manual fallback is not a failure of engineering. It is a recognition that not every problem justifies an automated solution. Document when and why you fell back to manual so the pattern is visible.
When recovering from an error, explicitly identify whether you are fixing the root cause or applying a workaround. Both are valid, but they have different implications. A root cause fix prevents recurrence. A workaround gets you moving but leaves the underlying issue intact. Document which one you chose and why. Workarounds that are not tracked become permanent technical debt.