What I Learned from Building a Kaggle AI Agents Project

Clinical AI Kit is my attempt to create a system where clinicians can inspect the evidence, tools, uncertainty, and approval boundaries behind every result. You can find all the relevant information about it here:

• Kaggle Writeup - Clinical AI Kit — Kaggle Writeup
• GitHub repository - Google-Capstone-Project
• Interactive application and diagram atlas
• LLM Wiki
• Project Wiki
• Swagger
• ReDoc

Tools Used

Where the Idea Began

If you have ever worked with me, you’d know I am a huge fan of healthcare-based products. I studied psychology and specialized in mental health. One of the longest projects I worked on was a system that helped clinicians treat patients with sleep apnea.

I also previously vibe-coded/engineered another project agenticlibrary.net (which is due for an update), but I never had the motivation to turn one of my ideas into a proper healthcare project.

That was until Google and Kaggle’s “AI Agents: Intensive Vibe Coding Capstone Project” was announced, and I realized I wanted to create a capstone project that would fulfill all the criteria while also having my personal touch.

Product Concept

Anyone who has created an AI project will know that the initial results will be mostly rubbish, regardless of whether you decided to do it with an AI Coding Agent like Claude Code or Codex, or with a pre-built tool like Lovable, Bolt, Base 44, or similar.

This is because, as good as coding agents are right now, they still take the easy route: creating something from known patterns in their training data, but they don't properly search for what similar products look like.

And quite honestly, everyone and their grandmother has seen a RAG-based system in 2026. It was a new solution back in 2023~ but not anymore.

I also didn’t think that a single agentic workflow made sense, because AI without a proper use case and a problem to solve is only a flashy demo without real substance.

Hence why I thought back to the time I helped create another healthcare system that clinicians would use. That got me thinking about how information-dense it was, the number of tabs and navigation options, and the need to store everything in one place.

This is how Clinician AI Kit came to be. The premise is that the system will act as the command center for a clinician who wants more information about their patients.

Back-and-forth with AI

As I worked alone on this capstone project, I didn’t really get to brainstorm with someone else. That’s when AI came into the picture. While I had the original idea, I had a back-and-forth discussion with Claude to grill my idea using the grill-me skill, which required me to reconsider many aspects of the project as I went.

Simply put, while the original idea had substance, it lacked many of the finer details that would make the application usable; it wasn't technically sound and had many missing components that made the agents unusable in the state I had imagined.

After an hour-long session brainstorming how the application would look, I decided to use Claude Design to visualize the idea as a high-fidelity prototype.

Why Is It Different?

Flashy demos and AI-generated websites rely on a lot of non-existent social proof and testimonials, and on a “premium glassmorphism” feel. This one here began by answering the question, “What would a clinical AI product look like if every important action were inspectable?”

And the answers narrowed down to “It must be the overall clinician platform with all the information a clinician would use anyway, while still having access to all the AI functionality they are supposed to.

That also resulted in building three separate Agentic AI solutions that are tightly integrated with the existing information from the platform:

1. A clinician-patient session extraction capability that allows a clinician to upload their session images or PDFs, extract all structured information from them, and use it immediately, while still providing confidence and source evidence.
2. A Patient-specific multi-model RAG system where a clinician can ask a patient-specific question and receive a cited answer grounded in clinician notes, documents, images, and based on patient data retained in a vector database.
3. A database intelligence capability allowing clinicians to ask a question about the hospital’s patient cohort and get a generated read-only SQL query that provides users with patient data and a Pydantic-based visualization from the dataset.

If you were to visualize this whole thing, it would look something like this:

While the capabilities don’t promise HIPAA-compliant data handling, as this is just a POC, the application uses HIPAA-aware design patterns and can be extended into a functional application.

Design Phase with Claude Design

As anyone who has read enough hype articles and seen LinkedIn influencers talk about how big spec-driven development and proper planning is, I thought, “hey, why not directly go for a one-shot prompt to create the overall website?

Needless to say, the final results were pathetically bad. It churned out a generic, AI-sloppy page.

So instead, I worked on a version with Google’s Stitch and created multiple variations with a proper design language (and tokens) file to support UI creation.

This resulted in a much better initial set of artifacts (or few-shot examples) for Claude Design to follow before building any high-fidelity prototype.

In hindsight, if I were making this project from scratch again, I would first create the initial screens, then build a Design System for Claude to consume, create a proper Claude Design, and move to implementation.

Project Scaffolding and Technology Stack

While working on the initial panels and application design, I also set up the project’s scaffolding.

The first decision was to make an overall Architecture choice for what the application would look like despite the fancy Google ADK design, and I decided on this:

1. React clinical interface,
2. FastAPI product and policy layer,
3. Google ADK agent runtime,
4. Tools, retrieval, persistence, MCP, A2A, and audit.

While I would have loved to show you the exact /grill-with-docs, the conversation is long gone, and Claude Code refused to locate the session itself. To summarize, though, the project’s overall tech stack and decisions didn’t come from my own whim (purely because I was the only one working on this project with no external feedback) but came from a back-and-forth discussion alongside Opus 4.6 (since I still think it was better than 4.7 and 4.8 at the time). The final decision regarding the application resulted in this:

In addition to creating my own version of the Karpathy Wiki, Swagger, and Redoc documentation, I used an adjusted version of Agents365-ai/drawio-skill, which helped me create the application's overall architecture diagrams and understand what the project will look like upon completion. This also resulted in the structure of the application’s harness, which looked like this:

End-to-End Documentation of the Project

Main submission links

Application workflows

API and operational endpoints

Source code and technical evidence

Kaggle links

Closing Thoughts

This was a really fun Agentic vibe-coding competition to be a part of, even though I didn't win.

I would most likely repeat something like that in the future as I improve my skill set (and when I am not full of work-related tasks to do, as I am now).

In closing, the Clinical AI Kit began as an attempt to create a vibe-coded product based on multi-modal agent (MAS) architecture that allows clinicians to organize their fragmented clinical data. The result isn’t a medical device application, nor is it HIPAA-compliant. Still, it shows you can use Google ADK to orchestrate agents that help a human find the exact information they need and the exact references it came from.

If anyone wants to play around with the project or extend it, the repo is available here: Google-Capstone-Project.