Case Study 01 · Agentic AI · Commute Risk Prediction

Saarthi AI

How a 4-person team built a proactive commute-planning agent for Lucknow that uses MongoDB MCP as agent memory, for the Google Cloud Rapid Agent Hackathon (MongoDB Partner Track).

By Sameer Singh · 2026-03-15 · 7 min read

GitHub ↗ Live Demo ↗ Read the blog write-up →

The problem

In Indian cities, commute delay isn't just traffic. Rain, religious events and processions (Bada Mangal, Muharram), railway-station congestion, stadium events, and police diversions all move the needle, and most navigation apps are reactive — they tell you about a jam once you're already in it, and they have no memory of your past trips. Saarthi AI was built to answer a different question upfront: "When should I leave, and what hidden local factors should I worry about?" — as an agent with memory, not a static ETA lookup.

Approach

  1. User enters origin, destination, arrival deadline, and travel mode.
  2. Locations are geocoded within Lucknow using TomTom and Geoapify.
  3. The agent simulates multiple future departure times using TomTom's departAt routing to build a full ETA curve rather than a single estimate.
  4. In parallel, it checks rain forecast (Open-Meteo), festivals (Calendarific plus a curated Lucknow calendar), public events (Ticketmaster), and police advisories (DuckDuckGo search).
  5. All of that is fused into a deterministic, auditable 0–100 risk score — traffic delay, rain, festivals, events, and advisories are weighted and combined transparently, not hidden inside an LLM.
  6. Gemini, orchestrated through Google ADK, synthesizes the final verdict and narration on top of that deterministic score — the model explains the number, it doesn't invent it.
  7. The result is written to MongoDB Atlas as commute history.
  8. An "Ask Saarthi" chat agent then lets users ask follow-ups — using MongoDB MCP tools (find, aggregate, list-collections) to query historical commute patterns, e.g. "Which day is worst for my Charbagh commute?"

Why the core output is deterministic, not LLM-guessed

The risk score is computed with plain, inspectable arithmetic before the LLM ever sees it. Gemini's job is narration and follow-up Q&A over that score and the commute history in MongoDB — not deciding the number itself. That split keeps the core output auditable even though the conversational layer is generative.

Tech stack

  • Google ADK (LlmAgent + InMemoryRunner)
  • Gemini (Groq fallback)
  • MongoDB Atlas
  • MongoDB MCP Server
  • FastAPI + Server-Sent Events
  • TomTom Routing API
  • Open-Meteo
  • Calendarific
  • Ticketmaster API
  • Leaflet / OpenStreetMap
  • Docker on Hugging Face Spaces

Results

  • 121 passing unit tests (pytest), including a dedicated MCP smoke test that verifies the MongoDB MCP server exposes find, aggregate, and list-collections.
  • Deterministic, auditable 0–100 risk score instead of an opaque LLM guess.
  • Degrades safely under live-API failure via caching, fallback LLM providers, and deterministic fallback summaries.
  • Built and shipped within the Google Cloud Rapid Agent Hackathon, MongoDB Partner Track timeline.

Sameer's contribution

Sameer's contributions: agent knowledge grounding, Lucknow event intelligence and local commute-risk research, agent response validation, test coverage, and demo scenario preparation.

Team