Un agente de IA para moverse por Bengaluru que planifica cómo viaja usted

Pídale un trayecto a cualquier app de navegación y obtendrá una sola respuesta: una ruta. Los desplazamientos reales en una ciudad como Bengaluru son más complicados. El camino más rápido no siempre es el más barato. Un viaje en metro algo más largo puede ganarle a una hora en un atasco. Hay quien no se sube a un taxi o a un autorickshaw pase lo que pase. Y el plan que parecía perfecto hace cinco minutos puede ser erróneo ahora.

Ese desajuste dio lugar a Commute Agent, un sistema de IA que no se limita a encontrar una ruta, sino que decide cómo debería desplazarse una persona. GoWise es la app que usan de verdad los viajeros. El código es público en https://github.com/ssharanyab/commute-agent.

Estrategias, no rutas

GoWise es un planificador multimodal y personalizado para Bengaluru. Un trayecto no es un único camino de A a B. Es una mezcla de caminar, autobuses de BMTC, metro, autorickshaws y taxis, que puede dar lugar a cadenas como a pie, metro, a pie, o a pie, autobús, a pie, o autorickshaw, metro, a pie, según convenga.

Nadie programó esas combinaciones a mano. El planificador busca en la red de movilidad y calcula de forma algorítmica los trayectos viables.

Cómo está dividido el sistema

La decisión de diseño central es un muro firme entre la orquestación con IA y la toma de decisiones determinista. A grandes rasgos:

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

Flutter ofrece la experiencia del viajero. El backend ejecuta el flujo de planificación y Google ADK se encarga de la orquestación. Esta es la regla que más importa: el LLM nunca elige la ruta.

Los trayectos candidatos salen de la búsqueda en grafos

El Journey Builder trabaja sobre una red de paradas, estaciones, conexiones y tramos a pie o de acceso. Una búsqueda determinista en el grafo la convierte en trayectos multimodales viables, cada uno con su propia combinación de medios y transbordos.

Así que nadie le pregunta a Gemini algo como "¿cuál es la mejor forma de ir de Majestic a Indiranagar?". Primero se generan los candidatos de forma algorítmica. Eso hace la planificación mucho más predecible y fácil de auditar que dejar que un modelo de lenguaje improvise una ruta.

De los candidatos a la decisión

Generar opciones es solo la mitad del trabajo. Después, el sistema tiene que decidir cuál es la mejor para este viajero en concreto, y de eso se encarga un motor de decisión determinista con varios objetivos. Los viajeros pueden ponderar distintos objetivos: lo más rápido, lo más barato, lo que menos caminar exige, lo más fiable, lo que menos tráfico tiene o un equilibrio.

El motor puntúa los candidatos según esas preferencias y a la vez aplica límites estrictos. Tome a un usuario que dice que quiere evitar taxis y autorickshaws. Esas palabras no hacen simplemente que el sistema prefiera menos esos medios. Se convierten en restricciones que descartan cualquier trayecto que los incluya, y los que sobreviven se puntúan y ordenan.

Mantener separadas las restricciones y las preferencias resultó ser una de las decisiones de diseño más importantes.

Los datos que hay debajo

No es una demo conceptual. La red se basa en fuentes reales de Bengaluru:

• Feeds GTFS de BMTC
• Datos de la red de metro de BMRCL
• Tarifas de autorickshaw publicadas por la administración
• Información sobre políticas públicas
• Datos históricos de movilidad de Uber Movement

Encima hay instantáneas versionadas y trazabilidad del origen, de modo que una actualización fallida no puede sobrescribir en silencio un conjunto de datos que funcionaba.

Lo que el historial puede y no puede decir

Los datos históricos aportan señales de contexto sobre una ruta: tiempo de viaje esperado, cuánto varía ese tiempo, fiabilidad, cobertura y desviación respecto a las condiciones normales. El modelo se plantea a propósito como un estimador del contexto de la ruta y no pretende predecir cualquier tráfico futuro. Esa honestidad importa. Un sistema de IA debería decir con claridad qué saben sus modelos.

Condiciones en tiempo real

El historial no puede describir un viaje que empieza en este minuto. Para los tramos por carretera, GoWise puede añadir datos de rutas de Google Maps, que aportan estimaciones actuales que tienen en cuenta el tráfico. La división es limpia: el historial dice qué es lo normal y las rutas en tiempo real dicen cómo están las cosas ahora mismo. El motor de decisión razona sobre los trayectos enriquecidos con ambas fuentes.

El papel acotado de Gemini

Gemini, llamado a través de Google ADK, es la capa de explicaciones. Una vez que el motor determinista ha elegido un trayecto, Gemini recibe hechos contrastados sobre esa elección y redacta una explicación comprensible para el viajero. Eso impide que el modelo se invente IDs de ruta, puntuaciones, costes o razonamientos sin respaldo. En pocas palabras, el sistema decide y Gemini explica.

La personalización como parte de la planificación

Imagine el trayecto de Majestic a Indiranagar con tres viajeros distintos. Uno quiere la opción más barata. Otro no quiere caminar mucho. Un tercero rechaza taxis y autorickshaws. La red de movilidad es idéntica para los tres. Lo que cambia es el contexto de la decisión. Aquí la personalización forma parte de la propia planificación, no es un retoque estético de la interfaz.

Dónde encaja Google Maps

GoWise no pretende sustituir a Google Maps, que es excelente guiando a alguien por un trayecto ya elegido. GoWise aborda la pregunta previa: ¿qué estrategia de movilidad debería elegir? Maps navega una ruta; GoWise decide y compone cómo viaja usted y luego pasa la elección a Maps para la navegación paso a paso.

Replanificar sobre la marcha

Un desplazamiento no se queda quieto, y cuando las condiciones cambian lo suficiente, la primera recomendación puede dejar de ser la mejor. La capa adaptativa toma el contexto del trayecto actual, actualiza las condiciones que han cambiado, vuelve a puntuar los candidatos y comprueba si debería ganar otra estrategia. Eso hace que el producto pase de ser un planificador de rutas de una sola vez a un agente que toma decisiones de movilidad.

Lecciones de construirlo

Añadir un LLM no produce por sí solo un agente de IA. La mayor parte del trabajo duro resultó ser ingeniería determinista corriente:

• Construir un grafo de movilidad que merezca la pena usar
• Encontrar trayectos multimodales que sean realmente distintos entre sí
• Resolver la primera y la última milla
• Mantener intacta la identidad de los elementos de transporte entre las fases de planificación
• Arreglárselas con datos incompletos
• Distinguir los valores desconocidos de los ceros
• Diseñar una puntuación con varios objetivos que signifique algo
• Aplicar correctamente las restricciones del usuario
• Mantener las explicaciones ligadas a lo que realmente se decidió

El LLM es una pieza. La inteligencia surge de cómo cooperan todas las piezas.

Qué viene después

Hay margen para crecer: feeds de transporte en tiempo real más completos, redes peatonales más detalladas, más proveedores de movilidad, una planificación más sólida a lo largo del tiempo, personalización aprendida y conjuntos de datos más grandes. El objetivo a largo plazo no es un planificador de rutas más bonito. Es un sistema que comprenda al viajero, la red, el contexto del momento y los compromisos entre las distintas formas de moverse.

La pregunta mejor

Nos hemos vuelto muy buenos preguntando por la ruta más rápida, pero a menudo eso no es lo que quiere saber un viajero. Una pregunta más útil es cómo debería desplazarse, teniendo en cuenta quién es, qué le importa y qué está pasando ahora mismo. GoWise es un intento de responder a esa.