Relay

When food rescue plans break, Relay turns messages into reviewed updates, replaces failed commitments, and tracks custody through delivery—powered by Strands Agents SDK and Amazon Bedrock.

Comment

Inspiration

Food rescue does not end when a route is generated. A driver can drop out after pickup, a kitchen can change its capacity, and a coordinator must decide what can safely change while the rest of the rescue continues.

Relay focuses on that operational gap: recover a broken commitment without discarding the commitments that still work. Our goal is to help food-rescue coordinators turn changing information into accountable action.

What it does

Relay is a working operations workspace with participant facts, AI-assisted messages, feasible plans, confirmations, recovery and an activity log.

A participant can write, “I am available. I can carry 16 crates and must finish by minute 85.” Relay uses a live model call to interpret the message, validates quantities and time, and presents a reviewable draft. The coordinator explicitly applies the update. Interpretation alone never approves a rescue or changes a commitment.

The recovery flow demonstrates the central idea. In our synthetic 320 kg rescue, Tunde has a 192 kg assignment and Amara has 128 kg. After Tunde picks up the food and cannot finish, the coordinator proposes Ada as a replacement. Even after the necessary responses are recorded, Relay blocks the swap while Tunde still holds the food. Once the donor records the returned load, the replacement can be committed. Amara's assignment and pickup remain intact. The kitchen's recorded receipt completes the rescue.

How we built it

Strands Agents SDK and Amazon Bedrock: A Strands Agent with BedrockModel invokes Claude Sonnet 4.6 for typed message extraction. Source-span checks, Pydantic validation and deterministic Python normalization verify the proposed facts. Ambiguous or unsupported input can require clarification. Model requests are metered and bounded. The agent has no dispatch tools.

A separate recovery engine: Python and FastAPI enforce roles, revisions, confirmations, capacity, route feasibility and custody. Commands produce durable receipts; duplicate or stale requests cannot silently become new actions. Partial replacement preserves unchanged work instead of restarting the entire rescue.

AWS deployment: The public companion and private engine run in containers on Amazon EC2. SQLite/WAL stores transactional state on encrypted EBS, with backups in Amazon S3. IAM supplies runtime permissions, Systems Manager supports host operations, and a temporary Cloudflare Tunnel provides public HTTPS. Durable worker queues support follow-up processing.

Cognito sign-in and SES email-response paths were also exercised in separate integration rehearsals. The public sandbox uses simulated participant roles; those identity and email integrations are not active in the public demonstration.

Challenges we ran into

The hardest problem was the boundary between language and action. A fluent interpretation is not sufficient evidence for changing a plan. We separated source-backed drafts from reviewed commands and kept engine validation authoritative.

Recovery also required accounting for physical custody. Reassigning a driver cannot make food appear at the donor. We added explicit return evidence, revision-specific acceptance and preservation of unaffected commitments. Persistence, retries and concurrent commands required transactional checks rather than UI-only safeguards.

Accomplishments that we're proud of

  • A complete recorded public workflow: live AI interpretation, human review, planning, participant confirmations, custody rejection, partial replacement and recipient receipt.
  • A recovery flow that preserves the unaffected driver's 128 kg assignment and recorded pickup.
  • 277 automated tests passing at the dashboard milestone, covering domain transitions, permissions, persistence, duplicate/concurrent commands, SDK behavior and model metering.
  • A working AWS deployment, an implementation architecture diagram and a reproducible local build.

These are software results from synthetic scenarios. Practitioner validation and real-world impact measurement are the next step.

What we learned

Reliable agent assistance needs a clear handoff: AI interprets, people review, and the engine validates what changes. Planning, commitment, physical custody and receipt are different states. Keeping them distinct makes failures explainable and recovery auditable.

What's next for Relay

Validate the workflow with food-rescue coordinators, improve travel and handling inputs, extend the bounded planner, and develop production identity and notification delivery. Practitioner feedback should guide those changes.

Try it

Open the live link and use Messages & AI, Commitments, Recovery and Activity log. Each visitor receives an isolated synthetic scenario. The demonstration makes real model calls and engine transitions; people, travel inputs and food movement are simulated. Public inference has a finite allowance; structured controls remain available if AI is unavailable. The temporary tunnel is a demonstration endpoint, and the repository includes local setup instructions.

The 3:20 video shows the complete workflow and explains the Strands/AWS architecture from 2:40 to 3:10. Relay is MIT licensed and was developed with AI coding assistance. The project cover illustration was AI generated. Actual application screens and the architecture diagram are included separately.

Built With

Share this project:

Updates

Submission history