Inspiration

Girls at under-resourced South African schools miss class, and sometimes drop out, when their school runs out of donated sanitary pads. NGOs do supply stock, but tracking it across many schools is manual, so nobody notices a shortage until it's already happened and a school day is already lost. The idea started simple: surplus at one site can cover a shortage at another, the hard part is catching it in time instead of after a phone call.

What it does

Four agents built on the Strands Agents SDK work together to keep pad stock flowing across a network of schools and community centers. A Stock Monitor agent reads current levels across every site. A Forecast agent flags anyone heading for a shortage within five days and ranks by urgency. A Matching agent searches the network for surplus and proposes a transfer, or, if there's genuinely nothing to reallocate, escalates to a human coordinator instead of inventing a donor that doesn't exist. A Delivery Planner agent turns a confirmed match into a concrete plan (who to contact, how much, by when) and executes the transfer. A standalone browser dashboard shows the whole thing running live, including both outcomes side by side.

How we built it

Four separate Strands agents, each with one job and its own tools, chained so each agent's output feeds the next agent's prompt. Everything runs on Amazon Bedrock (Nova Lite). The demo has three layers: a credential-free mock (demo_mock.py) that mirrors the real logic for quick testing and video recording, the real orchestrated pipeline (orchestrator.py) hitting live Bedrock, and a static HTML dashboard that visualizes both the normal-match and failure-escalation scenarios without needing a server. We also containerized the pipeline with Docker for portability, and wrote (but didn't deploy) an Amazon Bedrock AgentCore Runtime entrypoint as a next step.

Challenges we ran into

Almost the entire challenge was AWS account access, not the agents themselves. Every Bedrock call failed with ValidationException: Operation not allowed, identically across different models, different regions, and even the raw AWS CLI with no application code involved. We chased IAM permissions and a real Service Control Policy before AWS Support gave the actual answer: the account was too new to be trusted with Bedrock model access yet, a fraud safeguard, not a bug, and support couldn't override it themselves. The fix wasn't technical, it was asking the hackathon organizers to help unblock access on their end. Once that cleared, a second, smaller bug surfaced: our four agents were running as isolated calls with no memory of each other, so the Delivery agent had no idea what the Matching agent had just decided. Fixed by passing each agent's output explicitly into the next agent's prompt.

Accomplishments that we're proud of

The escalation path. It would have been easy to let the Matching agent always "find" something to keep the demo looking smooth. Instead it says plainly when there's genuinely no surplus anywhere in the network, and hands off to a human rather than fabricating a solution. That's the one design decision in this project we'd defend without hesitation, an agent that knows the edge of what it can actually solve is worth more than one that always has an answer.

What we learned

When something fails identically across every model, every region, and even a raw CLI call with no framework involved, stop debugging your code and go find the human who can see the part of the system you can't. Also: state handoff between agents isn't automatic just because they're called in sequence in the same script, each agent only knows what you explicitly hand it.

What's next for Period Poverty Distribution Agent

Replace naive "most spare stock" matching with distance-aware logistics. Connect to however schools and NGOs already track inventory instead of mock data. Route the delivery plan to coordinators over SMS or WhatsApp, given real connectivity constraints at many of these sites, rather than just printing it. And finish the Amazon Bedrock AgentCore Runtime deployment we scoped but didn't ship, turning the pipeline into a real hosted service instead of something that only runs locally or in a container.

Built With

Share this project:

Updates

Submission history