Inspiration
Roughly a third of the food we produce is wasted while millions of people are food-insecure. The nonprofits fighting this — food banks, community kitchens, and rescue networks — already coordinate in Slack, but that coordination is chaos: donation offers arrive as free text with expiry clocks ticking, recipient needs are buried in channel history, and volunteers get reached by luck. Dedicated food-rescue platforms exist, but they all demand that every bakery, shelter, and volunteer adopt yet another app. We asked a simpler question: what if the dispatcher was an AI agent living in the channels these teams already use?
What it does
Plenty watches a donations channel. When a donor posts a messy, natural-language offer — "day old bagels n stuff, maybe 30ish, need em gone in like an hour" — the agent extracts the structured details (food type, quantity, pickup deadline), then uses Slack's Real-Time Search API to search the live conversation history of the requests channel and find which organization needs this food most, right now. It posts an explained recommendation — which org requested this food, how far away they are, and whether they've already been served today — with a confidence level and a runner-up. A volunteer claims the pickup in one click, and the card updates in place. Every rescue is logged to an impact feed (meals provided, kilograms of waste prevented) and rolled into a daily digest. Plenty also acts without being asked: a proactive scanner spots donations about to expire unclaimed, finds organizations whose past requests match, and offers to notify them — before the food goes in the bin. The agent recommends and asks; a human always makes the final call.
How we built it
Plenty is built with Bolt for Python over Socket Mode and uses two of the challenge's core technologies live at runtime. Real-Time Search API is how Plenty decides who receives food: every offer triggers an assistant.search.context query against the workspace's live conversation history to surface organizations that actually requested that food, then ranks them — every reason on the recommendation card traces to a real message. Model Context Protocol computes distance: the matcher holds a persistent MCP ClientSession (official mcp Python SDK) connected over stdio to a geo MCP server exposing a distance_km tool, so every "X km away" figure comes from a genuine tool call, one per candidate organization. An LLM (Gemini) handles the messy-text extraction and the transparent, cited match reasoning. Block Kit cards make every decision actionable in a click; state lives in SQLite.
Challenges we ran into
Turning genuinely messy, human donation messages into dispatch-grade structure reliably. Getting Real-Time Search to return useful matches — we learned that short keyword queries surface real results where verbose natural-language questions return nothing, and that results are best scoped to the requests channel in code, since the endpoint has no reliable channel-scope parameter. Wiring MCP as a persistent session rather than a per-call subprocess. And designing proactive behavior that is helpful but bounded: the agent surfaces and suggests, but a person always decides.
Accomplishments that we're proud of
We got two core technologies genuinely executing live, not stubbed — Real-Time Search powering every recipient decision and MCP powering every distance calculation, both confirmed in logs against a real Enterprise Grid sandbox. The agent turns a deliberately messy, misspelled offer into a correct structured dispatch in seconds. And we kept the design honest: Plenty explains every recommendation with reasons a human coordinator can verify, and never takes an irreversible action without a person's click.
What we learned
That the hard part of an agent isn't answering questions — it's deciding and acting. Real-Time Search turned out to be the difference between a chatbot and a dispatcher: searching live workspace history is what lets Plenty reason over context no static database would have. We also learned the practical texture of the platform — that search needs a user token and specific scopes, that keyword queries beat prose, and that a genuinely useful agent is mostly careful plumbing between search, reasoning, and action.
What's next for Plenty
The core engine — read the chaos, search the context, dispatch the help — generalizes well beyond food. The same pattern extends to shelter-bed availability, supply requests, volunteer dispatch, and disaster-response coordination. Plenty starts with dinner.
Log in or sign up for Devpost to join the conversation.