SelfSurgeon - Autonomous AI Self-Healing Agent

SelfSurgeon autonomously detects failing AI agents, diagnoses broken prompts, generates fixes using Gemini, validates them, and deploys healed prompts — no human intervention needed.

Comment

Inspiration

I kept breaking my own agents.

Every time I changed a prompt or added a new feature, something else would silently fail. Logs were noisy, dashboards were empty, and I only noticed bugs when a test happened to hit the right edge case. I wanted a way for the system to catch its own mistakes instead of waiting for me.

That turned into SelfSurgeon.

What it does

SelfSurgeon watches another AI agent (the "victim") while it runs.
When the victim starts doing the wrong thing, SelfSurgeon:

  1. reads the traces from the victim
  2. finds the failed cases
  3. asks Gemini to explain what is wrong with the prompt
  4. asks Gemini to write a new version of the prompt
  5. tests the new prompt on the old failures
  6. if it works, it saves and marks that as the new prompt

All of this runs as an automated loop on the backend.
The frontend is just a window into that loop: you can see failed traces, the surgery that ran, and the before/after prompt.

How I built it

  • Backend: FastAPI running on Render
  • Victim agent: a simple lead routing model that can be "wrong on purpose"
  • Storage: SQLite file on Render for traces and surgeries
  • LLM: Google Gemini (for diagnosis and prompt edits)
  • Frontend: React + Vite + a dark UI built in Lovable
  • Deploy:
    • backend → Render
    • frontend → Vercel
    • ENV glue with VITE_API_BASE_URL pointing to the Render URL

Most of the work was getting the loop reliable:
making sure traces actually got stored, the observer could find them, surgeries wrote back to the right place, and the frontend always pulled live data instead of mocks.

Challenges

  • Phoenix tracing was flaky in my local setup, so I switched to SQLite to avoid spending the whole hackathon debugging infra.
  • Keeping the story honest: it is easy to fake "self-healing" with hardcoded data. I forced myself to keep real traces flowing end‑to‑end.
  • Getting Google Cloud and Render to behave on a Windows laptop took more time than I hoped.
  • Making the UI show one clear narrative instead of ten different charts and no clear message.

What I learned

  • Observability is useless if traces are not actually being stored where your tools expect them.
  • It is better to ship a simple, honest demo with one clear before/after than a giant system that sort of works.
  • Having a "victim" agent that is broken on purpose is a nice way to test self‑healing ideas.

What's next

  • Swap SQLite for a real observability backend again (Arize Phoenix or similar).
  • Support more failure types than just boundary issues and routing mistakes.
  • Add a safer rollout mechanism (canary style) instead of instant full deployment.

Built With

Share this project:

Updates