Food Bridge

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

Every day, restaurants, hotels, event venues, and commercial kitchens have safe surplus food that could help nearby communities. The food exists, recipients need it, and volunteers may be available—but the rescue often fails because coordination takes too long.

Someone must check food-safety requirements, recipient capacity, refrigeration, distance, collection deadlines, and transport availability. They may also need to contact several organizations before finding a match.

We created FoodBridge to turn this time-sensitive chain of calls and decisions into one coordinated, human-controlled rescue.

What it does

FoodBridge is an AI-powered food-rescue coordinator that moves surplus meals from donors to qualified community organizations before the food expires.

A donor or coordinator enters:

• The food source and type
• The estimated number of meals
• The pickup area and deadline
• Whether refrigeration is required

FoodBridge then:

1. Validates the donation details.
2. Checks recipient capacity and safe-storage requirements.
3. Compares eligible recipients using distance and reliability.
4. Recommends the safest match.
5. Pauses and asks the coordinator for approval.
6. After approval, reserves recipient capacity and assigns a suitable volunteer.
7. Prepares the pickup plan and notifications.
8. Records the completed handoff and updates the verified impact total.

If the selected recipient becomes unavailable, FoodBridge can automatically evaluate the next qualified recipient and return a new recommendation for approval.

The project also includes a conversational workspace where coordinators can describe a donation naturally, ask why a recipient was selected, review alternatives, approve the next action, and follow the rescue’s live progress.

FoodBridge never contacts a recipient without human approval and never records a delivery until the handoff is confirmed.

How we built it

The autonomous agent was built in Python using the Strands Agents SDK and deployed to Amazon Bedrock AgentCore Runtime.

We created specialized agent tools for:

• Validating donation requirements
• Matching and ranking recipients
• Requesting human approval
• Reserving recipient capacity
• Assigning compatible volunteers
• Preparing notifications
• Handling recipient failure and rerouting
• Recording delivery receipts

For fast responses, the agent first uses Groq with GPT-OSS 20B. GLM through Z.AI provides a secondary model route, while Amazon Nova Micro through Amazon Bedrock remains the final AWS fallback. All providers run through the same Strands agent and safety tools.

The public application was built with Next.js, React, and TypeScript and deployed on Cloudflare Workers. Cloudflare D1 stores donation statuses, recipient matches, activity history, completion timestamps, and verified impact.

A secret-protected AWS Lambda bridge connects the Cloudflare application to AgentCore. AWS and model credentials remain encrypted on the server and are never exposed to the browser.

The interface includes responsive desktop and mobile layouts, live rescue progress, approval actions, formatted agent responses, sound feedback, rescue history, and verified impact statistics.

All organizations, volunteers, and donation records shown in the public prototype use synthetic demonstration data.

Challenges we ran into

One of our biggest challenges was model availability. Our AWS account initially received a zero inference quota for several Bedrock models across multiple regions. Some models were unavailable to the account, while others returned daily token-limit errors.

Instead of removing Bedrock, we designed a resilient provider strategy. Groq became the low-latency route, GLM became the secondary option, and Amazon Nova Micro remained the final AWS fallback. This allowed us to preserve the AgentCore and Strands architecture while handling temporary provider limitations.

Another challenge was securely connecting a Cloudflare-hosted interface to an AWS AgentCore deployment. We did not want AWS credentials or model keys inside the browser. We solved this using a narrowly scoped Lambda bridge, encrypted secrets, and restricted IAM permissions.

We also had to balance autonomy with safety. FoodBridge needed to take useful actions automatically without making sensitive decisions on behalf of the operator. We designed explicit approval gates before recipient contact and delivery confirmation.

Finally, we worked to make the agent visible and understandable. Instead of showing only a loading spinner, the interface explains which rescue checks are happening and presents clear actions the operator can approve.

Accomplishments that we're proud of

• Built and deployed a working Strands agent on Amazon Bedrock AgentCore Runtime
• Created a complete donation-to-delivery workflow rather than a standalone chatbot
• Connected a public Cloudflare application securely to AWS without exposing credentials
• Added deterministic refrigeration and capacity checks that cannot be ignored by the model
• Implemented human approval before any recipient is contacted
• Added automatic fallback and recipient-rerouting behavior
• Created an auditable rescue timeline and verified impact history
• Built a responsive experience that works across desktop and mobile devices
• Ensured the application reports connection failures honestly instead of displaying fabricated AI answers

What we learned

We learned that a useful agent is more than a model producing text. It needs clear tools, persistent state, safe boundaries, failure recovery, and an interface that shows people what it is doing.

We also learned that deterministic rules should handle critical requirements such as capacity and refrigeration. The model can explain and coordinate the decision, but safety constraints must remain enforced by the application.

Human approval does not make an agent less autonomous. A carefully placed approval step creates trust while still allowing the agent to perform repetitive coordination work.

Finally, provider fallback is important for real-world reliability. An agent should be able to recover from quotas, temporary outages, and unavailable models without changing its safety rules or user experience.

What's next for FoodBridge

Our next steps are to:

• Connect real community organizations and food donors
• Add live recipient availability and capacity updates
• Allow volunteers to accept and confirm pickups from their phones
• Send multilingual SMS, WhatsApp, and email notifications
• Add map-based routing and estimated pickup times
• Support photo-based packaging and food-condition verification
• Provide operational dashboards for charities and municipalities
• Add privacy-preserving integrations with partner systems
• Measure environmental impact, including food waste and estimated emissions avoided

Our long-term goal is for FoodBridge to become a shared coordination layer that helps communities rescue more food safely, quickly, and with less manual effort.

Built With

• ai-agents
• amazon-bedrock
• amazon-bedrock-agentcore
• amazon-cloudwatch
• amazon-nova-micro
• aws-iam
• aws-lambda
• cloudflare-d1
• cloudflare-workers
• drizzle-orm
• glm
• gpt-oss-20b
• groq
• human-in-the-loop
• next.js
• python
• react
• strands-agents-sdk
• tailwind-css
• typescript
• vite
• z.ai