What inspired this
In 2025, several children died at Camp Mystic near Austin during a flash flood — not because warning data didn't exist, but because nobody was coordinating it with what was actually happening on the ground. Around the same time, I was reading about earthquake and flood responses across Asia where the same pattern kept appearing: sensors said one thing, citizens reported another, and there was no clear process for deciding which source to trust.
That specific gap — between what instruments measure and what people actually experience — became the foundation for Lifeline Relay.
What it does
Lifeline Relay runs four Qwen-powered agents across the full disaster lifecycle, all sharing a single Disaster Memory:
- WatcherAgent — scores zone risk from weather signals using Qwen-Plus reasoning, not just threshold checks
- ResponderAgent — triages SOS messages with vulnerability priority: messages mentioning children, elderly, or disabled people get automatically escalated
- CoordinatorAgent — detects conflicts when sensors and citizens disagree, uses Qwen to arbitrate which source to trust, then requires human approval before acting. Reject the recommendation and the zone reverts to the original sensor reading — real consequence, not a cosmetic checkbox
- RecoveryAgent — analyzes real damage photos using Qwen-VL-Plus (actual image bytes, not text descriptions), weights severity by each zone's SOS history, and recommends concrete resource dispatch constrained by real inventory (helicopters, boats, medical supplies)
Every decision is logged to a live Decision Timeline. Human-in-the-loop checkpoints exist at every critical moment.
How I built it
- Backend: FastAPI on Alibaba Cloud ECS (US Virginia region)
- Agents: Four Python agent files sharing a single in-memory Disaster Memory store
- AI:
qwen-plusfor all text reasoning,qwen-vl-plusfor real vision analysis on actual flood photos — both through the same Alibaba Cloud endpoint - Dashboard: Plain HTML/JS served directly by FastAPI — no separate frontend framework, kept simple by design
- Demo sequence: 5 guided buttons that run through the full disaster timeline (9AM weather signals → 10:45AM conflict detection → 11:30AM damage assessment)
Challenges I faced
Alibaba Cloud security groups — the biggest infrastructure wall early on. Port 80 was open in the rules, the app was listening, but traffic still wasn't reaching the instance. Turns out there's a hidden "inbound default blocked" policy that isn't visible in the normal security group rules table. Found it through Alibaba's built-in Network Connectivity Diagnosis tool. Not obvious, but the tooling is there once you know where to look.
Getting structured insights from Qwen-VL — the vision model works well, but getting it to return consistent, parseable JSON with specific structured fields (water level, structural damage flag, visible hazards, people count) required careful prompt engineering. Early versions returned free-form descriptions that were readable but not usable by downstream code. The fix was being very explicit in the system prompt about the exact JSON shape expected, and adding a fallback parser that strips markdown code fences Qwen sometimes wraps around JSON responses even when asked not to.
Designing a demo that tells the story clearly — with four agents and three phases, it was easy to build something that worked but was impossible to follow in three minutes. The challenge was collapsing the whole disaster lifecycle into five sequenced buttons that a reviewer could watch unfold in real time without switching screens or losing the thread. Every button had to produce an immediately visible effect — zone cards changing color, agent status flipping, conflict cards appearing — so the cause and effect was obvious without narration.
Cross-phase memory consistency — getting four agents to share one memory store without race conditions or stale reads took more design work than the individual agents themselves. WatcherAgent's risk assessment feeds CoordinatorAgent's conflict detection, which feeds RecoveryAgent's priority weighting. Sequencing matters, and bugs here are subtle — the system looks like it's working until you notice a priority score that doesn't match the zone's actual history.
The conflict headline bug — CoordinatorAgent was reporting "sensor said CRITICAL" when the sensor had actually said LOW, because the zone's risk level was being read after it had already been mutated by the escalation logic. Fixed by capturing the original value before any mutation happens. A reminder that explainability bugs matter as much as logic bugs — a wrong explanation with a correct outcome still undermines trust in the system.
Stale files on the server — multiple times during development, a file uploaded to GitHub via drag-and-drop landed at the wrong path (e.g. backend/schemas.py instead of backend/app/models/schemas.py), silently shadowing the correct file. The running server was importing the old version while the new version sat unused at the wrong location. Lesson learned: always use GitHub's in-browser edit (pencil icon) for existing files, never drag-and-drop uploads for updates.
What I learned
- Separating responsibilities across agents makes each one simpler and more debuggable than one monolithic prompt
- Human-in-the-loop works best when the override has real consequence — not just a label, but an actual state change
- Qwen-VL-Plus returns genuinely specific descriptions from real photos — water level estimates, structural damage flags, visible hazards — not generic responses
- 100% API success rate across 163 real Qwen Cloud calls throughout development
Built with
qwen-plus · qwen-vl-plus · alibaba-cloud-ecs · fastapi · python · multi-agent-systems · human-in-the-loop
Built With
- agent-society
- alibaba-cloud
- alibaba-cloud-ecs
- conflict-resolution
- disaster-response
- fastapi
- html
- human-in-the-loop
- javascript
- multi-agent-systems
- pydantic
- python
- qwen-plus
- qwen-vl-plus
- uvicorn
Log in or sign up for Devpost to join the conversation.