Inspiration

In Douglas County, older adults often depend on volunteer drivers to reach medical appointments, grocery stores, pharmacies, and community activities. Local nonprofit transportation programs coordinate thousands of rides each year, but every request can involve multiple moving pieces: rider needs, volunteer availability, distance, timing, accessibility, confirmations, cancellations, and last-minute gaps.

NeighborRoute explores a simple question: what if an AI agent could handle the repetitive coordination work while people retained control of every sensitive decision?

The project is inspired by the publicly documented workflows of senior transportation nonprofits serving Castle Pines and the surrounding Douglas County community. We are seeking feedback from local coordinators before finalizing the workflow and will not use real client information in the hackathon demo.

What it does

NeighborRoute is a human-supervised volunteer transportation coordinator.

A coordinator can provide ride requests from a form, email, or simulated phone transcript. The agent:

  1. Extracts the pickup, destination, appointment window, round-trip needs, accessibility requirements, and urgency.
  2. Checks the request against program policies and identifies missing information.
  3. Finds suitable volunteer drivers using availability, service area, time, vehicle capability, and route distance.
  4. Proposes combined routes when compatible trips can be served safely by one driver.
  5. Contacts simulated volunteers for confirmation and follows up when they do not respond.
  6. Replans when a driver declines or a ride is cancelled.
  7. Sends medical, accessibility, policy-conflict, or unfilled requests to a Judgment Inbox for a human coordinator.

The agent never decides whether a person deserves service, overrides safety rules, or exposes one rider's information to another volunteer. The demo uses synthetic riders and volunteers.

How we plan to build it

NeighborRoute will use the Strands Agents SDK to orchestrate specialized agents for intake, policy checking, matching, communication, and recovery. A graph workflow will make each step visible and auditable.

The planned AWS architecture includes:

  • Amazon Bedrock for reasoning and structured extraction
  • Amazon Bedrock AgentCore Runtime for hosting the agent
  • AgentCore Memory for approved operational context
  • AWS Lambda for event-driven intake and callbacks
  • Amazon DynamoDB for synthetic ride and volunteer records
  • Amazon Location Service for route-aware matching
  • Amazon SNS for simulated notifications and confirmations

Every proposed assignment will include a short explanation of why the match was selected. Sensitive or ambiguous cases will pause for explicit human approval.

Why it matters

Transportation is often the difference between keeping a medical appointment and missing care, or between living independently and becoming isolated. The project is designed to give small nonprofit teams more coordination capacity without replacing the relationships and judgment that make volunteer programs work.

Success will be measured in the demo through:

  • percentage of eligible requests matched
  • coordinator minutes saved
  • volunteer response and reassignment time
  • unnecessary driving miles avoided
  • number of sensitive decisions correctly escalated

Challenges

The central challenge is not route optimization alone. A useful system must balance urgency, accessibility, volunteer constraints, privacy, fairness, and nonprofit policies. It must also fail safely when information is incomplete or no appropriate driver is available.

What's next

Our immediate next step is interviewing local nonprofit coordinators and volunteers to validate the real bottlenecks. We will then narrow the workflow, build a synthetic-data prototype, test cancellation and no-driver scenarios, and deploy a live end-to-end demo on AWS.

Built With

Share this project:

Updates