This is a submission for the Google AI Agents Writing Challenge: Learning Reflections

Introduction: The "Aha!" Moment

Before taking the 5-Day AI Agents Intensive Course by Google and Kaggle, I viewed AI primarily as a chatbot—a passive entity waiting for a prompt. I asked, it answered. But as I moved through the modules, specifically learning about Tooling and Reasoning Loops, my perspective shifted entirely.

I realized that AI doesn’t just have to talk; it can do.

This realization culminated in my capstone project: The Self-Healing AI Agent System. I wanted to answer a specific question: If an AI Agent can write code, can it also fix itself when it crashes?

The Problem: AI as a "Black Box"

One of the key takeaways from the course was the importance of Observability. When we build complex systems, things break. Usually, when software crashes, it spits out a long, messy stack trace that looks like gibberish to non-developers (and sometimes even to developers!).

I learned that while we can use AI to write code, the debugging process is still manually intensive. I wanted to close that loop.

The Solution: An Autonomous AI Team

Applying the Multi-Agent Systems concepts from the course, I designed a system that mimics a real-world engineering team. Instead of one giant AI trying to do everything, I broke the problem down into three distinct roles.

The Architecture

1. Agent A (The Patient): This is a research agent I intentionally designed with flaws (like tool type mismatches) so it would generate complex crashes.
2. Agent B (The Doctor): An observability agent. Using the Google ADK, I gave it custom tools like read_log_file and find_last_error_in_trace. Its only job is to diagnose why the patient died.
3. Agent C (The Surgeon): The software engineer. This agent has "dangerous" tools like read_code_file and apply_fix_to_file. It takes the Doctor’s diagnosis and actually rewrites the Python source code to fix the bug.

Key Learnings & Challenges

1. The Power of "Tools"

The most significant learning curve was defining Tools. The course taught me that an agent is only as good as the tools you give it.

• Challenge: Initially, the "Surgeon" agent would hallucinate fixes that didn’t match the file structure.
• Fix: I had to implement robust file I/O tools (read_code, apply_fix) that acted as guardrails, ensuring the agent interacted with the file system correctly.

2. Multi-Agent Orchestration

I learned that agents need to collaborate asynchronously. I used a file-based state system where the "Doctor" leaves a diagnosis note that the "Surgeon" picks up. This decoupled architecture made the system much more resilient than trying to pass massive prompt contexts back and forth.

3. Observability is King

Using the LoggingPlugin from the ADK was a game-changer. It allowed me to capture deep execution traces. The "Doctor" agent could essentially "read the mind" of the crashed agent by analyzing these logs, turning raw data into actionable insights.

The Result

The final result is a system where a crash turns into a fix in about 10 seconds, completely autonomously.

• Crash: The Patient fails.
• Diagnose: The Doctor identifies the root cause (e.g., "TypeError in line 45").
• Heal: The Surgeon rewrites line 45.

Seeing the gemini-2.5-flash-lite model successfully edit its own source code to recover from a crash was a definitive "future is here" moment for me.

Conclusion

The Google & Kaggle Intensive wasn’t just about learning syntax; it was about learning a new paradigm of software development. We are moving away from writing static code to orchestrating intelligent agents that can maintain themselves.

Building the Self-Healing AI Agent System proved to me that the future of software is resilient, self-maintaining, and agentic.

---

Project Links

• Repository: https://github.com/trivedikavya/Self-Healing-AI-System
• Demo Video: https://youtu.be/kbjBXdfiW68?si=BrbYHlNcMMhVv4Yk