Inspiration I run Macknificient World, a nonprofit serving families in Tampa Bay — kids' mental health, neurodivergent support, financial hardship, affordable activities. Every time a case worker sits down with a family, the first hour goes to the same manual research: is this program still running, does it serve this zip code, can this family actually afford it, is the phone number even current anymore. That work never gets easier because it's never saved — it gets redone from scratch for the next family, and the next. When I saw the Good Neighbor Agents track, it was an exact match for a problem I already live with: repetitive, judgment-light research that's exactly the kind of work an agent should absorb, so the human time goes to the part that actually needs a human — talking to the family.
What it does Two cooperating agents built on the Strands Agents SDK, running on Claude via Amazon Bedrock:
The Family Matching Agent takes a plain-language description of a family's situation — a child's age, their needs, a zip code, any constraints like cost or transportation — and returns a ranked, explained shortlist pulled from a database of vetted local resources. No forms, no dropdown filters, just a conversation. The Discovery & Vetting Agent runs in the background. It re-checks existing resources for dead links and outdated information, and searches a curated set of local directory pages for new candidates. Critically, it doesn't auto-approve anything ambiguous — a possible duplicate, an unclear eligibility rule, a service-area mismatch — those get escalated to a human review queue instead.
Together they mean the database gets more accurate and more complete on its own, and a case worker gets a real answer in seconds instead of an hour of tab-hopping.
How we built it I scoped it to Tampa/Hillsborough County across four categories — mental health, neurodivergent support, financial assistance, youth activities — and hand-researched 25 real local resources as a seed dataset rather than starting from anything synthetic. Both agents share one SQLite database and one small toolset (query_resources, db_read, db_write, mark_verified, flag_for_review, fetch_url), all built as Strands @tool functions with parameterized SQL and a table/column whitelist, so nothing an agent hallucinates can touch the database outside its intended lane. The Discovery Agent runs on a schedule via a cron-triggered shell script. The front end is a Streamlit chat app styled to match Macknificient World's actual branding, so it's something a case worker would recognize as ours.
Challenges we ran into The most instructive failure: the first time I let the Discovery Agent loose on a real "find new resources" pass, it did its job too well — it went past the curated source list I gave it and started guessing domains for organizations it recognized from its own training data, racking up 50+ web requests and a pile of 404s in a single run. It still found two legitimate resources that way, but an agent that free-associates its way around the open web isn't the trustworthy, scoped tool a nonprofit's data needs. I tightened the system prompt to restrict it to given URLs and links actually found on a fetched page, which cut that same pass down to a handful of calls with no loss in quality. It was a good reminder that "give the agent a tool" and "give the agent a bounded tool" are different design problems.
Accomplishments that we're proud of Getting the escalation logic to actually hold up under a real run, not just look good on paper — the Discovery Agent correctly caught a rebranded 211 hotline, a service-area mismatch on a mental health provider, and several possible duplicates, and routed every one of them to a human review queue instead of guessing. That's the whole thesis of the Good Neighbor track in one behavior: autonomous where it's safe, human-in-the-loop where it isn't.
What we learned That the line between "helpful autonomy" and "unbounded search" is thin and has to be designed on purpose — an agent with a web-fetch tool and no explicit scope will use it exactly as broadly as it's capable of, not as broadly as you intended. Also just how far a small, well-chosen toolset goes: four simple functions against one SQLite table were enough to support two very different agents doing very different jobs.
What's next for Macknificient World Resource Navigator A review-queue interface so a case worker (not just SQL) can approve or dismiss what the Discovery Agent flags; expanding the hub-page list so discovery covers more of what's actually out there (youth sports leagues are a known gap right now); and, if it earns its complexity, deploying on Bedrock AgentCore Runtime with an EventBridge schedule instead of local cron — the Technical Implementation stretch goal I scoped out of the initial build to make sure the core product shipped first.
Built With
- amazon-bedrock
- amazon-web-services
- beautiful-soup
- cron
- github
- python
- sqlite
- strands-agents-sdk
- streamlit

Log in or sign up for Devpost to join the conversation.