Inspiration
Disaster coordination turned out to be the perfect problem to address with multi-agent orchestration. When a wildfire hits, the bottleneck isn't information — it's coordination between independent parties who don't share a system: shelters tracking their own capacity, transport volunteers managing their own availability, medical caches held by different organizations. No single LLM call can query all of them simultaneously, run a real matching algorithm, and monitor unresolved needs around the clock. That requires agents.
What it does
Dispatch is an autonomous disaster relief coordination system. A coordinator types one plain English message — "Wildfire in Altadena. Need shelter for 40 people, transport for elderly residents, and insulin for 3 diabetics within 10 miles" — and four autonomous agents coordinate in real time to produce a unified action plan with specific resources, distances, and contact information in under 60 seconds.
A separate AlertAgent runs 24/7 with no human trigger. Ask it "any alerts?" and it reports which critical needs have gone unmatched beyond the response threshold — something no chatbot can do because chatbots only act when asked.
How we built it
Built on Fetch.ai's uAgents framework with four agents, each with a distinct role that justifies its existence:
OrchestratorAgent — the only agent ASI:One talks to. Parses natural language intent with Claude, fans out to sub-agents, and synthesizes the final response.
RegistryAgent — stateful resource database. Holds live availability of all shelters, transport, and medical resources. Answers queries, accepts updates, and persists state across the system lifetime using ctx.storage.
MatchingAgent — pure algorithm. No LLM. Scores every resource against every need using haversine distance, capacity, urgency weighting, and keyword relevance. Returns ranked assignments.
AlertAgent — the only truly autonomous agent. Monitors unmatched critical needs on a 30-second interval with zero human trigger. Stores escalations and reports them on demand.
Data Pipeline — before the system runs, Browser Use autonomously navigates real public emergency resource directories, scrapes live shelter listings, transport services, and medical facilities, and chains a Claude API call to standardize the raw scraped data into our resource schema. This populates the RegistryAgent with real, location-accurate data rather than hardcoded placeholders. If the pipeline fails for any site, the system falls back to curated seed data automatically — the agents never go down.
All agents communicate via Fetch.ai's uAgents message protocol, are registered on Agentverse, and are accessible through ASI:One's natural language interface.
Challenges we ran into
The "fake multi-agent" trap. Our first architecture was just three agents doing the same thing — search a dictionary and format with Claude. A judge would see through that in 30 seconds. We scrapped it and rebuilt around the question: what is each agent's genuine reason to exist?
ASI:One session management. Pushing proactive alerts from the AlertAgent through ASI:One's chat interface doesn't work reliably — ASI:One treats sessions as complete after the first response. We redesigned the AlertAgent to store escalations rather than push them, making alerts pull-based instead. Better architecture anyway.
Bureau vs mailbox. Running all agents together with Bureau bypasses individual mailbox registration, causing 404s when external services try to reach sub-agents. Took significant debugging to understand the communication model.
Async response collection. When the orchestrator fans out to multiple agents simultaneously, responses arrive asynchronously. We built a session storage pattern using ctx.storage as a scoreboard to collect all responses before synthesizing.
Accomplishments that we're proud of
Every agent has a defensible answer to "why does this need to be a separate agent." The RegistryAgent maintains live state. The MatchingAgent runs real math, not LLM guessing. The AlertAgent acts without being asked. The OrchestratorAgent coordinates without knowing the implementation details of its sub-agents.
The end-to-end flow works through ASI:One with no custom frontend — a coordinator types a disaster scenario in natural language and gets a structured action plan with real contacts, distances, and priority sequencing in under 60 seconds.
What we learned
Fetch.ai's value isn't in making LLM calls cleaner — it's in enabling genuinely independent agents to coordinate without trusting each other or sharing a central system. The moment we stopped asking "how do we use agents?" and started asking "what problems require agents?", the architecture became obvious.
ASI:One is most powerful when agents are designed around it from the start, not retrofitted. Agent descriptions and keywords on Agentverse directly determine when ASI:One routes to your agent — treat them like SEO.
What's next for Dispatch
Live data integration — connect the RegistryAgent to real APIs: FEMA disaster declarations, 211 social services directory, Red Cross shelter finder. The agent architecture is already designed for this — swap the data source without touching anything else.
Real resource registration — let actual organizations register their resources as agents on Agentverse. A Red Cross chapter runs their own ResourceAgent. A hospital runs their own MedicalAgent. Dispatch discovers them dynamically at runtime — no central database, no middleman.
Payment protocol — implement Fetch.ai's Payment Protocol so resource providers can be compensated for their services through the agent network, creating economic incentives for participation.
Chat Session: https://asi1.ai/shared-chat/acf041e3-3202-4206-b239-17d3aaf6f6e2
Built With
- browseruse
- claude
- fetch.ai
- python
Log in or sign up for Devpost to join the conversation.