NeighborOps AI

Live operations dashboard for Karachi Community Pantry
Five fictional requests with clear live status pills
Persisted Strands tool calls: classification, stock checks, reservations, and volunteer matching
Protected inventory, reservations, and safety thresholds
A real Strands-coordinated delivery with stock and volunteer actions
Volunteer availability, transport, skills, and current workload
Real production human review: ten food boxes cross the protected reserve
Real production needs-information state: no usable location, no allocation

Inspiration

Small community pantries spend too much staff time classifying requests, checking stock, finding volunteers, and following up. Those repeated steps need coordination, while decisions that consume protected resources need a person. NeighborOps AI handles routine work and makes escalation visible.

What it does

For a fictional Karachi Community Pantry, an operator starts a real Strands agent from an operations dashboard. The agent inspects requests and capacity through narrow tools, then classifies, checks stock, reserves, matches a volunteer, creates a task, drafts a notification, or escalates. The five seeded cases cover three routine needs, a missing address, and a ten-box event request that would cross the protected food reserve. The operator can reduce a high-impact allocation to four. The activity timeline records actual operations, and model text alone cannot change stock.

Why an agent

The request path depends on current inventory, location, volunteer capacity, and the outcome of earlier tool calls. Strands chooses the next operational tool based on those results; a chatbot answer without a transaction would not reserve stock or safely schedule a delivery.

How we built it

Next.js on Vercel provides the dashboard. FastAPI on Vercel invokes strands.Agent with 15 registered @tool functions. Its OpenAI-compatible model adapter calls OpenRouter free models, with a free fallback. SQLAlchemy persists requests, resources, volunteers, allocations, decisions, tasks, runs, and audit events in a dedicated Supabase Postgres project over verified TLS. Each serverless invocation atomically claims one new request. The repository includes a migration, idempotent seed, policy tests, and an architecture diagram.

Human control and safety

The model has no unrestricted SQL or message-sending tool. Transactions enforce available inventory, protected thresholds, and volunteer availability; a unique allocation constraint prevents double reservation. A high-impact allocation requires a human decision. Notifications stay as drafts. Provider failure returns a request to a safe retry state without claiming success.

What we verified

Hosted Strands/OpenRouter runs processed all five fictional requests through real tool calls. REQ-001 and REQ-003 are AUTO_APPROVED; REQ-002 is SCHEDULED. REQ-004 reached HUMAN_REVIEW because ten food boxes would leave five, below the protected threshold of eight. REQ-005 is NEEDS_INFORMATION because its location is missing, with no allocation or task. In the live UI, an operator chose REDUCE_ALLOCATION to four boxes for REQ-004; the decision, reservation, volunteer match, and task persisted, leaving REQ-004 SCHEDULED. The final state has two AUTO_APPROVED, two SCHEDULED, and one NEEDS_INFORMATION request; four unique allocations, four unique tasks, and one human decision. Food inventory is 11 available / 13 reserved. A final agent run processed zero requests and left inventory, allocations, tasks, and decisions unchanged.

Challenges and what's next

Free-model availability and tool reliability vary. We kept the model as planner and enforced every mutation at the tool and database boundary; serverless calls are bounded to one request. The data is entirely fictional. Before real use, we would add operator authentication, organization isolation, rate limits, background jobs, intake integrations, configurable policy, and notification delivery. We would measure impact with partner organizations rather than assume time saved.