Relay

Relay autonomously coordinates food rescues, recovers from routine disruptions, and brings in a human only when real judgment is required

Comment

Inspiration

Food rescue does not only have a matching problem. It has a coordination problem.

A rescue can begin with a simple plan: a donor has surplus food, a recipient organization can accept it, and a volunteer driver can collect it.

Then reality happens.

A recipient suddenly loses refrigeration capacity. A driver cancels shortly before pickup. The quantity changes. Important handling information is missing. A delivery needs to be verified. What looked like one straightforward rescue becomes a chain of operational decisions that someone has to keep resolving.

Food-rescue organizations already work with networks of donors, shelters, food banks, community kitchens, and volunteer drivers. We did not want to build another product whose main contribution was simply matching those parties.

We wanted to explore a different question:

What if an agent could coordinate the rescue after the original plan starts falling apart?

That became Relay.

Relay is an autonomous operations layer for food-rescue organizations. It observes a rescue, interprets new information, works within deterministic operational policies, takes permitted actions, verifies outcomes, recovers from routine failures, and brings in a human only when real judgment is required.

Its operating loop is:

OBSERVE → REASON → ACT → VERIFY → RECOVER → ESCALATE

The goal is not to remove people from food rescue. It is to remove repetitive coordination work so people can focus on the situations where their judgment actually matters.

What it does

A food-rescue organization operates Relay over its existing network of donors, recipient organizations, and drivers.

In a production deployment, that network could come from an organization's existing systems, partner onboarding, APIs, or integrations. For this hackathon, we use a clearly labelled synthetic rescue network so we can demonstrate the complete coordination workflow without exposing real personal or organizational data.

The participants and rescue scenario are synthetic. The system executing the scenario is real.

Our demonstration begins when Market Square makes 36 prepared chicken meals and 12 bakery items available for rescue.

Relay structures the intake, checks operational constraints, evaluates the network, and creates a rescue plan. Harbor Community Kitchen is initially able to receive the food and a driver is assigned.

Then the plan starts to fail.

Harbor reports a refrigerator failure.

Relay evaluates what changed. Instead of discarding the entire plan, it preserves the 12 bakery items at Harbor, releases the prepared-food allocation, evaluates eligible alternatives, and reassigns the 36 prepared meals to Riverside Shelter.

Then the assigned driver, Maya, cancels.

Relay handles that routine disruption too, replacing Maya with Lena and updating the persisted rescue plan.

Neither routine failure requires human intervention.

Eventually Relay encounters incomplete or ambiguous evidence that it is not authorized to resolve itself.

This time, it stops.

Instead of inventing an answer, Relay creates a human decision boundary. The coordinator resolves the documented exception, after which the workflow continues through verification and completion.

That distinction is central to Relay:

Routine operational problem → Relay acts.

Genuine judgment → Relay escalates.

The public command center makes this visible through rescue states, allocations, driver assignments, autonomous recovery cards, human decisions, operational activity, policy boundaries, and delivery verification.

How we built it

Relay is a full-stack working application rather than a scripted frontend demonstration.

The command center is built with Next.js, React, and TypeScript and deployed publicly on Vercel. The backend uses Python and FastAPI, deployed on Railway, with PostgreSQL, SQLAlchemy, and Alembic providing persistent operational state.

The agent layer is built with the Strands Agents SDK.

We separated agent responsibilities into bounded roles:

  • Intake Agent — turns messy rescue information into strict structured data while preserving what is known, inferred, and unknown.
  • Coordination Agent — reasons about the operational situation and proposes actions through bounded tools.
  • Exception Agent — assists with unusual recovery situations where contextual reasoning is useful.

The agents do not have unrestricted authority over the rescue.

A deterministic Rescue Engine handles eligibility, capacity, timing, allocations, matching, driver assignments, and recovery constraints. An AuthorizedActionService controls which proposed actions may actually mutate operational state.

This separation gave us one of Relay's most important architectural rules:

The LLM never decides food safety.

The LLM can interpret messy information and provide bounded reasoning. It cannot invent preparation times, claim missing storage evidence exists, declare food safe, silently bypass policy, or grant itself additional authority.

Relay uses three operational authority levels:

  • Green — routine actions Relay can perform autonomously.
  • Amber — policy-bound situations requiring additional evidence or constraints.
  • Red — situations requiring human judgment.

Every meaningful state change is persisted and recorded in the rescue timeline, giving the coordinator an audit trail of what happened and why an operational action occurred.

We also deployed Relay's narrow Intake Agent to Amazon Bedrock AgentCore Runtime in us-east-1. This is a real deployed runtime, not a simulated AgentCore integration.

We remotely tested the runtime with normal intake, missing-evidence, and prompt-injection scenarios. A normal request produced structured intake data. Missing critical evidence produced needs_clarification rather than fabricated information. A hostile instruction attempting to expand the agent's authority resulted in human review, while an output containing an authoritative food-safety statement was rejected fail-closed by Relay's deterministic safety guard.

AgentCore runtime invocation evidence is available through Amazon CloudWatch.

We intentionally deploy only the narrow Intake capability to AgentCore rather than claiming that the entire Relay application runs there.

Challenges we ran into

The hardest challenge was deciding where autonomy should end.

It would have been much easier to let an LLM make every decision. That might create an impressive demo, but it would create an operations system that is difficult to trust.

We instead spent significant effort separating probabilistic reasoning from deterministic operational authority.

Recovery was another major challenge. A useful operations agent cannot work only when everything goes according to plan. We had to model rescues as persistent workflows and make recipient capacity changes, driver cancellations, missing evidence, retries, idempotency, concurrency, human decisions, and verification first-class parts of the system.

AgentCore deployment introduced another set of real-world challenges around CodeZip packaging, IAM resource boundaries, runtime invocation, and observability. We deliberately kept the deployed runtime narrow instead of broadening permissions simply to make deployment easier.

Public deployment also exposed problems that local development did not.

Our first deployed hero scenario revealed that the synthetic network was not being reset correctly between repeated demonstrations. We fixed the baseline reset while preserving historical rescues and added regression coverage.

Production verification also exposed a React hydration mismatch caused by a time-dependent greeting being prerendered at build time. We fixed it before submission and reran the complete production workflow.

Those failures were useful: they forced Relay to become a system that works repeatedly, not just once on a developer's machine.

Accomplishments that we're proud of

We are most proud that Relay's strongest moment is not the happy path.

It is what happens when the plan fails.

A recipient can lose refrigeration capacity and Relay replans the allocation.

A driver can cancel and Relay replaces the assignment.

Information can become ambiguous and Relay knows when not to act.

A human can resolve the exception and the rescue can continue through delivery verification and completion.

The demo itself uses synthetic organizations and people, but pressing Run hero scenario does not play a prerecorded animation.

It sends requests through the real deployed application.

The workflow writes to PostgreSQL, evaluates constraints, changes allocations, replaces assignments, records exceptions and recoveries, processes a human decision, verifies delivery, and exposes the resulting state through the same APIs used by the command center.

Relay now includes:

  • A publicly deployed command center
  • A publicly deployed FastAPI backend
  • Persistent PostgreSQL state
  • Deterministic policy and authorization boundaries
  • Real Strands agents
  • A real Amazon Bedrock AgentCore Runtime deployment
  • CloudWatch runtime invocation evidence
  • Autonomous exception recovery
  • Human decision boundaries
  • Delivery verification and audit history
  • Unit and PostgreSQL integration tests
  • Continuous integration covering backend quality, database integration, and frontend validation

Most importantly, we demonstrated something we believe is fundamental to useful agents:

Autonomy is not making every decision. It is reliably making the routine decisions and recognizing the ones you should not make.

What we learned

Building Relay changed how we think about agents.

The difficult part is not giving an agent more tools. It is deciding what authority each tool represents.

An agent that can reason but cannot safely affect the world is mostly an assistant. An agent that can affect everything without boundaries is dangerous.

Useful autonomy sits between those extremes.

We learned to treat agent output as a proposal that must survive structured validation, deterministic policy checks, authorization, persistence, and verification before it becomes an operational action.

We also learned that "human in the loop" should not mean asking a human to approve everything.

If every action requires approval, the agent simply becomes another notification system.

The better boundary is to automate routine situations confidently and make escalation itself intelligent.

We also learned the importance of distinguishing demonstration data from demonstration execution.

Our donor, recipient, driver, food, and disruption data are synthetic.

The API calls, database writes, agent execution, state transitions, recovery logic, human-decision processing, and deployed infrastructure are real.

What's next for Relay

Relay currently focuses on the autonomous coordination layer.

The next step is connecting that layer to real food-rescue operations.

Organizations could create workspaces and onboard or import their existing donors, recipient organizations, and volunteer drivers. Donors could submit available food through integrations or a lightweight portal. Recipient organizations could update capacity and availability. Drivers could receive and respond to assignments through mobile notifications, SMS, or existing volunteer systems.

We would also add organization-level authentication and permissions, richer routing providers, external communication channels, production monitoring, and integrations with existing food-rescue platforms rather than asking organizations to replace systems they already use.

Longer term, Relay could learn from historical operational outcomes while keeping hard safety, policy, and authorization rules deterministic.

The vision is not another marketplace for surplus food.

It is an autonomous coordination layer that helps existing food-rescue networks keep rescues moving when reality stops following the original plan.

Relay doesn't help food rescuers coordinate. Relay coordinates — and asks humans only when human judgment matters.

Built With

Share this project:

Updates

Submission history