Inspiration
AutoMend started with a simple question: what if software could fix itself?
Our team got on a call to decide what we wanted to build for the hackathon, and we spent almost an hour discussing different ideas. Harshit Bisht came up with the idea of a self-healing code runner on a GPU. The idea was that if something running on the GPU stopped because of an error, memory issue, or some other failure, an agent could figure out what went wrong and take the necessary steps to recover it.
We really liked the idea of software being able to detect its own failures and actually respond to them. As we discussed it further, we decided to explore the same idea in a backend environment where we could build the complete recovery loop using real infrastructure.
That led us to AutoMend.
What it does
AutoMend watches a backend service running on Google Cloud Run. When something goes wrong, it does not just alert a developer.
It automatically:
- Detects the failure
- Diagnoses the cause
- Selects a safe recovery action
- Executes it
- Verifies the service
- Records the incident
For example, if a bad deployment causes an error spike, AutoMend can detect the failure, use Gemini to diagnose the likely cause, roll back to the last known good revision, check whether the service has recovered, and record the entire incident in Firestore.
How we built it
After deciding on the idea, we divided the project into three major parts so we could work in parallel.
Harshit Bisht worked on the Target Service and Watcher. He built the backend service with controlled failure triggers and a Watcher that monitors Cloud Logging and Cloud Monitoring, classifies failures, and sends structured failure events to the Orchestrator.
Srivarshini S worked on the Diagnosis Agent using Gemini and Google's Agent Development Kit (ADK). The agent receives the failure event, reasons about the likely cause, and selects a recovery action. We restricted it to a fixed set of pre-approved actions so that it cannot execute arbitrary commands.
Md. Hanan Sajid worked on the Orchestrator, infrastructure, recovery execution, and reporting. The Orchestrator connects the entire pipeline, executes recovery actions through the Cloud Run Admin API, verifies the service after recovery, and stores the incident lifecycle in Firestore.
We kept the communication between the components simple and clearly defined through fixed API contracts. This allowed all three of us to develop independently and integrate everything later without constantly changing each other's code.
Challenges we ran into
One of the biggest challenges was making the system reliable beyond just getting the AI response to work.
We had to handle things like structured outputs, validation, authentication, API failures, timeouts, infrastructure changes, and recovery verification. For example, we had to ensure Gemini's responses were always valid JSON with exactly the right fields—otherwise the Orchestrator would reject them and fall back to a safe default.
Another important challenge was deciding how much control to give the agent. We did not want Gemini to be able to generate arbitrary commands and send them directly to our infrastructure.
Instead, we created a closed set of recovery actions. The Diagnosis Agent can reason about the problem, but it can only return one of the actions that we have explicitly approved. Invalid outputs are rejected and handled through deterministic fallbacks.
We also had to make sure that a recovery was actually successful. Simply executing a rollback does not mean the service is fixed, so AutoMend checks the service health after every recovery action.
Accomplishments that we're proud of
We are most proud of building a complete end-to-end autonomous recovery loop instead of just an AI demo.
A real failure can move through the entire system:
Failure → Detection → Diagnosis → Recovery → Verification → Audit
The system can work with a live Cloud Run service, use Gemini for diagnosis, make real infrastructure changes through the Cloud Run Admin API, and store the complete incident history in Firestore.
In our testing, AutoMend successfully recovered from simulated failures in under 90 seconds on average, compared to the 15+ minutes it would typically take for a developer to detect, diagnose, and manually roll back.
We are also proud of the way we divided the work. Since the three components had clear contracts, we could work on different parts at the same time and bring them together during integration.
Most importantly, we built an agent that does more than explain a problem. It actually takes responsibility for recovering the service.
What we learned
This project taught us that building an agent is about much more than putting an LLM into a pipeline.
We learned the importance of structured outputs, clear contracts, validation, authentication, timeouts, idempotency, and verification.
We also learned that giving an agent boundaries is just as important as giving it intelligence. Gemini is responsible for reasoning about the failure, but the Orchestrator is the only component allowed to modify the infrastructure.
Working as a three-person team also taught us how important it is to define interfaces early. Once our contracts were fixed, each of us could build our part without waiting for the others.
What's next for AutoMend
Right now, AutoMend focuses on Google Cloud Run, but the idea can go much further.
We want to explore MCP-based tool connections so that AutoMend can work with different infrastructure providers instead of relying on hardcoded API integrations.
We also want to add support for monitoring platforms such as AWS CloudWatch, along with integrations for PagerDuty and Slack. This could allow AutoMend to escalate incidents when autonomous recovery is unsafe or unsuccessful, while also giving engineers the option to take control when needed.
Our long-term goal is simple: make backend systems more resilient by giving them the ability to detect, understand, and recover from failures on their own. This isn't just automation—it's a fundamental shift toward autonomous infrastructure.
Log in or sign up for Devpost to join the conversation.