Case study / Agentic AI

Traffic apps show "now."
I wanted "should I leave."

Every map app tells you what traffic looks like right this second. None of them tell you what it'll look like at the moment you'd actually leave, or that there's a procession on your route because of a festival the app has never heard of. So I built one that does.

RoleSolo build
StackGoogle ADK, Gemini, FastAPI, MongoDB
Tests121 passing unit tests
LinksGitHub repo →
Saarthi-AI pipeline: fused signals to recommended departure window Traffic · Weather Festivals · Events TomTom / Open-Meteo / Calendarific / Ticketmaster Deterministic risk score (0–100) LLM narration Gemini / Groq fallback Departure window recommendation
Saarthi-AI pipeline — math first, LLM narration second

The itch

Commuting in an Indian city like Lucknow isn't just about congestion — it's weather, festival processions, local events, and police advisories, all stacking on top of ordinary traffic in ways that shift week to week. Mainstream navigation apps are reactive: they tell you what's happening right now, at the moment you open the app, not what's going to happen in the thirty minutes between now and when you'd actually leave the house. By the time congestion shows up on the map, you're already stuck in it.

What already existed

The big navigation platforms are excellent at real-time and historical-average traffic, but none of them are built to simulate "what if I leave at 5:45 vs. 6:15 vs. 6:45" as a first-class question, and none of them fold in hyperlocal signals like a religious procession or a stadium event that's about to shut down a street you use every day. They also don't remember you — every query starts from zero, with no memory of your actual commute history.

An app that only tells you what traffic looks like right now is answering a question you didn't ask. I wanted to know when to leave, not what's happening if I don't move.

How I actually built it

The core idea is to simulate the future, not report the present. Saarthi-AI uses the TomTom routing API to run the same route across multiple candidate departure times, so instead of one "traffic right now" answer, it produces a real comparison across the windows you're actually choosing between.

On top of that, I fused in weather (Open-Meteo), festival calendars (Calendarific), local events (Ticketmaster), and police advisories into a single risk signal per route-and-time combination.

Math first, LLM second

The decision I care most about in this build: risk scoring is deterministic, computed as an auditable 0–100 score from the fused signals before any LLM is involved. The LLM — Gemini, with a Groq fallback for resilience if Gemini is unavailable — only narrates the reasoning in plain language afterward. I did this on purpose: an LLM hallucinating a traffic score is a real failure mode, and a commute tool that's confidently wrong is worse than one that just shows you the raw numbers. Keeping the scoring deterministic means the output is testable and explainable, not a black box you have to trust blindly.

Commute history gets stored in MongoDB Atlas as agent memory, exposed through MCP tools so the agent can query your own historical patterns — the more you use it, the more it knows about your actual commute, not a generic average one. The backend runs on FastAPI with Server-Sent Events for live updates, with a Leaflet-based map frontend, all deployed via Docker on Hugging Face Spaces.

The numbers

  • 121 passing unit tests plus MCP smoke tests verifying MongoDB tool availability — because a routing tool people rely on daily has to actually be reliable
  • Risk fused from traffic, weather, festivals, events, and police advisories into one deterministic 0–100 score
  • Multiple simulated future departure windows per query, not just current-conditions ETA

Why it matters

Most "AI agent" demos lean entirely on the LLM to reason about everything, including things that should just be math. Saarthi-AI was my attempt to build an agent the boring, correct way: deterministic computation for anything that can be computed, and the LLM reserved for the one thing it's actually good at — explaining a decision in language a person can act on quickly.

FAQ

What is Saarthi-AI?

A predictive commute-planning agent for Lucknow. It simulates multiple future departure times with the TomTom routing API and fuses traffic, weather, festival, event, and advisory data into a deterministic risk score, then uses an LLM to explain the recommendation.

Why is the risk score computed before the LLM instead of by the LLM?

Computing the 0–100 risk score deterministically from the fused data sources first, then having the LLM only narrate that score in plain language, keeps the output auditable and testable. An LLM hallucinating a traffic risk number is a real failure mode this design avoids.

What data sources does Saarthi-AI combine?

TomTom for routing, Open-Meteo for weather, Calendarific for festival calendars, Ticketmaster for local events, and police advisories, all fused into a single deterministic risk score per route and departure time.

What tech stack powers Saarthi-AI?

Google ADK's LlmAgent, Gemini with a Groq fallback, a FastAPI backend with Server-Sent Events, a Leaflet-based map frontend, and MongoDB Atlas for commute history as agent memory, deployed via Docker on Hugging Face Spaces with 121 passing unit tests.