RescueMesh

An autonomous food-rescue agent that matches surplus food with community pantries, coordinates volunteer drivers, replans when conditions change, and escalates only when human judgment is needed.

Comment

Inspiration

Food rescue looks simple on the surface: a donor has surplus food, a community pantry needs it, and a volunteer driver transports it.

In reality, it is a real-time coordination problem.

A donation may only be available for a few hours. Pantries have different needs and capacities. Volunteer drivers have vehicle limits and availability windows. Pickup deadlines, travel times, delivery routes, and last-minute disruptions all have to line up.

Even when food, drivers, and receiving organizations are available, poor coordination can still cause usable food to go to waste.

That inspired RescueMesh: an autonomous food-rescue coordination system designed to turn a surplus-food donation into an executable, trackable, and recoverable rescue operation.

The goal was not to build another chatbot that tells people what they should do. We wanted to build an agent that could actually help coordinate the workflow.

What RescueMesh Does

RescueMesh connects four participants:

  • Food donors with surplus food
  • Volunteer drivers transporting donations
  • Community pantries receiving food
  • Rescue operators monitoring active rescues and handling exceptions

When a donation is created, RescueMesh inspects the current rescue network and determines whether a feasible rescue exists.

It considers pantry need and available capacity, assigns an available volunteer driver, allocates food across eligible pantries, optimizes the delivery route, and creates a persistent rescue operation.

For example, if one pantry has 40 pounds of unmet need and another has 10 pounds, RescueMesh can split a 50-pound donation across both locations when capacity, driver availability, deadlines, and route feasibility allow it.

The rescue is then tracked through:

Donation → Planning → Driver Dispatch → Pickup → Delivery → Pantry Confirmation

RescueMesh can also respond when conditions change during an active rescue.

If a driver becomes unavailable, a pantry closes, or pantry capacity changes, the system evaluates the updated state and runs deterministic replanning.

If a safe alternative exists, the rescue can recover automatically. If there is no clearly safe alternative, RescueMesh stops automation and escalates the case for human review.

We also use two-sided delivery verification. A driver's delivery report does not complete the rescue by itself. The receiving pantry must independently confirm receipt before the stop is marked complete.

How We Built It

Our main design principle was:

LLMs orchestrate. Deterministic algorithms optimize.

We intentionally separated AI coordination from logistics optimization.

AI Coordination

The rescue coordinator is built using the Strands Agents SDK and deployed through Amazon Bedrock AgentCore Runtime.

The Strands RescueCoordinator uses Claude Haiku 4.5 through Amazon Bedrock for reasoning and tool selection.

The agent receives a restricted set of RescueMesh tools that allow it to:

  • inspect a donation
  • inspect the current rescue network
  • request a rescue plan
  • inspect an active operation
  • inspect operation events
  • inspect pending escalations

The agent coordinates the workflow, but it does not calculate routes, quantities, capacities, or travel times itself.

Deterministic Logistics

Critical logistics decisions are handled by deterministic components:

  • PuLP for food allocation
  • Google OR-Tools for route optimization
  • OpenRouteService for road-network travel times

The planner evaluates constraints such as:

  • pantry demand and capacity
  • driver availability
  • vehicle capacity
  • driver shifts
  • pickup deadlines
  • route feasibility

This prevents the LLM from inventing logistics values.

Application and State

The user-facing application is built with Streamlit and hosted on AWS EC2 behind Nginx + HTTPS.

The backend uses FastAPI, and persistent operational state is stored in SQLite.

The database tracks:

  • donations
  • rescue operations
  • driver routes
  • delivery stops
  • events
  • escalations

This allows a rescue to continue across multiple real-world events instead of existing only inside an LLM conversation.

Two Execution Paths

RescueMesh deliberately separates agentic coordination from physical-world actions.

The AI coordination path is:

Donation → AgentCore → Strands → Restricted Tools → FastAPI → Deterministic Planner

Driver and pantry actions follow a separate path:

Driver / Pantry → Application → Operational State

This means the agent cannot fabricate driver acceptance, pickup, delivery, pantry confirmation, or human approval.

Challenges We Ran Into

One of the biggest challenges was deciding how much control the AI agent should have.

It would have been easy to let the LLM choose pantries, quantities, drivers, and routes directly. However, these decisions involve hard operational constraints and can have real consequences.

We instead built a hybrid architecture where the agent coordinates the process while deterministic optimization validates and calculates the logistics.

Another challenge was handling disruptions after a rescue had already started.

A plan that was valid a few minutes earlier may become invalid if a driver becomes unavailable or a pantry closes. We had to design RescueMesh around persistent operational state so it could understand what had already happened, preserve completed actions, and replan from the current situation.

Deploying the agent through Amazon Bedrock AgentCore was another major challenge. We had to connect:

EC2 → AgentCore → Strands → Amazon Bedrock → Remote Tools → FastAPI → Optimizer → Database

This involved IAM permissions, authenticated remote tools, deployment packaging, application boundaries, and making sure the deployed agent could safely operate on the live RescueMesh backend.

We also had to carefully separate simulated demo controls from real system state. For example, a driver reporting a delivery and a pantry confirming receipt are intentionally modeled as two different events.

What We Learned

The biggest lesson was that giving an AI agent more control does not automatically make the system more capable.

For RescueMesh, the strongest design came from giving each component a clear responsibility:

  • LLMs handle reasoning, coordination, and tool selection.
  • Optimization algorithms handle quantities, capacities, routes, and feasibility.
  • Application events represent what actually happened in the physical world.
  • Humans handle consequential decisions when automation should stop.

We also learned that persistent state is essential for real agentic workflows. A rescue cannot live only inside a conversation because drivers, pantries, and disruptions interact with it over time.

Finally, deploying the coordinator through AgentCore showed us the difference between a local AI prototype and an operational agent. Authentication, IAM permissions, remote tools, backend state, and failure handling all become part of the system design.

Evaluation

We wanted to evaluate RescueMesh beyond a single hand-picked demo.

The project currently has 53 automated tests passing, covering planning constraints, capacity, driver availability, shifts, deadlines, routing, disruption handling, and workflow state.

We also created a reproducible randomized benchmark with seed=42.

Across 50 randomized planning scenarios:

  • 46 / 50 generated feasible rescue plans
  • 46 / 46 generated plans passed independent safety checks
  • 89.62% weighted food rescued
  • 0 capacity violations
  • 6.42 seconds average planning latency

The four infeasible scenarios were safely rejected rather than forcing an invalid plan.

We also tested 10 in-transit pantry-closure disruptions:

  • 10 / 10 recovered autonomously
  • 0 unsafe autonomous recoveries
  • 0.79 seconds average recovery latency

The 100% recovery result applies specifically to the tested pantry-closure scenarios.

What's Next

RescueMesh is currently a hackathon prototype using simulated donors, volunteer drivers, and community pantries.

Future versions could add:

  • SMS or mobile workflows for drivers
  • real pantry inventory integrations
  • restaurant and grocery-store donation integrations
  • production authentication and identity management
  • scalable cloud databases
  • real-time notifications
  • richer monitoring and observability
  • additional disruption scenarios
  • multi-city rescue networks
  • demand forecasting for pantry needs

The long-term goal is to reduce the coordination burden required to move usable food from places that have it to communities that need it.

Built With

Share this project:

Updates

Submission history