DEV Community

Building an Offline-First Bushfire Response Platform With Hermes Agent

ujja on May 28, 2026

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent What I Built Project Haven is an AI-powered emergency r...
Collapse
 
xulingfeng profile image
xulingfeng

Great to find another Hermes user working on real-world problems! Just followed you 🀝

Collapse
 
ujja profile image
ujja

Thank you β™₯️. Always nice to connect with people.

Collapse
 
itskondrat profile image
Mykola Kondratiuk

offline-first AI is a constraint most frameworks wave away. how are you handling action replay when connectivity comes back - idempotent calls or a queue?

Collapse
 
ujja profile image
ujja

Good question. To be completely honest, I haven't shipped action replay yet.

Right now, if the AI call can't reach Hermes, the app falls back to a local keyword-based response so users still get basic guidance offline. When connectivity comes back, nothing gets replayed β€” the next message just goes to Hermes as normal.

The read side is much further along than the write side at the moment. Alerts, recommendations, and other data are cached with Workbox so the app remains usable offline.

The queue + UUID/idempotency approach is actually what I have in mind for the next iteration, but it's still on the roadmap rather than in production today.

Collapse
 
itskondrat profile image
Mykola Kondratiuk

the 'next message starts fresh on reconnect' model actually works for most guidance flows β€” replay gets hairy once you have partial multi-turn context built offline. when you do tackle it, an idempotent action key per user-turn plus a small pending queue is probably the cleanest path before you need full event-sourcing.

Collapse
 
benjamin_nguyen_8ca6ff360 profile image
Benjamin Nguyen

Great job, Ujja! It is really neat application to detect wildfire because we need this kind of technology these days. My own country have huge wildfire for the last 3 years now. My government deploys AI application to detect wildfire since a week ago.

Collapse
 
ujja profile image
ujja

Thanks Benjamin :)

I'm sorry to hear your country has been dealing with major wildfires as well. It's encouraging to see governments starting to use AI in this space, especially for early detection and risk assessment, where even a small improvement can make a big difference.

Hopefully, we'll continue seeing more technology used to support the people and emergency services dealing with these events.

Collapse
 
benjamin_nguyen_8ca6ff360 profile image
Benjamin Nguyen

Ah, thank you! I agree with you completely. AI gives us a huge advantage in monitoring and predicting wildfire outcomes. My government is focusing more on saving money and reducing public civil service spending, which makes operations leaner and more productive more like the private sector.

Thread Thread
 
ujja profile image
ujja

That's great. I think that's true with all the governments atm.

Thread Thread
 
benjamin_nguyen_8ca6ff360 profile image
Benjamin Nguyen

yep, it is!

Collapse
 
xulingfeng profile image
xulingfeng

Great questions β€” and you've clearly thought this through. The semantic merge per entity type approach makes a lot of sense, and taking the minimum for evacuation capacity is the right call (safer to under-report in a crisis).

For our Hermes setup, the architecture naturally sidesteps most write-write conflicts: each agent owns its domain. My agent on the Windows PC handles the MQTT message queue, and the sibling agent on the VPS is a consumer. Single writer per queue β€” no CRDTs needed, just old-fashioned idempotency keys. For state that crosses agents, we use a simple flag-based approach.

The harder problem for us wasn't conflict resolution β€” it was the UX of offline queues. Are you doing anything to show a "pending sync" indicator while writes are queued locally? We found that was the bigger challenge than the merge logic itself.

Collapse
 
xulingfeng profile image
xulingfeng

@ujja I went with a similar direction β€” per-entity merge rules instead of generic CRDT, and per-agent domain ownership sidesteps most conflicts entirely.

Capacity minimum makes sense. Over-evacuating burns resources, under-evacuating burns lives. Minimum is the correct conservative bound.

For edge cases where two agents touch the same entity (rare but happens), timestamp last-write-wins on idempotent fields. Not elegant, pragmatic.

Did you add JSON Schema response validation on the MCP side, or keeping it looser?

Collapse
 
jgsabedra profile image
JoΓ£o Gabriel Sabedra Vieira

This is way beyond my level right now (I just published my first article in HTML/CSS today!), but reading projects like this is super motivating. It shows where I can get to. Out of curiosity, how long did it take you to feel comfortable building something so complex?

Collapse
 
ujja profile image
ujja

Thank you! And congratulations on publishing your first article πŸŽ‰

Honestly, this didn't happen overnight. I've been building software professionally for several years, and even then, this project started as a hackathon prototype held together with a lot of shortcuts πŸ˜„

The best advice I can give is to keep building things that are slightly beyond your comfort zone. Small projects have a way of turning into bigger ones over time.

Collapse
 
xulingfeng profile image
xulingfeng

Offline-first Hermes for bushfire response β€” that's a genuinely impactful use case. The "connectivity comes and goes" constraint is exactly the edge case most agent frameworks ignore. We run Hermes with sqlitemem as the persistence layer, and that local-first design has been our savior in network-partitioned scenarios too.

Curious: how are you handling data sync when connectivity comes back? Conflict resolution across offline agents is something we've been wrestling with.

Collapse
 
ujja profile image
ujja

Great question, and honestly, the part I'm still wrestling with too. Right now, Haven is read-heavy offline β€” Workbox NetworkFirst caches alerts, safe spaces, and recommendations so the app stays usable when the network drops. That part works.

The write path (user location updates, feed posts, status changes while offline) is designed as an IndexedDB queue that drains on reconnect β€” but conflict resolution is where it gets genuinely hard. For Haven's domain, I'm leaning toward timestamp-based last-write-wins for most state (location, user status), since the data is either idempotent or the latest value is always correct in an emergency. The trickier case is community feed posts and volunteer availability β€” where you might have two users updating the same resource offline simultaneously.

For that, I'm thinking of semantic merge rules per entity type rather than a generic CRDT: feed posts are append-only, so no conflicts; capacity counts at evacuation centres are reconciled by taking the minimum (safer to under-report capacity in a crisis). Haven't shipped it yet, though β€” curious what approach you landed on?

Collapse
 
apimartai profile image
APImart

🩷