Accueil / Articles / An AI Commute Agent for Bengaluru That Plans How You Travel

Cet article est publié en anglais.

An AI Commute Agent for Bengaluru That Plans How You Travel

How GoWise composes walk, bus, Metro, auto and cab journeys with graph search and a scoring engine, and keeps Gemini to explanations only, never routing.

1146 mots

Ask any navigation app for a trip and you get one answer: a route. Real commutes in a city like Bengaluru are messier. The quickest way isn't always the cheapest. A slightly longer Metro ride can beat an hour in traffic. Some people won't take a cab or an auto no matter what. And the plan that looked perfect five minutes ago may be wrong now.

That mismatch led to Commute Agent, an AI system that doesn't merely find a route but decides how a person should travel. GoWise is the app commuters actually use. The code is public at https://github.com/ssharanyab/commute-agent.

Strategies, not routes

GoWise is a personalized multimodal planner for Bengaluru. A journey isn't one path from A to B. It's a mix of walking, BMTC buses, Metro, auto-rickshaws and cabs, which can produce chains such as walk, Metro, walk, or walk, bus, walk, or auto, Metro, walk where that suits.

Nobody hardcoded those combinations. The planner searches the mobility network and works out feasible journeys algorithmically.

How the system is split

The central design choice is a firm wall between AI orchestration and deterministic decision-making. In outline:

Flutter / GoWise
       ↓
    FastAPI
       ↓
Google ADK Orchestrator
       ↓
  Journey Builder
       ↓
Live + Historical Enrichment
       ↓
  Decision Engine
       ↓
Gemini Explanation

Flutter supplies the commuter experience. The backend runs the planning workflow, and Google ADK handles orchestration. Here's the rule that matters most: the LLM never picks the route.

Candidate journeys come from graph search

The Journey Builder works over a network of transit stops, stations, connections and walking or access links. Deterministic graph search turns that into feasible multimodal journeys, each with its own blend of modes and transfers.

So nobody asks Gemini something like "what's the best way from Majestic to Indiranagar?" Candidates are generated algorithmically first. That makes planning far more predictable and easy to audit than letting a language model improvise a route.

From candidates to a decision

Producing options is only half the job. Next the system has to decide which option is best for this particular commuter, and a deterministic multi-objective decision engine does it. Commuters can weight different goals: fastest, cheapest, least walking, most reliable, least traffic, or a balance.

The engine scores candidates against those preferences while also enforcing hard limits. Take a user who says to avoid cabs and avoid autos. Those words don't merely make the system dislike the modes. They become constraints that throw out every journey containing them, and the survivors get scored and ranked.

Keeping constraints and preferences apart turned out to be one of the more important design calls.

The data underneath

This isn't a conceptual demo. The network draws on real Bengaluru sources:

  • BMTC GTFS feeds
  • BMRCL Metro network data
  • Government-published auto fares
  • Government policy information
  • Historical mobility data from Uber Movement

Versioned snapshots and provenance tracking sit on top, so a failed refresh can't quietly overwrite a dataset that was working.

What history can and can't say

Historical data yields context signals for a route: expected travel time, how much that time varies, reliability, coverage and deviation from normal conditions. The model is deliberately framed as a route-context estimator and makes no claim to forecast arbitrary future traffic. That honesty matters. An AI system ought to be upfront about what its models know.

Live conditions

History can't describe a trip starting this minute. For road-based segments, GoWise can add Google Maps routing data, which brings current, traffic-aware estimates. The split is clean: history tells you what's normal, and live routing tells you what it looks like right now. The decision engine reasons over the journeys enriched by both.

Gemini's narrow job

Gemini, called through Google ADK, is the explanation layer. After the deterministic engine has chosen a journey, Gemini receives grounded facts about the choice and writes a rider-friendly explanation. That stops the model from inventing route IDs, scores, costs or reasoning nothing supports. Put simply, the system decides and Gemini explains.

Personalization as part of planning

Picture the Majestic to Indiranagar trip with three different riders. One wants the cheapest option. Another doesn't want to walk much. A third refuses cabs and autos. The mobility network stays identical across all three. What differs is the decision context. Personalization here is part of planning itself, not a cosmetic change to the UI.

Where Google Maps fits

GoWise isn't out to replace Google Maps, which is superb at guiding someone along a chosen journey. GoWise tackles the earlier question: which mobility strategy should you pick at all? Maps navigates a route; GoWise decides and composes how you travel, then hands the pick to Maps for turn-by-turn guidance.

Replanning on the fly

A commute doesn't stand still, and when conditions shift enough the first recommendation can stop being the best. The adaptive layer takes the existing journey context, updates the conditions that changed, re-scores the candidates and checks whether another strategy should win. That moves the product from a one-shot route planner toward a mobility decision agent.

Lessons from building it

Bolting on an LLM doesn't automatically produce an AI agent. Most of the hard work turned out to be plain deterministic engineering:

  • Building a mobility graph worth using
  • Finding multimodal journeys that are genuinely different from each other
  • Handling the first and last mile
  • Keeping transit identities intact between planning stages
  • Coping with incomplete data
  • Telling unknown values apart from zeros
  • Designing multi-objective scoring that means something
  • Applying user constraints correctly
  • Keeping explanations tied to what was actually decided

The LLM is one part. The intelligence comes from how all the parts cooperate.

What comes next

There's room to grow: richer real-time transit feeds, finer walking networks, more mobility providers, stronger planning over time, learned personalization and bigger datasets. The long-range aim isn't a nicer route planner. It's a system that grasps the commuter, the network, the current context and the trade-offs among ways of getting around.

The better question

We've gotten very good at asking for the fastest route, but that often isn't what a commuter wants to know. A more useful question is how you should travel, given who you are, what you care about and what's happening right now. GoWise is an attempt to answer that one.