NeighborNode

Inspiration

Community fridges keep growing everywhere, hundreds of them now, in cities like New York, Philadelphia, Los Angeles, Toronto, and Austin. They work precisely because there's no bureaucracy. No forms, no eligibility checks, no gatekeeping. Anyone can leave food, anyone can take it.

That same lack of structure is what quietly breaks them. Every fridge depends on one volunteer host, a loose network of donors, and whoever happens to see an Instagram post asking for a restock. There's no dispatcher. When a fridge goes empty, it stays empty until someone happens to notice, happens to have food, and happens to have time, all three at once, by luck.

We looked for something that already solved this and came up short. What exists are recipe apps for what's in your own fridge, an unrelated problem, and static maps that show where fridges are, which solves discovery, not operations. Nobody was building the dispatcher. So we built it.

What it does

A fridge host texts "EMPTY" or anything that means the same thing, the system understands free text, not a rigid keyword. From there:

The system finds the nearest open donor offer that fits the fridge's remaining capacity and the food's freshness window. It dispatches the nearest available runner with a text: pickup address, dropoff address, what to bring, suggested route. It logs everything quietly, and on request generates a funder-ready impact report, no manual spreadsheet. Anything that needs real judgment, a food-safety flag, a first-time donor, gets held for a human Coordinator to approve. Everything else runs unattended.

Nobody taking food from the fridge ever touches the system. It only talks to the people keeping the fridge running, and it stays invisible to everyone else.

How we built it

We started from the data layer up rather than from the UI down. Everything the system knows lives in one DynamoDB table, keyed so a fridge's identity and its full event history sit next to each other. That single decision meant the Report Agent never needed its own analytics pipeline, it just queries the same table everything else writes to.

Above that sit small, single-purpose tools: finding open offers, scoring a match, checking the food-safety exclusion list, sending an SMS. Each tool is deterministic where determinism actually matters, distance math, safety checks, and only hands off to the model where judgment is genuinely required.

Each of the five agents, Intake, Forecast, Match, Dispatch, Report, is a Strands Agent wrapping a cluster of related tools with a narrow system prompt. Sitting above all of them is the Orchestrator, itself a Strands agent whose tools are the other agents. It routes inbound events by reasoning about what the message actually says, not a hardcoded switch statement, so something like "5th st fridge dead again" gets correctly parsed, matched to the right fridge, and turned into a status update without anyone writing a regex for it.

The whole thing runs on Bedrock AgentCore Runtime with Nova Micro and Nova Lite doing the reasoning, Pinpoint handles SMS, Lambda and EventBridge glue it together, and the coordinator dashboard is a React frontend with a live map, an approval queue, and one-click reports.

Challenges we ran into

Deploying through SAM surfaced a run of CloudFormation quirks we hadn't hit before, including a cryptic AWS::EarlyValidation::ResourceExistenceCheck that blocked deployments for hours with no clear explanation of what it actually wanted checked. We eventually had to reverse-engineer how SAM packages nested agent dependencies for the Lambda runtime, and manually rebuild and inject Linux-compatible .so binaries for our native-extension packages after discovering our local build artifacts simply wouldn't execute on Amazon Linux. It was a slow, unglamorous few hours, but it forced us to actually understand what's happening underneath sam deploy instead of treating it as a black box.

We also had to be careful about where determinism ends and model judgment begins. Distance and freshness scoring needed to be predictable and testable, but deciding whether a donor is trustworthy enough to skip Coordinator approval is genuinely a judgment call, drawing that line cleanly took a few rewrites of the Match and Intake agents.

Accomplishments that we're proud of

We're proud that the system actually reflects the "agents as tools" pattern properly rather than faking it with one big prompt. The Orchestrator genuinely delegates, and each specialist agent genuinely owns its slice of the problem.

We're also proud that a Coordinator can look at the trace of any single dispatch and see exactly why the system made the call it made, which fridge, which donor, which score, which runner, because AgentCore gives us that observability for free rather than us building it ourselves.

And honestly, we're proud that the person using this the most, the fridge host, never has to learn a new tool. They just text "EMPTY" the same way they'd text a friend.

What we learned

We learned that autonomous AI acting in the physical world needs hard guardrails, not just good prompting. The Dispatch Agent is built to check every offer against a food-safety exclusion list, raw meat, raw poultry, unpasteurized dairy, home-canned goods, before it ever reaches a runner, and to route anything flagged to a human Coordinator rather than let the model decide on its own. Building that habit into the agent, checking first, escalating by default, taught us more about designing AI that fails safely than any amount of reading about AI safety in the abstract.

We also learned a lot about AgentCore's memory strategies in practice, semantic and summarization memory changes how a multi-turn dispatch cycle feels, especially when a runner declines and the system needs to remember why before trying the next candidate.

What's next for NeighborNode

We want to move past a single-city pilot into a real multi-fridge network, which means building trust scoring for repeat donors instead of treating every offer the same. We also want the Forecast Agent to get ahead of empty fridges rather than just reacting to them, using time-of-day and day-of-week patterns to nudge donors before a fridge actually hits zero. And we'd like the impact reports to plug directly into the tools food banks and nonprofits already use for grant reporting, so a Coordinator never has to translate our data into someone else's spreadsheet.