This is my submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
AI agents are becoming capable of doing real work: editing files, modifying databases, and executing multi-step workflows. But when an agent makes a mistake, recovering from it can be surprisingly difficult.
An agent might delete a file it shouldn't have touched, overwrite important content, or modify the wrong resource. Knowing that something went wrong isn't enough. We need a reliable way to undo the damage.
That's why I'm building Mercy — universal undo and recovery infrastructure for AI agents.
Mercy is designed to let AI agents recover from their own actions through snapshots, action journals, and undo operations. Instead of relying on an agent to remember what it changed or generate a fix, Mercy records the information needed to reverse supported actions.
I'm starting with filesystem operations and database integrations, with an extensible adapter architecture that can support additional tools and resources.
The idea is simple: AI agents should be able to make mistakes without making recovery a nightmare.
Who would pay for it?
Mercy is designed for developers and teams building AI agents that interact with real-world resources, including:
- AI coding tools: Recover files after an agent overwrites or deletes the wrong code.
- AI automation platforms: Reverse unintended changes made during automated workflows.
- Enterprise AI teams: Build safer agents that interact with internal systems and business data.
- Agent framework developers: Integrate recovery capabilities without implementing custom rollback logic for every resource.
The long-term business opportunity is to offer Mercy as a developer-focused SDK and MCP integration, with potential hosted infrastructure for teams that need centralized recovery, monitoring, and operational controls.
Demo
Code
GitHub: github.com/yogesh201sits/mercy
How I Built It
Mercy is built with TypeScript and Bun using a modular architecture.
The core is designed around a few key components:
- Action Journal: Records supported operations and the information needed for recovery.
- Snapshots: Preserve resource state before changes so previous content can be restored.
- Undo Engine: Uses recorded action information and snapshots to reverse supported operations.
- Adapters: Encapsulate resource-specific behavior, starting with the local filesystem and PostgreSQL.
- Runtime and SDK: Provide a reusable interface for applications integrating Mercy.
- MCP integration (in development): The goal is to expose Mercy's recovery capabilities to AI applications through the Model Context Protocol.
Each resource has different recovery requirements. Restoring a file is not the same as reversing a database operation, so adapters handle the resource-specific details while the core coordinates the recovery process.
I'm also exploring agent-based testing to simulate realistic scenarios: an agent changes a file, makes another modification, or deletes a resource, and Mercy is tested on whether it can restore the earlier state.
The goal is to make recovery a reusable infrastructure capability rather than something every agent developer has to build from scratch.
Why Does Open Innovation Matter?
AI agent infrastructure should not be locked into a single model provider or agent framework.
Open innovation makes Mercy useful across different AI stacks. Developers should be able to choose their preferred model, framework, and tools while still having access to recovery capabilities.
It also makes the architecture extensible. Developers can implement adapters for their own resources and define how supported operations should be reversed, instead of waiting for a closed platform to support every integration.
Most importantly, open-source development lets people inspect how recovery works, test its behavior, contribute adapters, and identify limitations before trusting it with important data.
For infrastructure that deals with potentially destructive actions, transparency and extensibility matter.
Top comments (0)