Inspiration

The inspiration for Routed came from repeated personal experience traveling to new cities and feeling overwhelmed by how fragmented urban mobility tooling is. Even when cities have efficient public transportation systems, short-term visitors are often forced to research unfamiliar networks, download multiple local apps, register accounts, learn fare rules, and constantly switch between maps, weather, transit, and rideshare apps—often while jet-lagged or already in transit.

Most existing tools optimize for navigation or comparison, presenting many options and leaving the burden of decision-making on the user. Routed explores a different approach: treating urban mobility as a delegated system responsibility, where software handles research, coordination, and decision-making on behalf of the traveler.


What it does

Routed is an all-in-one urban travel application designed primarily for iOS and Android, with a web version provided for demo and evaluation purposes.

The system:

  • Unifies access to a city’s primary transportation modes and passes
  • Produces one resolved mobility plan instead of multiple alternatives
  • Reduces the need to download, register for, and switch between many local apps
  • Optionally provides food and location recommendations when explicitly requested
  • Adapts over time by learning from user behavior and trip outcomes

The primary goal is to reduce the cognitive and logistical overhead of navigating public transportation in unfamiliar cities, especially for short stays.


How we built it

Routed is built as a mobile-first client architecture backed by a centralized decision and orchestration backend.

Client applications (iOS / Android / Web demo)

The primary user experience is delivered through native mobile applications on iOS and Android. A lightweight web client mirrors the mobile experience for demo and judging purposes.

All clients:

  • Communicate with the backend via REST APIs
  • Never call external providers directly
  • Keep all third-party API keys server-side

Primary backend (Decision + Orchestration API)

The Node.js + Express backend acts as an agent orchestration layer responsible for producing a single TripPlan response.

Its responsibilities include:

  • Validating city context and enforcing cross-city constraints
  • Fetching candidate routes from Google Maps
  • Fetching weather and time context using city-local time
  • Performing venue availability checks (open/closed logic)
  • Calling Gemini as a constrained decision engine to select among candidates
  • Generating a factual explanation layer grounded in verified data
  • Emitting structured trip steps and tracking trip state and events

Gemini is used for reasoning and decision-making, not as a conversational interface. The model operates only over validated candidates and must justify decisions using concrete signals such as travel time, transfers, and weather conditions.

Optional memory sidecar

An optional FastAPI service backed by PostgreSQL and pgvector provides retrieval-based personalization and enrichment.

Its responsibilities include:

  • Storing episodic memories and inferred preferences
  • Retrieving relevant user preferences and prior behaviors
  • Serving curated community knowledge (e.g., POIs sourced from Reddit or XHS)
  • Returning ranked retrieval results to the Node backend via HTTP

This component is used strictly for retrieval, not training, and remains decoupled from routing logic to maintain system clarity and safety.

The backend also implements request gating, rate limiting, caching, idempotency, and event logging to ensure predictable behavior and cost control.


Challenges we ran into

One major challenge was designing a system that removes choice without reducing trust. Presenting a single recommendation requires strong grounding in facts and consistent behavior across different cities and conditions.

Another challenge was integrating Gemini in a meaningful way. Instead of free-form text generation, the model is constrained to operate over verified candidates and produce actionable, grounded decisions.

Managing API cost and safety in an early-stage prototype also required careful gating, monitoring, and fallback behavior to prevent runaway usage.


Accomplishments that we're proud of

  • Designing a delegation-first mobility system that collapses complexity instead of exposing it
  • Integrating Gemini as a reasoning and decision layer, not just a text generator
  • Building a clean orchestration pipeline that combines deterministic logic with constrained AI reasoning
  • Implementing a retrieval-based memory sidecar for personalization without entangling core routing logic
  • Delivering a functional, end-to-end system as an early-stage prototype

What we learned

This project reinforced that AI systems are often most effective when they remove decisions rather than add explanations. Delegation-based design shifts responsibility from the user to the system, closer to how infrastructure operates.

It also showed that personalization does not need to be explicit to be useful. Learning from observed behavior over time can quietly improve outcomes without requiring manual preference configuration.


What's next for Routed

Next steps include deeper integration with city-specific transit memberships, a full mobility broker for in-app rideshare booking, and expanded behavioral modeling across longer usage periods.

Routed will also integrate additional ways to explore cities, such as shared bikes, scooters, and other local mobility options. These modes will be incorporated into the same decision pipeline, allowing the system to select them contextually when they are the most practical or enjoyable way to move through a city.

Over time, this expands Routed from solving “how to get from A to B” to supporting lightweight, situational city exploration, while preserving the core design principle of minimizing research, app switching, and user decision-making.

Built With

Share this project:

Updates