Building Saarthi AI: giving a commute-planning agent memory with MongoDB MCP
Notes from building Saarthi AI at the Google Cloud Rapid Agent Hackathon — why we kept the risk score deterministic, what MongoDB MCP actually bought us over a normal database call, and what broke during the demo.
Why a commute planner needed memory at all
Most traffic apps answer one question: how long will this route take right now. That's fine until you actually live somewhere like Lucknow, where the thing that wrecks your ETA on a given day is rarely just traffic — it's a Bada Mangal procession, a stadium event two kilometers from your route, or a railway-crossing closure nobody put in a map. We wanted Saarthi AI to answer a different question upfront: when should you leave, and what should you actually be worried about today.
That meant the agent needed two things a stateless ETA API doesn't have: a way to fuse several unrelated signals into one number, and a memory of past commutes so it could answer follow-up questions like "which day is usually worst for my Charbagh commute?"
Keeping the risk score boring on purpose
It would have been easy to hand all the signals — traffic delay, rain, festival calendar, event feeds, police advisories — straight to Gemini and ask for a risk score. We didn't do that. The 0–100 risk score is computed with plain weighted arithmetic before the model ever sees it, so it's inspectable: you can look at the breakdown and see exactly why a commute scored 72 instead of 40.
Gemini, wired up through Google ADK, only comes in after that — narrating the score and answering follow-ups over MongoDB-stored commute history. Letting the LLM narrate instead of decide turned out to be the single best architectural call in the project: it kept the core output auditable during hackathon judging, and it made debugging bad scores tractable instead of a black-box guessing game.
What MongoDB MCP actually bought us
We used the MongoDB MCP server to expose find, aggregate, and list-collections as tools the agent could call directly, instead of hand-writing a retrieval layer between the LLM and the database. The practical win was in the "Ask Saarthi" follow-up chat: a question like "which day is worst for my Charbagh commute" turns into an aggregate call the agent constructs itself against commute_history, rather than a route we'd have to pre-anticipate and hardcode.
We shipped a dedicated MCP smoke test just to verify the server actually exposed those three tools before we trusted anything built on top of it — a small thing, but it caught a misconfiguration during setup that would otherwise have failed silently mid-demo.
Degrading safely when the live APIs didn't cooperate
Saarthi leans on five external services in parallel — TomTom, Open-Meteo, Calendarific, Ticketmaster, and a DuckDuckGo search for police advisories. Any hackathon demo that depends on five live third-party APIs during a scheduled judging slot is one flaky connection away from disaster, so caching, a Groq fallback for Gemini, and deterministic fallback summaries were not optional polish — they were what let the demo run at all when one provider rate-limited us mid-session.
Team & credit
Saarthi AI was a four-person build for the Google Cloud Rapid Agent Hackathon, MongoDB Partner Track. Saksham Pathak — who goes by Parthmax — led the team and owned UI/UX; Aishrica Dhiman handled data analysis; Urmila Saini built the agentic tool orchestration and MongoDB MCP setup; I focused on agent knowledge grounding, Lucknow event-risk research, response validation, and the 121-test suite that kept us honest while the rest of the system was still moving. 121 tests passing end to end, with a dedicated MCP smoke test, is the number I'm proudest of from this build.