PatchPilot

PatchPilot
ngrok
dashboard
description
ci.yml
pull requests
github repo
firestore console
actions
webhooks
main.py

Inspiration

Every failed CI build costs a developer the same fixed 15 minutes: open the run, scroll past noise to find the real error, figure out what broke, fix it, push again — even when the fix is small and mechanical. We wanted an agent that actually does that triage instead of just summarizing it.

What it does

PatchPilot watches a repo's GitHub Actions runs. When one fails, it:

Diagnoses the root cause from the raw CI logs, using past incidents for that repo as context so recurring failures are recognized, not re-derived from scratch.
Proposes a minimal, targeted fix — or explicitly declines if it isn't confident.
Validates its own proposed fix with an adversarial second pass before it's allowed to become a PR.
Opens a pull request with the fix and its reasoning, or comments the diagnosis on the commit if no safe fix exists.

It never auto-merges — a human always reviews the PR.

How we built it

Three Google ADK agents (log_analyzer, patch_generator, validator), each with structured Pydantic outputs, chained in a SequentialAgent pipeline running Gemini 3.5 Flash. A FastAPI service on Cloud Run receives GitHub's workflow_run webhook, publishes the job to Pub/Sub (since a 3-call LLM pipeline plus GitHub API round-trips regularly exceeds GitHub's ~10s webhook timeout), and a second Cloud Run worker picks it up and runs the pipeline asynchronously. Firestore stores a per-repo incident history that acts as lightweight cross-run memory for the diagnosis stage.

Challenges we ran into

Keeping the agent from guessing: the validator stage exists specifically because a single LLM pass will confidently patch things it shouldn't. Splitting diagnosis → patch → validation into separate agents made it much easier to reject low-confidence or off-target fixes before they ever reach a human's PR queue.
GitHub's webhook timeout vs. a multi-minute pipeline — solved by decoupling receipt (webhook) from processing (Pub/Sub-triggered worker).

What we learned

Multi-agent pipelines are much safer than single-shot prompting for anything that takes real action — having a dedicated adversarial validator agent catch the patch generator's mistakes made a measurable difference in how often we'd trust the output.

What's next for PatchPilot

Vector-embedding-based similarity search over past incidents for better recurring-failure detection, a GitHub Check Run UI for live pipeline progress, and monorepo support with per-package diagnosis scoping.

Built With

cloud-run
docker
fastapi
firestore
gemini
github-api
google-adk
pub-sub
pygithub
python
vertex-ai

Submitted to

All Things Agentic Hackathon

Created by

I worked on the backend and deployment side — wiring the agent pipeline up to Gemini, getting Firestore and the GitHub webhook talking to each other, and debugging the whole thing end-to-end until real pull requests started showing up on their own. This was my first time deploying anything on Google Cloud, so there was a lot of trial and error with billing, quotas, and permissions — but watching PatchPilot open its first real PR by itself made it worth it.

Aanya Dhuriya
I worked on the agent design side — figuring out how the three agents should be split up (one to diagnose the failure, one to write the fix, one to double-check it before anything goes out) and writing the prompts that guide each one. It was my first time designing a multi-agent system like this, and getting the validator to actually catch bad fixes instead of approving everything took a few tries — but that's the part that makes the whole thing safe to run without a human watching every step.

Abhishek Pandey