What inspired it

Every night in Edinburgh, incredible restaurants throw away perfectly good, high-quality food. It is not because they want to, but because coordinating a donation at 10:30 PM after a grueling shift is a logistical nightmare. Calling shelters to check capacity, verifying food safety windows for hot versus cold items, and finding a volunteer driver takes up to 45 minutes of manual work.

I was inspired by the Good Neighbor Agents track to solve this exact problem. I wanted to build an autonomous broker that handles this repetitive, time-sensitive coordination, allowing restaurants to donate their surplus with a single sentence while taking the operational burden off local nonprofits.

What it does

Our agent acts as a 24/7 intelligent dispatcher for community food rescue.

  • Natural Language Intake: A restaurant manager simply types what they have left over (e.g., "15 lbs of hot vegetable stew").
  • Safety & Capacity Reasoning: The agent analyzes the food type, checks local Edinburgh shelter databases for active capacity, and ensures the shelter is permitted to accept hot food.
  • Autonomous Dispatch: It matches the food with an eligible shelter (like the Grassmarket Community Project) and selects an available volunteer driver with the appropriate vehicle.
  • Human-in-the-Loop: It presents the logistical plan to the manager for a final "Approve & Dispatch" click, ensuring safety and oversight before sending mock SMS notifications to the driver.

The Math Behind the Rescue

To make the agent's decision-making robust, we modeled the logistics mathematically. For a valid shelter match, the agent ensures the donation weight, (W_{donation}), never exceeds the available capacity, (C_{shelter}): W_{donation} \leq C_{shelter}

We also track the net environmental impact (CO₂ Saved) of every successful dispatch. The total carbon emissions saved, (E_{saved}), is calculated by taking the weight of the rescued food, (W), multiplied by the carbon footprint factor of food waste, (\alpha), minus the emissions generated by the driver's transit: E_{saved} = \sum_{i=1}^{N} \Big( W_i \cdot \alpha \Big) - \Big( d_i \cdot \epsilon_{vehicle} \Big) (Where (d_i) is distance driven and (\epsilon_{vehicle}) is the emission factor of the chosen transport, such as (0) for an electric cargo bike).

How we built it

I built the application using Python and the Strands Agents SDK. The user interface is a multi-tab dashboard built entirely in Streamlit, featuring a Restaurant Portal, a Live Dispatch Hub, and a Community Impact metrics page.

The core "brain" of the agent runs on Amazon Bedrock. I utilized the Qwen 3 (235B) model because of its exceptional reasoning capabilities and ability to perfectly parse complex tool schemas. The agent is equipped with several custom Python tools (@tool decorators) that allow it to query our mock Edinburgh JSON databases in real-time.

Challenges we ran into

The biggest hurdle was cloud infrastructure billing and AWS Marketplace restrictions. Initially, I attempted to use Anthropic's Claude models, but I repeatedly encountered AccessDeniedException errors due to missing Marketplace payment instruments on my Free Tier account.

Instead of letting it stop me, I pivoted to a native Amazon Bedrock model (Qwen 3). This bypassed the third-party subscription requirements entirely, allowed me to utilize my AWS promotional credits smoothly, and kept the project moving forward without compromising on the agent's reasoning quality.

Accomplishments that we're proud of

We are incredibly proud to have built a complete, end-to-end logistics agent that goes beyond a simple chat interface. Building a polished multi-tab dashboard that incorporates a critical "Human-in-the-Loop" approval state makes this feel like a viable, production-ready product for Edinburgh's community.

What we learned

I learned that building an AI agent is less about prompting and more about system architecture. Mastering the Strands SDK taught me how to strictly define tool docstrings and data types so the LLM knows exactly when and how to interact with the real world. I also learned that for real-world logistics involving food safety, human approval is a mandatory feature.

What's next for Zero Waste Food Logistics Agent

The next step is integrating a real database (like PostgreSQL) instead of local mock datasets, and connecting live communication APIs (like Twilio) to send actual SMS dispatch pings to volunteers navigating Edinburgh. We also plan to implement live route optimization to calculate dynamic driver ETAs based on current traffic.

Built With

Share this project:

Updates

Submission history