Joruri Shohay (জরুরি সহায় — "Emergency Helper") .

Thumbnail
System_Architecture
BanglaUI
Joruri_Sohay_Agent

Inspiration

Earlier this year, earthquakes in Venezuela and Colombia killed thousands of people. Watching that unfold, I kept thinking about what happens in the hours right after a disaster — when buildings are down, help is stretched thin, and people still need to know where to go and who to call.

Bangladesh sits in a similarly high-risk, densely populated zone. If something on that scale ever hit here, that same confusion in the first chaotic hour could cost just as many lives. But the problem isn't only large-scale disasters — it's every single day, in ordinary medical emergencies, where people lose critical time simply not knowing which number to call, what to do while help arrives, or which hospital they can actually reach and afford.

That gap is what Joruri Shohay (জরুরি সহায় — "Emergency Helper") is built to close.

What it does

Joruri Shohay is a bilingual (Bangla/English) AI agent that gives people fast, honest guidance in a medical emergency:

Gives the real emergency number first — 999 for general emergencies, 1090 for disasters, 109 for women & child safety — before anything else, in serious situations.
Walks users through standard first-aid steps for bleeding, burns, choking, fractures, unconsciousness, and earthquakes, while help is on the way.
Finds the nearest suitable hospital ranked by both emergency type and the user's budget tier (free/low/mid/high), using real geocoding for named areas like "Dhanmondi."
Finds nearby blood banks when blood is urgently needed — while always telling the user to call and confirm current stock, since we don't track live inventory.
Logs user corrections (a wrong number, an updated cost, a suggested hospital) for a human to review, rather than trusting unverified claims automatically.
Works entirely in Bangla or English, matching whichever language the user types in.

How we built it

The agent is built on the Strands Agents SDK and runs on Claude, via Amazon Bedrock.

It uses a genuine multi-agent architecture. A primary orchestrator running Claude Sonnet 4.6 handles the conversation, triage, and safety rules, with direct access to six tools. All hospital lookup, however, is delegated to a separate Hospital Finder specialist agent running Claude Haiku 4.5, which has its own system prompt and its own tool set (geocode_location and find_hospitals). The primary agent has no direct access to hospital search — every hospital lookup must go through delegation. That separation keeps each agent's context narrow and lets the specialist run on a faster, cheaper model since its job is narrow tool-call sequencing.

Tools available to the agents:

geocode_location — converts a named area into real coordinates via OpenStreetMap's Nominatim API
find_hospitals — ranks nearby hospitals by distance, emergency type, and budget tier
find_blood_banks — ranks nearby blood banks by distance
get_emergency_number — returns the correct real number for the situation
first_aid_steps — standard first-aid guidance, bilingual
submit_user_feedback — logs corrections for human review
draft_emergency_message — drafts a message the user can copy and send to family

Safety is enforced in two layers. Two deterministic hooks run in code — a rate limiter that caps repeated tool calls, and a location workflow that ensures blood-bank lookup has real coordinates in the message. Two LLM-based second opinions review every reply before it ships — a tone guardrail that checks the reply against the safety rules, and a scope guardrail that keeps the agent inside emergency help only.

The frontend is a lightweight vanilla-JS chat interface served through a Flask backend, with dark/light theming, tap-to-call phone numbers, one-tap example prompts, per-chat session memory, and a "share my location" button that lets the agent skip geocoding entirely when real device coordinates are available.

Challenges we ran into

Two of our biggest challenges had nothing to do with the AI itself.

The first was data. There's no proper, reliable API for Bangladeshi medical services — no unified source for hospital locations, specialties, budget tiers, or blood bank details. We ended up hand-curating that data ourselves, cross-checking names and specialties manually. That gap is actually the direct reason the agent is instructed to only ever state a phone number or hospital that came straight from a verified tool result — after building the dataset by hand, we knew exactly how easy it would be for an LLM to confidently "fill in" a plausible but nonexistent hospital for an area we hadn't covered yet.

The second was a strange, hard-to-reproduce bug: at one point Strands suddenly couldn't recognize or invoke the Claude Sonnet 4.6 model ID at all — every call failed, with no code changes on our end. Oddly, the moment we opened the AWS Bedrock Playground directly, typed a simple "hi," and got a response there, Strands started working again on the very next attempt. We genuinely don't know the exact mechanism — our best guess is some kind of model-access or provisioning step on Bedrock's side that only fully activates after a first direct invocation — but we're noting it here in case another team runs into the same thing.

Accomplishments that we're proud of

A genuinely bilingual experience, not just translated UI strings — the agent detects and responds in whichever language the user writes in.
A real multi-agent architecture: the primary agent delegates hospital lookup to a separate specialist agent rather than calling the tools itself.
Hard safety guardrails that hold up under testing — two deterministic hooks that run in code, and two LLM-based second opinions that review every reply before it ships.
A working end-to-end pipeline from a typed area name to real geocoded coordinates to a ranked, budget-matched hospital list, built entirely on hand-verified data despite the lack of a proper source API.

What we learned

We learned a lot about tool-orchestration design with Strands Agents — specifically, how much of an agent's real-world safety comes not from the model itself but from how narrowly its tools are scoped and how explicitly the system prompt forbids it from filling gaps with its own training knowledge. In a domain like emergency response, "I don't know, here's the real number to call" is a better answer than a plausible-sounding guess.

We also learned that splitting work across two agents with different scopes produces a cleaner, faster system than one agent trying to do everything. The primary agent stays focused on the conversation and safety rules; the specialist stays focused on hospital lookup. Each one has less to get wrong.

What's next for Joruri Shohay

Expand hospital/blood bank coverage beyond Dhaka to Chittagong, Sylhet, Khulna, and other divisions
A WhatsApp interface — realistically, nobody in an actual emergency is opening a website
Real routing-distance data instead of straight-line distance
Offline/SMS fallback for low-connectivity disaster scenarios
Live blood stock integration, if a real data source ever becomes available