TransitBD - Smart Transit Agent

Smart transit agent that understands your travel constraints, validates routes and locations, and recommends only trustworthy, feasible journeys, never guessing when critical data is missing.

Comment

Inspiration

Urban travel is rarely just a shortest-path problem. A commuter may need to reach a destination before a deadline, stay within a budget, minimize walking, or adapt to traffic and weather conditions.

We wanted to build an AI transit agent that could understand these constraints in natural language and make a recommendation without blindly trusting a single API result.

We also wanted the system to avoid being dependent on a single commercial mapping platform or a proprietary LLM API. Instead, the core decision-making should remain transparent, testable, provider-agnostic, and capable of operating without an external LLM.

This inspired Smart Transit Agent, an evidence-aware AI transit planning system designed around a simple principle:

UNKNOWN ≠ FEASIBLE.

If critical information is missing or unreliable, the system should preserve that uncertainty instead of inventing an answer.

What it does

Smart Transit Agent allows users to describe a journey naturally, including constraints such as destination, deadline, budget, walking preference, and travel mode.

For example:

"I need to go from Mirpur to United International University before 9 AM, keep my budget under 100 taka, and minimize walking."

The agent:

  • Understands the user's natural-language request and extracts constraints.
  • Resolves origin and destination using provider-agnostic geocoding services.
  • Validates both the geography and the identity of the resolved entity.
  • Retrieves route, traffic, weather, and available transit evidence.
  • Evaluates hard constraints such as deadline and budget.
  • Ranks candidates deterministically according to the user's preferences.
  • Returns alternatives and explanations when sufficient evidence exists.
  • Fails closed when critical evidence is missing instead of fabricating a recommendation.

Unlike systems built around a single mapping ecosystem, Smart Transit Agent does not depend on Google Maps, Google Directions, or Google Places APIs for its core functionality.

The LLM layer is also optional rather than mandatory. Natural-language planning can fall back to a deterministic rule-based parser, while an LLM can be used for richer understanding and explanation when available.

Most importantly, the LLM is intentionally non-authoritative. It can help understand the request and generate explanations, but it cannot override the deterministic feasibility decision.

How we built it

We built the system as a layered architecture:

Natural Language → Agent → Tools → Services → Providers → Evidence & Validation → Decision Core

The architecture is provider-agnostic. Instead of coupling the decision engine to Google Maps or another single platform, external services are accessed through controlled provider abstractions.

For geocoding, we use multiple providers and validate their results instead of blindly accepting the first result. An explicit operating region for Dhaka is applied before the entity and geography gates, preventing ambiguous locations from silently resolving outside the intended region.

For routing, OpenRouteService is the primary provider with GraphHopper available as a fallback. TomTom provides traffic information, while Open-Meteo provides weather data. Transit functionality is deliberately evidence-aware: we never fabricate live Dhaka transit itineraries when real evidence is unavailable.

The agent does not directly call external provider APIs. Providers are accessed through the service layer, keeping the LLM and decision logic isolated from API-specific implementations.

The decision layer evaluates hard constraints before ranking candidates. Missing evidence remains UNKNOWN, and UNKNOWN candidates are never treated as feasible.

We also built an adversarial verification layer, internally referred to as KILLCRITIC, to challenge the system with wrong entities, wrong geography, impossible budgets, impossible deadlines, unavailable providers, missing evidence, and adversarial LLM outputs.

Challenges we ran into

The biggest challenge was not simply integrating APIs. It was preventing plausible-looking API responses from becoming incorrect recommendations.

During development, we found cases where a geocoder could return a geographically valid but semantically wrong entity. For example, a query for United International University could return another university in Dhaka. We also encountered the broader problem of ambiguous locations such as "Mirpur", where a provider could return a location outside the intended operating region.

We addressed these issues with explicit geographic boundaries, entity validation, evidence states, and fail-closed behavior.

Another challenge was making the LLM useful without allowing it to become the authority over safety-critical decisions. We introduced sanitization and a controlled LLM interface so that adversarial or malformed model output cannot override hard constraints or convert UNKNOWN into FEASIBLE.

We also deliberately avoided making the system dependent on a single commercial API or an external LLM. This required designing provider abstractions and keeping the deterministic decision core independent from framework, HTTP-client, provider-SDK, database, and LLM-SDK dependencies.

Finally, live verification has been challenging because the development verification environment did not have the required external network access, dependencies, or API credentials. Rather than claiming live integrations were verified, we kept those paths explicitly marked as NOT VERIFIED until they can be exercised in a real environment.

Accomplishments that we're proud of

We are particularly proud that the system's decision-critical core has been extensively tested against both normal and adversarial scenarios.

The verified work includes:

  • Evidence-aware geocoding with geography and entity validation.
  • Deterministic hard-constraint evaluation.
  • Fail-closed handling of missing or unusable evidence.
  • Protection against wrong-location and wrong-entity geocoding results.
  • An LLM-optional architecture where the core planner can operate without an external LLM API.
  • Provider abstraction with routing fallback.
  • Independence from Google Maps, Google Directions, and Google Places APIs.
  • Adversarial KILLCRITIC scenarios covering wrong entities, wrong geography, impossible budgets, impossible deadlines, provider failures, missing evidence, and adversarial LLM outputs.
  • A deterministic offline demonstration path that produces stable results without fabricating live data.

The offline verification process reports 42/42 machine-checked invariants passing, a 102-file compile sweep with zero errors, and zero findings across the static architecture audits. The larger verified test subset also reports 401 passing tests.

Most importantly, the system is designed to prefer an honest UNKNOWN state over a confident but unsupported answer.

What we learned

Our biggest lesson was that adding an LLM does not automatically make a system intelligent or reliable.

The difficult part is deciding when an answer is trustworthy enough to act on.

We learned to separate probabilistic language understanding from deterministic decision authority. An LLM can be useful for interpreting what the user wants, but validation, feasibility, and ranking should remain controlled and testable.

We also learned that a robust AI system should not depend on one provider or one model. Mapping providers can return incorrect entities, external APIs can become unavailable, and LLM output can be malformed or adversarial.

By keeping the core decision engine independent of Google APIs and external LLM dependencies, we can test the most important parts of the system deterministically and swap providers without changing the decision logic.

We also learned that missing data must be represented explicitly. Treating missing fare as zero, assuming a missing ETA, or blindly accepting the first geocoding result can turn uncertainty into a false recommendation.

This led us to adopt a fail-closed philosophy throughout the system:

Missing evidence stays missing. UNKNOWN never becomes FEASIBLE.

What's next for Smart Transit Agent

Our immediate priority is completing live end-to-end verification on a networked environment with the required dependencies, API credentials, and real provider calls.

Next, we plan to:

  • Complete live verification of the FastAPI agent endpoint and external providers.
  • Build the user-facing frontend around the verified backend contracts.
  • Improve real-time transit itinerary coverage as reliable data becomes available.
  • Add persistent trip state and caching where they provide measurable value.
  • Strengthen autonomous trip monitoring and meaningful rerouting.
  • Develop and evaluate ETA prediction against a historical median baseline using temporal validation.
  • Expand regression and adversarial testing as new capabilities are introduced.
  • Continue expanding provider flexibility without coupling the system to a single mapping or LLM platform.

Our long-term goal is not simply to build an AI that finds a route.

It is to build a transit agent that can understand the user's intent, challenge the evidence, enforce the constraints, and clearly distinguish between what it knows and what it does not know — without requiring a single proprietary mapping platform or LLM to be the authority.

Built With

Share this project:

Updates

Submission history