NourishNet - Turn local surplus into meals

NourishNet uses AI agents to find surplus food, match it to nearby need, and notify volunteers — with explainability and a human-in-the-loop for safety. Fast, fair, and human-centered.

Comment

NourishNet — AI for Zero Hunger

Inspiration

Every day, perfectly good food is discarded while families and community groups go hungry. In many cities the problem isn’t a lack of food or goodwill — it’s coordination: spotting surplus, prioritizing who most needs it, and delivering timely, trustworthy notifications so volunteers can act.

We were inspired by three ideas:

  1. Small acts scale — a bakery’s unsold sandwiches become dozens of meals if matched fast.
  2. AI as a connector, not a replacement — automation can surface opportunities but humans must remain in the loop for safety and dignity.
  3. Open, auditable systems — communities must be able to inspect and trust how AI makes decisions.

NourishNet started as a simple question: how do we turn local surplus into local meals — automatically, fairly, and safely?

What it does

NourishNet is a multi-agent prototype that detects surplus food, prioritizes matches, and notifies people who can collect it — while recording an auditable decision trail and escalating uncertain cases to humans.

Core features

  • Scout — vision & extraction: Detects surplus from photos (or manual listings), runs OCR and object detection, outputs structured data (items, quantities, expiry) with a confidence score.
  • Coordinator — matching & prioritization: Scores and ranks candidate recipients/organisations by urgency, distance, dietary needs, and fairness constraints. Produces a match score and triggers elicit tasks for low-confidence cases.
  • Logistics — multi-channel notifications: Sends short, actionable messages to recipients and volunteers (in-app + SMS/chat-like mock channels), including pickup codes and quick Confirm actions.
  • MCP (Model Context Protocol) hub: Routes events between agents, keeps logs, and provides a single source of truth for agent messages and decisions.
  • Human-in-the-loop Supervisor: Escalates ambiguous or high-risk listings to a human reviewer who can Accept / Edit / Reject, then re-run the automated flow.
  • Audit & Explainability: Every match includes confidence, a short explanation (why this recipient), and an audit record for later review.
  • Demo UI (mobile + web): Role-aware screens for donors, recipients, volunteers, and supervisors, plus an interactive demo player with canned scenarios.

Demo scenarios included

  • Happy path (detect → match → notify → confirm).
  • Low-confidence elicit (supervisor clarifies and releases).
  • Urgent broadcast (large listing triggers rapid distribution).

Impact snapshot (demo metrics)

  • Meals rescued: 1,247
  • CO₂ avoided: 3.24 t
  • People reached: 89
  • Today rescued (demo): 45

How we built it

We focused on modular, composable components so the system is understandable, testable, and extensible.

Architecture (high level)

[Donor app / Scout image upload]
          ↓
       Scout agent (vision + OCR)
          ↓ (structured listing + confidence)
       MCP hub (event routing, audit)
          ↓
   Coordinator agent (prioritization, matches)
          ↓ (match score or elicit)
   ┌──────┴───────┐
   │              │
 Logistics      Supervisor
 (notify)      (human-in-loop)

Key technologies & components

  • Vision & OCR: lightweight object detection + OCR pipeline that extracts items, qty, expiry and a confidence score. We simulate and feed realistic OCR outputs in the demo to highlight edge cases.
  • Agents & Orchestration: modular agents (Scout / Coordinator / Logistics) connected via a central MCP hub. Orchestration logic implemented as event handlers and simple policy rules. We prototyped agent orchestration using the OpenClaw / FLock conceptual model so behavior is composable and auditable.
  • Models: prototyped with small, fast models for proof-of-concept. (In the tech stack we demonstrate how multiple model endpoints — e.g. Llama 3.1 / Mistral 7B / Gemma 2B — could be used for language/semantic tasks, though the demo uses lightweight alternatives tuned for latency.)
  • Data & Audit: every agent decision is logged as an event (timestamped JSON) to produce a readable audit trail and enable supervisor review.
  • Notifications: simple in-app channel plus mock SMS/chat payloads for the demo. Messages are designed to be one-action (Confirm) and short.
  • UI & Prototype: role-aware mobile and web mockups created in Figma with a demo player to run seeded scenarios. The UI highlights match scores, confidence, audit entries, and escalation actions.

Demo assets & fixtures

  • Pre-generated images (bakery tray, pastries, salads).
  • OCR mock outputs and agent event sequences for three canned scenarios.
  • Dashboard metrics JSON and sample timelines for the user interface.
  • A simple demo player that stream-replays event sequences so judges can watch the flow in real time.

Challenges we ran into

Building a trustworthy, useful system surfaced a set of practical challenges — many of which are central to deploying AI responsibly in the real world.

  1. Noisy vision & OCR

    • Food images are varied: lighting, packaging, and handwritten labels make OCR error-prone.
    • We addressed this by adding confidence thresholds and an elicit workflow to route low-confidence cases to humans.

  2. Prioritization fairness

    • Matching purely on proximity favors dense neighborhoods; we needed to bake in fairness and dietary needs.
    • We implemented transparent prioritization rules (urgency, distance, dietary tags, fairness quota) and surfaced the scoring so supervisors can audit.

  3. Notification reliability & UX

    • Users have different device capabilities and preferences. Messaging must be short, action-oriented, and work across channels.
    • For the demo we built an in-app flow and mock SMS payloads and recommended multi-channel fallbacks in production.

  4. Privacy & consent

    • Handling phone numbers and contact flows raises privacy concerns.
    • We implemented opt-in flows, minimal retention of PII, and clear microcopy about data usage. The design includes easy opt-out and data deletion steps.

  5. Human-in-the-loop ergonomics

    • Supervisors need a compact, fast UI to handle elicit queues without fatigue.
    • Designing a mobile-friendly supervisor queue with clear context (image + suggested parse + impact estimate) required several iterations.

Accomplishments that we're proud of

  • End-to-end prototype demonstrating detection → match → notification → confirmation flows, with mock event streams that animate the full lifecycle.
  • Human-in-the-loop safety: a supervisor flow that can Accept/Edit/Reject low-confidence listings while preserving an audit trail.
  • Explainability: every automated decision includes a short reason and a confidence score — not a black box.
  • Demo-ready scenarios & assets: 3 playable scenarios (happy path, elicit, urgent broadcast) seeded with real-looking images, OCR outputs, event logs and notification payloads so judges can see the system behave predictably.
  • Impact visualization: dashboard mock metrics (meals rescued, CO₂ avoided) with mapping to live demo actions to make impact tangible.
  • Open-source & transparent: code + architecture notes on GitHub so partners can evaluate and extend the system.

What we learned

  • Human oversight is not optional. Low-confidence cases occur often — routing them to fast, simple human review preserves dignity and prevents mistakes.
  • Confidence scores are powerful UI primitives. Showing “92% match” or “58% OCR confidence → escalate” builds trust and lets people make informed choices.
  • Simplicity in messaging wins. Volunteers and recipients prefer one-click confirmations and short, unambiguous pickup instructions.
  • Design for local context. Prioritization rules must be configurable per city/community — what’s “fair” in one place won’t fit another.
  • Open, auditable processes accelerate partner trust. Organizations are more willing to pilot when they can inspect logs, model choices, and escalation flows.

What’s next for NourishNet — AI for Good

We built a prototype and a demo that proves the concept. Next steps focus on pilot readiness, safety hardening, and partnerships:

  1. Pilot with local partners. Run short pilot projects with bakeries/food banks and volunteer groups to validate assumptions (true match rates, pickup reliability, average time-to-rescue).
  2. Improve vision & NLU models. Integrate stronger on-device OCR or server-side vision models, add multilingual parsing, and tune confidence calibration.
  3. Expand channels & integrations. Add real SMS integration, improve accessibility (IVR for low-connectivity users), and provide an API for NGO partner systems.
  4. Policy & fairness tooling. Build a small admin UI for cities/NGOs to tune prioritization rules and quotas, and to audit fairness metrics.
  5. Metrics & evaluation. Define measurable pilot KPIs: percent of listings successfully rescued, false-positive rate, time-to-match, volunteer drop-off rate, and social impact metrics like meals/CO₂.
  6. Governance & community review. Open a public review of ethical guardrails, invite experts to audit our approach, and publish a short methodology doc for the hackathon audience.

NourishNet is a small, pragmatic application of AI that prioritizes people. It is designed to transform the many daily moments of surplus and need into coordinated rescues — quickly, fairly, and transparently. We bring together lightweight vision, policy-driven matching, and human-in-the-loop safety to make an immediate social difference.

We’re excited to iterate with partners, pilot in the field, and keep building toward a future where surplus is a source of nourishment — not waste.

  • Thanks to the Changemaker League: AI for Good for the opportunity and to the sample pilot partners who helped shape the workflow.

Built With

  • ai
Share this project:

Updates