RideRelay

An intelligent community transportation coordinator that matches riders to limited resources and automatically recovers when disruptions happen.

Comment

Inspiration

Transportation becomes difficult when many people need different types of rides at the same time.

A wheelchair user may need an accessible vehicle, a parent may be traveling with a child, students may need transportation after school, and someone with a medical appointment may have a strict time window. At the same time, drivers have schedules, vehicles have limited capacity, and one cancellation can affect multiple assignments.

I wanted to explore:

What if an AI agent could coordinate this transportation network while a safety layer ensured that every committed assignment was actually feasible?

That idea became RideRelay, an agentic transportation operations coordinator for community transportation.

What it does

RideRelay coordinates riders, drivers, vehicles, schedules, capacity, accessibility requirements, and transportation disruptions as one connected network.

A member submits a ride request with their destination, timing, and requirements. The Strands Agent coordinates the workflow and works with the Transportation Optimizer to find a feasible assignment.

Before an assignment is committed, the Constraint & Safety Layer verifies:

  • Driver availability
  • Vehicle availability
  • Vehicle capacity
  • Wheelchair accessibility
  • Rider time windows
  • Existing trip conflicts
  • Scheduling constraints
  • Overlapping assignments

The core principle is:

The agent can propose. The safety layer verifies.

RideRelay also handles disruptions. If a driver becomes unavailable, the Strands Agent triggers the recovery workflow. The Recovery Engine searches for another feasible driver or vehicle using the same safety constraints.

If a safe alternative exists, the affected assignment is updated. If no safe alternative exists, RideRelay does not force an unsafe decision. The ride remains in the Human Review Queue with a Review & Retry workflow.

How I built it

RideRelay is built with:

  • FastAPI — backend API and application logic
  • Strands Agents — agentic workflow coordination
  • SQLite — canonical persisted transportation state
  • Constraint-based Transportation Optimizer — assignment planning
  • Recovery Engine — disruption detection and reassignment
  • Constraint & Safety Layer — deterministic feasibility and safety validation

The main architecture is:

Member Request → FastAPI → Strands Agent Coordinator → Transportation Optimizer / Recovery Engine → Constraint & Safety Layer → validate_plan() → SQLite → All Portals Updated

We separated the responsibilities of the agent, optimizer, recovery engine, and safety layer.

  • The Strands Agent coordinates the workflow rather than directly committing assignments.
  • The Transportation Optimizer searches for feasible assignments.
  • The Recovery Engine handles disruptions and reassignment.
  • The Constraint & Safety Layer verifies the proposed plan.
  • validate_plan() acts as the safety gate before a plan can be persisted.
  • SQLite provides the canonical persisted transportation state.

This separation allows the system to combine agentic reasoning with deterministic safety checks instead of allowing an AI agent to directly make and commit transportation decisions.

Challenges I ran into

One of the biggest challenges was coordinating multiple constraints at the same time.

A ride cannot simply be assigned to the first available driver. The system has to consider driver schedules, vehicle availability, vehicle capacity, wheelchair accessibility, rider time windows, existing trips, and overlapping assignments.

Disruption recovery introduced another challenge. When a driver becomes unavailable, the system needs to recover the affected assignment without accidentally changing or duplicating unrelated assignments.

We also encountered issues with duplicate assignment records and stale transportation state during development. We addressed this by making the persisted trip records the canonical source of truth and using stable assignment identities instead of creating duplicate proposal records.

Another important challenge was handling cases where no safe assignment exists. Instead of forcing the optimizer to return a result, RideRelay treats infeasible requests as a valid outcome and sends them to human review.

This helped reinforce an important design decision:

Failure to find a safe assignment is better than committing an unsafe one.

Accomplishments that I am proud of

I am proud that RideRelay became more than a simple ride-matching application.

The system can:

  • Coordinate multiple riders, drivers, and vehicles as one network.
  • Match rides while considering capacity, schedules, accessibility, and conflicts.
  • Validate proposed assignments before they are persisted.
  • Recover from driver or vehicle disruptions.
  • Preserve unaffected assignments during recovery.
  • Prevent unsafe or conflicting assignments from being committed.
  • Escalate infeasible cases to a human coordinator.
  • Allow human coordinators to retry matching when transportation conditions change.
  • Maintain a canonical persisted transportation state.

Most importantly, we built the system around a clear separation of responsibilities:

AI coordinates → Optimization proposes → Safety validates → The system persists.

What I learned

This project changed how I think about agentic AI.

An agent does not need to make every decision itself. In a real operational system, the agent can be responsible for coordinating tools, workflows, and decisions, while deterministic systems enforce rules that should never be violated.

I learned that agentic systems become much more reliable when they are combined with explicit constraints and validation rather than relying entirely on LLM reasoning.

I also learned the importance of having a canonical source of truth. During development, keeping persisted transportation state separate from temporary optimizer proposals helped prevent duplicate assignments and inconsistent recovery behavior.

Another major lesson was that recovery should be treated as part of the core workflow, not as an afterthought. Real-world systems change constantly, so an agentic system should be designed not only to create a plan, but also to adapt when that plan becomes invalid.

What's next for RideRelay

The next step for RideRelay would be expanding it from a hackathon prototype into a more realistic transportation coordination platform.

Future improvements could include:

  • Real-time driver and vehicle availability
  • Live route and traffic information
  • More advanced accessibility matching
  • Predictive disruption detection
  • Multi-stop and shared-ride optimization
  • Larger transportation networks
  • Historical analytics and demand forecasting
  • Notifications for riders, drivers, and coordinators
  • Integration with real transportation providers
  • More advanced agent collaboration for complex operational scenarios

The long-term goal is to make RideRelay capable of continuously coordinating a changing transportation network rather than simply generating a one-time schedule.

RideRelay doesn't just create a transportation plan. It coordinates, verifies, recovers, and adapts when the real world changes.

Built With

Share this project:

Updates

Submission history