NeighborOps AI

NeighborOps AI is a resource-coordination dashboard for community pantries. Its rule is "Automate routine coordination. Escalate judgment." Four of us built it for the Agents for Humans Hackathon on Devpost, in the Good Neighbor Agents track: Talal Khawaja, Umer Anis, Aqeela Urooj and Safa Kamran. It is an operations dashboard, not a chatbot. The demo organisation, a Karachi community pantry, and every person in it are fictional.

Problem

Small community organisations receive requests through scattered channels, and a small team can't classify each one, compare it with stock, find a free volunteer and follow up fast enough. Much of that work is routine. Some of it isn't. Giving ten food boxes to a community event can drain a reserve meant for emergencies, and that call belongs to a person.

How it works

An operator clicks Run Agent. A Strands agent, running on FastAPI, picks among 15 narrow tools, such as classify_request, check_safety_threshold, reserve_inventory, match_volunteer, create_delivery_task and request_human_approval. It receives their real results and either continues or escalates. The model has no unrestricted database tool, so its text alone can't reserve stock or change a status. Only a policy-enforcing tool can.

Data lives in Supabase Postgres, accessed through SQLAlchemy, with SQLite for a zero-account local demo. Reservations use a conditional update and a unique allocation key, so a retried run can't double-reserve. On serverless hosting, each invocation claims one request atomically and the frontend repeats the call until the queue is empty. The Next.js frontend and the API are separate projects on Vercel. Strands talks to free models on OpenRouter through its OpenAI-compatible provider.

The seeded demo exercises three paths. Routine requests are allocated and scheduled. A request with no location is marked as needing information, with nothing allocated. A ten-box event request would take food stock below the protected threshold of eight, so it goes to human review. In the hosted run, an operator reduced it to four boxes in the live UI, and the reservation, volunteer match and task followed.

Key decisions and trade-offs

• Policy in tools, not prompts. Free-model output varies, but tool-level rules are enforced whatever the model says.
• Honest failure. If the provider fails, the dashboard shows a generic retry state and never claims fabricated success.
• Nothing is sent. Notifications are drafts. There is no automatic client or beneficiary contact.
• Known gaps. The public demo has unauthenticated mutating endpoints, so it must only ever hold fictional data.

What's next

Before any real organisation uses it, the team's list is operator authentication, organisation isolation, intake integrations, rate limits, background jobs, policy configuration and real notification delivery. After that, we would measure time saved with partner organisations rather than assume impact from a demo.

Small community organisations get more help requests than their staff can classify, check against stock, schedule and follow up by hand. Most of those steps are repetitive, but some, especially the ones that use up protected inventory, need human judgement.

A Strands agent works through 15 narrow operational tools to classify requests, check stock, reserve inventory, match volunteers, create tasks and draft notifications. Policy lives in the tools and the database, not in the prompt. Anything that would breach a protected reserve becomes a human-review record instead of an allocation.

• Hosted runs on 13–14 Sep 2026 processed all five fictional requests with real tool calls: two auto-approved, two scheduled, one waiting on missing information, and one human decision recorded. A final run processed zero requests and changed nothing.

• Treat the model as a planner, not the source of truth: every operational change is validated at the tool and database boundary.
• Free models vary in availability and tool-call reliability, so the dashboard has to stay useful, and honest, when the model is down.