dsa-agent
An autonomous agent that watches your DSA practice repo, tracks what you've solved, and recommends what to solve next — no manual logging required.
Live demo: https://dsa-agent-ygpx.onrender.com
Built for the All Things Agentic Hackathon (Taskmaster track).
What it does You solve a problem and commit it with a specific message format (solved: []) A GitHub webhook fires automatically The agent parses the commit, saves it to Firestore, and ticks the matching row in your Notion tracker When you ask "what should I solve next?", a two-agent pipeline reads your history and recommends a problem — matched by pattern and difficulty In your notion , once a problem gets committed , the problem gets ticked in the checklist
No manual tracking. No stale spreadsheets. The agent does the bookkeeping. Architecture GitHub commit (solved: problem [pattern]) | v GitHub Webhook | v FastAPI (Render) --------> Notion API (ticks checklist) | v Firestore (solve_history) | v ADK Agent Pipeline
- recommendation_agent (reads history, suggests next problem)
- formatter_agent (structures output as JSON) | v /recommend endpoint --> structured recommendation Tech stack Gemini 3.5 — via Google ADK Google Agent Development Kit (ADK) — two-agent pipeline (recommendation + formatting) Firestore — persistent state for solve history (survives redeploys/cold starts) FastAPI — webhook listener and API Render — hosting (Docker-based deploy) Notion API — syncs solved problems to a visual tracker
Why two agents instead of one
Combining tools and output_schema on a single ADK agent was version-flaky. Splitting into a recommendation agent (uses tools, freeform output) and a formatter agent (strict JSON schema, no tools) sidesteps that entirely and keeps each agent's job simple.
Findings and learnings The biggest obstacle building this wasn't technical, it was billing. I applied for the hackathon's $150 Google Cloud credit through the official form but never received it in time. I then tried adding two different cards to set up a GCP billing account for Cloud Run, and both failed at the payment step. With no working card and the deadline close, I moved the actual compute to Render's free tier, which doesn't require billing setup, while keeping Firestore as my Google Cloud infrastructure component. It's a real deployment, just not the one I originally planned around Cloud Run. Splitting the ADK agent into two smaller agents (recommend, then format) turned out to be more reliable than trying to get one agent to both call tools and return a strict schema. Smaller, single-purpose agents were easier to debug too. Moving from a local JSON file to Firestore was a small code change but a real shift in thinking. Once I stopped treating the container as a place that remembers things between requests, state management got a lot simpler.
Notes Firestore was chosen over a local JSON file specifically because containers are stateless. A local file gets wiped on every redeploy or cold start. Firestore persists across both. Uses the free tier only, no paid Google Cloud services required to reproduce this project.
Built With
- fastapi
- firestore
- gemini
- google-cloud
- notionapi
- render
Log in or sign up for Devpost to join the conversation.