This post was created for my submission to the All Things Agentic hackathon, Taskmaster track.
As a student practicing DSA, figuring out which problem to solve next is very time consuming .
I could ask Gemini, but it gives generic answers. It doesn't know what I've already solved. A spreadsheet that tracks my progress can tell me what I've done, but it can't tell me what to do next. Deciding that myself eats up time I'd rather spend actually solving problems.
So I built dsa-agent , it recommends what problem to solve next, based on my solve history. Once I'm done, I commit the solution, and it gets ticked off automatically on my Notion tracker.
How it works
When I commit on the terminal, it fires a GitHub webhook that hits a FastAPI backend. The backend logs the solved problem to Firestore, which holds my full solve history. From there, a two-agent ADK pipeline kicks in: one agent reads the history and decides what to recommend next, the other formats that recommendation into clean output instead of raw JSON. That's what shows up on the UI which is still simple for now, but I plan to build it out further.
Why two agents, not one
I split the recommendation logic and the formatting logic into separate agents on purpose. Putting both jobs on a single agent overloads it, it has to reason about history and produce strict, clean output at the same time, and in practice that combination gets chaotic and messy. Separating them keeps each agent focused on one job, and the output stays predictable.
Why Firestore over local JSON
I originally stored history in a local JSON file, but that gets wiped if the container restarts which meant losing all progress with no warning. Firestore fixes this: history is saved permanently unless I explicitly delete it.
One tap, straight to the problem
I didn't want the recommendation to just tell me what to solve next, I wanted to be able to act on it immediately. So the recommendation card now shows the problem title as a clickable link. Tap it, and it takes you straight to that problem on LeetCode.
Under the hood, the link is generated from the problem name itself rather than stored anywhere LeetCode URLs follow a predictable pattern (lowercase, spaces replaced with hyphens), so a small helper function builds the link on the fly. The recommendation agent attaches it to the problem it picks, and the formatter agent carries it through to the final output, where the UI renders it as a tappable link right under the problem name.
The backend is deployed on Render , Cloud Run was the original plan, but billing confirmation failed on two cards and hackathon credits didn't arrive in time, so I switched over rather than lose build time to it. The frontend, for now, only runs locally , haven't deployed it yet, so testing it live means running it on your own machine, or hitting the Render-hosted /recommend endpoint directly through something like Postman.
Why two agents, not one - the real reason
I didn't split recommendation and formatting into two agents by default. I tried combining them first one agent using a history-reading tool and enforcing a strict output schema at the same time. In practice, that combination was unreliable: mixing tools and output_schema on a single agent got flaky depending on the ADK version, sometimes breaking the structured output. Splitting it into two agents one focused purely on reasoning over history, the other purely on formatting fixed that. It's not just a "cleaner architecture" choice; it's a fix for a failure I actually hit.
what's next
Right now, the recommendation agent works off my solve history what I've solved and what's still open on my NeetCode 150 list. It's not yet tracking things like which patterns I'm weak in, difficulty progression, or how many attempts a problem took me. That's the honest current state: it's more useful than a static spreadsheet or a generic prompt to Gemini, because it knows my history but it's not doing deep personalization yet. That's the most important thing I want to build next.
Reflection
Building this taught me a lot , fixing bugs here and there, figuring out why something silently failed, digging into API changes I didn't expect. It's a great feeling seeing it actually work end to end. And this isn't where I'm stopping , I want to keep making it better in the time ahead.
