Over the past 10 days, I took part in 10 Days of Voice Agents -VoiceForBharat Edition and built ResQ Voice, a voice assistant focused on disaster response.

The idea was simple: during an emergency, people shouldn't have to navigate complicated apps or type long messages. A voice interface can make it easier to ask for information, describe a situation, and get the right kind of help.

The Problem

During disasters, information can be difficult to access quickly.

Someone might need to:

Find an emergency shelter
Understand basic safety steps
Ask about shelter availability
Get help when they are trapped or injured
Be connected to a human when the AI cannot safely handle the situation

I wanted ResQ Voice to handle the first layer of these interactions while being very clear about its limitations.

Meet ResQ Voice
ResQ Voice is a Disaster Response Voice Assistant built around LiveKit.

Its main responsibilities are to:

1) Understand what the person needs.
2) Provide safe disaster-preparedness guidance.
3) Look up shelter information from available data.
4) Escalate situations that require human help.
5) Hand specialised requests to a specialist agent.

The voice pipeline uses Deepgram for speech-to-text, Gemini as the LLM, and Murf Falcon for text-to-speech, with LiveKit handling the real-time communication layer.

How the System Works

The architecture for the system is as follows:

The agent was designed for browser-based conversations and was also extended toward outbound calling during the challenge.

What I Built

I. Disaster-response personality and guardrails

I gave the agent a specific role instead of making it a general-purpose chatbot.

It is instructed not to:

• Give medical diagnoses
• Predict disasters
• Invent official alerts
• Claim an area is safe
• Pretend it has access to live emergency systems

It also adapts to the user's language, including English, Hindi and Hinglish.

This was important because in an emergency, a confident but incorrect answer can be worse than admitting that the system doesn't know something.

II. Shelter lookup

I added a shelter lookup tool that searches a local demonstration dataset. The agent only calls it after the user provides a location such as a town, district, locality or landmark.

It can return information such as:

• Shelter name
• Available capacity
• Last updated information

The agent is explicitly instructed not to invent a shelter when the data doesn't contain one.

III. Human escalation

One of the most important features I added was a human-help escalation system.

For example, if someone says:
"I'm trapped and injured."

The agent shouldn't continue trying to solve the entire situation itself.
Instead, it can collect a short summary containing:

• Who needs help
• What happened
• What the agent already checked
• Urgency
• Language
• Preferred follow-up method

Before creating the request, the agent asks the caller for permission to share those details.

The request receives a reference ID and is stored in a local human-help queue.

IV. Outbound calling

I also explored outbound calling using Twilio.

The idea for the Disaster Response track was an outbound welfare-check or district-alert scenario.
This introduced a different challenge compared with browser-based conversations because an outbound caller has to immediately explain:

• Who is calling?
• Why they are calling?
• How the person can stop the interaction?

V. Call analytics

I added call metrics using SQLite.
The system records whether a call was:

• Successful
• Failed

I then built a small Flask dashboard showing:

• Total Calls
• Successful Calls
• Failed Calls

The dashboard uses the database rather than hardcoded numbers.

VI. Specialist handoff

Another interesting part was separating responsibilities between agents.

The main ResQ agent doesn't need to know everything.

I created a specialist agent for shelter information and added a handoff mechanism.

The flow becomes:

User
↓
ResQ Voice
↓
"Let me connect you to our shelter specialist."
↓
Shelter Specialist
↓
Continues the conversation

The important part is that the user doesn't have to repeat their entire problem.

Some of the Challenges I Faced

Not everything worked perfectly on the first try.
One of the biggest problems I faced was my development environment. Some of the LiveKit dependencies, particularly around uv and platform compatibility on my Mac, made it difficult to run the complete backend locally.

I had to separate what I could actually run and test from what I could verify through the code and configuration.

I also ran into smaller issues while building the dashboard, including Python environments, Flask dependencies, imports and port conflicts. For example, installing Flask with uv didn't mean that running python3 directly would automatically use that environment. I had to run the application through: uv run python dashboard.py.
That was a small problem, but it was a good reminder that the environment is part of the application.

Building the Agent

The basic LiveKit agent session connects the different components:

Tools can then be exposed to the agent using LiveKit's function-tool mechanism.
For example, the shelter functionality is exposed as a tool:

This allows the LLM to decide when the tool is actually relevant instead of running it for every conversation.

Keeping API Keys Safe

API keys are stored in environment variables rather than directly in the source code.
For example: .env.local contains the required credentials. The file should never be committed to GitHub! A .gitignore entry should include .env.local
Anyone building a similar project should create their own API keys and environment file.

Testing the Agent

I tested the conversation paths that were available in my development environment and verified the remaining flows through the implementation and configuration.

A normal conversation should stay with the main agent.
For example:
"What should I keep in an emergency kit?"

But a specialist request should trigger the handoff:
"I need information about an emergency shelter near my area."

Similarly, a serious situation such as:
"I'm trapped and injured."
should trigger the human-help flow rather than normal advice.

This distinction was important because while the agent should not escalate everything, it also shouldn't try to handle situations beyond its role.

What I Learned

The biggest lesson from the challenge was that building a voice agent is much more than connecting an LLM to a microphone.
You also need to think about:

• What the agent is allowed to do
• What it should refuse
• When it should use tools
• When it should ask a human
• How information is stored
• How conversations are measured
• How multiple agents can work together
• What happens when the infrastructure doesn't cooperate

The more features I added, the more important the boundaries became!

What's Next?

If I continue developing ResQ Voice, I'd like to work on:

1) Live verified disaster information
2) Better location-aware services
3) More Indian languages
4) More robust telephony integration
5) A production-ready human support backend
6) Better monitoring and analytics
7) More extensive testing under real emergency scenarios
The current project is a prototype, not a replacement for emergency services. In a real emergency, users should still follow instructions from official local authorities and emergency responders!

My Final Thoughts

The 10 Days of Voice Agents - VoiceForBharat Edition gave me a chance to build something much more complete than a simple chatbot.

ResQ Voice started as a voice agent. By the end, it had a personality, guardrails, tools, memory, outbound-call capabilities, human escalation, analytics, and specialist handoffs. The most useful thing I learned wasn't how to make an AI talk. It was how to design an AI that knows what it can do, knows what it cannot do, and knows when to bring a human into the loop.
I'm grateful to have built this as part of 10 Days of Voice Agents and to experiment with Murf Falcon, LiveKit and the rest of the voice stack.

Links

GitHub
https://github.com/Kopal-404/murf-livekit-starter

Demo / videos

ResQ Voice AI Assistant for Disaster Response Guidance | Kopal Kumar posted on the topic | LinkedIn

I built ResQ Voice, an AI voice assistant for Disaster Response that gives calm, step-by-step guidance during disasters - floods, earthquakes, cyclones, fires, landslides, and heatwaves. In emergencies, people often lack access to clear, immediate guidance, and panic can compound the situation. ResQ Voice addresses this by delivering real-time, spoken instructions the moment they're needed, while consistently directing users to official emergency services for anything life-threatening. The voice pipeline runs on Murf Falcon - the fastest TTS API available for natural, low-latency responses, paired with LiveKit for real-time infrastructure, Deepgram for speech-to-text, and Gemini as the underlying language model. Excited to be part of 10 Days of Voice Agents - VoiceForBharat Edition! Murf AI #VoiceForBharat #AIVoiceAgents #BuildInPublic #10DaysOfVoiceAgents #MurfAI #MurfFalcon #LiveKit #Deepgram #Python

linkedin.com

Personalizing ResQ Voice for Emergency Interactions | Kopal Kumar posted on the topic | LinkedIn

Today, I focused on the frontend of ResQ Voice, my disaster-response voice agent. I personalized the interface to make emergency interactions clearer and more intuitive, with dedicated states for: - Ready - Connecting - Listening - Speaking - Call ended I also added clear speaker-status feedback and tested the complete voice interaction flow, including restarting a conversation. ResQ Voice is designed to handle emergency scenarios while following strict safety guardrails and supporting multilingual, code-mixed conversations. Built with LiveKit, Gemini, Deepgram, and Murf Falcon, the fastest TTS API. Building one step at a time as part of 10 Days of Voice Agents. Murf AI #VoiceForBharat #VoiceAI #AI #GenerativeAI #LiveKit #MurfAI #MultilingualAI #DisasterResponse #PublicSafety #BuildInPublic

linkedin.com

Refined ResQ Voice AI for Multilingual Disaster Response | Kopal Kumar posted on the topic | LinkedIn

Refined ResQ Voice, my AI-powered Disaster Response Voice Assistant, to better understand multilingual and code-mixed conversations and respond in the user's preferred language. This iteration focused on: - Defining clear call objectives for emergency assistance. - Implementing safety guardrails and escalation protocols. - Improving multilingual support, including Hindi, English, and Hinglish. - Enhancing the first-response experience with concise, user-centric interactions. ResQ Voice is being built using Murf Falcon, the fastest TTS API, together with LiveKit to deliver responsive, real-time voice interactions. Looking forward to improving its capabilities over the coming days through 10 Days Of Voice Agents! Murf AI #AI #GenerativeAI #VoiceAI #MultilingualAI #Python #LiveKit #MurfAI #DisasterResponse #PublicSafety #VoiceForBharat #BuildInPublic

linkedin.com

LinkedIn
www.linkedin.com/in/kopal-kumar

Special thanks to Murf AI for organising the challenge and for making the voice experience possible with Murf Falcon.

VoiceForBharat #VoiceAI #AI #LiveKit

Kopal Kumar