Building ASHA: A Real-Time Multi-Agent Voice AI Health Guide for Bharat

Muthukkumaran B — Sat, 15 Aug 2026 13:33:42 +0000

Building ASHA: A Real-Time Multi-Agent Voice AI Health Guide for Bharat

Day 10 — 10 Days of AI Voice Agents #VoiceForBharat

Over the past 10 days, I participated in the 10 Days of AI Voice Agents — #VoiceForBharat Edition challenge.

For this challenge, I built ASHA, a real-time AI voice assistant designed around a simple idea:

What if accessing basic health guidance could be as simple as having a conversation?

The project started from the Murf LiveKit Starter, which provided the initial foundation for building a real-time voice agent using LiveKit, Deepgram, an LLM, and Murf Falcon TTS.

Rather than building the entire voice infrastructure from scratch, I used that foundation as a starting point and adapted it for the #VoiceForBharat use case.

My work focused on configuring and extending the voice pipeline, shaping ASHA's healthcare-oriented behavior, adding application-level capabilities, experimenting with persistent context and specialist agent workflows, and working through the practical challenges of building a real-time voice application.

This post is my Day 10 technical retrospective covering the architecture, implementation, safety considerations, technical roadblocks, and lessons learned.

1. The Problem

Access to information is not always the same as access to usable information.

Many digital services assume that users are comfortable with:

Reading long instructions
Typing queries
Navigating multiple screens
Understanding technical terminology
Using conventional application interfaces

For users with different levels of digital literacy, a conversational voice interface can provide a much more natural interaction model.

This becomes particularly interesting in healthcare.

A user may not know the technical name for a symptom. They may simply describe what they are experiencing in everyday language.

For example:

"I've been feeling dizzy since morning."

Instead of forcing that user through a complex interface, a voice assistant can allow them to simply explain the situation naturally.

That led to the concept of ASHA.

The name is inspired by the idea of an accessible community health guide — not an automated replacement for a healthcare professional.

2. Why Voice?

Text-based AI is powerful, but voice introduces a completely different interaction model.

A typical chatbot looks like:

User types
    ↓
Server processes
    ↓
AI responds
    ↓
User reads

A real-time voice agent looks more like:

User speaks
    ↓
Audio streaming
    ↓
Speech-to-Text
    ↓
LLM reasoning
    ↓
Text-to-Speech
    ↓
Audio streaming
    ↓
User hears response

The second model introduces several additional engineering challenges.

Now the application has to deal with:

Audio streaming
Microphone permissions
WebRTC
Speech recognition
LLM latency
TTS latency
Connection state
Real-time synchronization
Interruptions
Streaming responses

That complexity is exactly what made this challenge interesting to me.

3. Starting Point: Murf LiveKit Starter

Before discussing ASHA's architecture, it is important to explain where the project started.

The project is based on the Murf LiveKit Starter, which provides a foundation for building a real-time voice agent with LiveKit and Murf.

The starter provided several important components:

LiveKit-based real-time communication
Python voice-agent structure
Deepgram speech recognition
LLM integration
Murf Falcon text-to-speech
Next.js frontend structure
Local development workflow

This meant I didn't have to reinvent the underlying real-time voice infrastructure.

Instead, I could concentrate on the application layer and the #VoiceForBharat problem.

The development approach became:

Murf LiveKit Starter
        ↓
Understand the architecture
        ↓
Configure the voice pipeline
        ↓
Adapt the agent for ASHA
        ↓
Add healthcare-oriented capabilities
        ↓
Implement memory and tool workflows
        ↓
Add specialist-agent architecture
        ↓
Test and debug
        ↓
ASHA

This was also an important lesson for me as a developer:

Building on an existing foundation is not the same as blindly using it. You still need to understand the architecture before you can meaningfully extend it.

4. System Architecture

The core ASHA architecture uses a full-duplex real-time voice pipeline.

                    ┌──────────────────┐
                    │     User / Mic   │
                    └────────┬─────────┘
                             │
                             │ WebRTC Audio
                             ▼
                    ┌──────────────────┐
                    │     LiveKit      │
                    │  Voice Transport │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  Deepgram Nova-3 │
                    │       STT        │
                    └────────┬─────────┘
                             │
                         Transcript
                             │
                             ▼
                    ┌──────────────────┐
                    │  Groq + LLaMA    │
                    │     3.3 70B      │
                    └────────┬─────────┘
                             │
                  ┌──────────┼──────────┐
                  │          │          │
                  ▼          ▼          ▼
                PHC       Patient    Appointment
               Lookup     Memory     Specialist
                  │          │          │
                  └──────────┼──────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │ Safety / Triage  │
                    │    Workflows     │
                    └────────┬─────────┘
                             │
                       ┌─────┴─────┐
                       │           │
                       ▼           ▼
                    Normal      Emergency
                   Response     Escalation
                                   │
                                   ▼
                              Webhook
                                   │
                                   ▼
                           Human Workflow

                             │
                             ▼
                    ┌──────────────────┐
                    │   Murf Falcon    │
                    │       TTS        │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │  User / Speaker  │
                    └──────────────────┘

                             │
                             ▼
                    ┌──────────────────┐
                    │ SQLite Analytics │
                    └──────────────────┘

The major components are:

Layer	Technology
Real-time communication	LiveKit
Voice transport	WebRTC
Speech-to-Text	Deepgram Nova-3
LLM	Groq + LLaMA 3.3 70B
Text-to-Speech	Murf Falcon
Voice	Anisha
Backend	Python
Frontend	Next.js / React
Persistence	SQLite
Analytics	FastAPI + SQLite
External workflows	Webhooks
Agent architecture	Multi-agent handoffs

5. LiveKit: The Real-Time Foundation

One of the most important parts of ASHA is LiveKit.

A voice assistant cannot behave like a normal request-response web application.

With a traditional API:

Request
   ↓
Wait
   ↓
Response

Voice requires something closer to:

Audio Stream
   ⇅
Real-Time Communication
   ⇅
Audio Stream

LiveKit provides the real-time communication infrastructure required for this type of application.

The basic architecture becomes:

Browser
   │
   ▼
LiveKit
   │
   ▼
Voice Agent

This allows the application to focus on the actual agent logic instead of implementing a custom audio transport layer.

6. Speech-to-Text with Deepgram

The first AI stage is speech recognition.

When the user speaks, the audio needs to be converted into text before the language model can reason about it.

ASHA uses Deepgram Nova-3 for this stage.

The conceptual flow is:

Microphone
    ↓
Audio Stream
    ↓
Deepgram Nova-3
    ↓
Transcript
    ↓
LLM

Voice input is fundamentally different from typed input.

Users may:

Pause
Repeat themselves
Correct themselves
Mix languages
Use informal terminology
Speak with different accents
Use regional expressions

A useful voice agent therefore needs to be designed around imperfect conversational input.

7. LLM Reasoning with Groq

Once the user's speech is transcribed, the request is passed to the language model.

ASHA uses LLaMA 3.3 70B through Groq for conversational reasoning.

The LLM is responsible for:

Understanding user intent
Maintaining conversational context
Deciding when clarification is required
Determining whether a tool should be called
Routing specialized requests
Generating the response

Conceptually:

User Request
     ↓
Intent Understanding
     ↓
Context Analysis
     ↓
Tool / Agent Decision
     ↓
Response Generation

However, the LLM is not treated as an unquestionable medical authority.

This distinction is particularly important in healthcare.

8. Murf Falcon: Giving ASHA a Voice

The response generated by the LLM needs to be converted back into natural speech.

That's where Murf Falcon TTS comes in.

The pipeline becomes:

User Speech
     ↓
Deepgram STT
     ↓
LLaMA 3.3 70B
     ↓
Response Text
     ↓
Murf Falcon
     ↓
Spoken Response

ASHA uses the Anisha voice for its Indian English conversational experience.

For a #VoiceForBharat project, this is particularly important.

The voice isn't simply an output format.

It is part of the user experience.

A conversational assistant should feel approachable rather than robotic.

9. Primary Health Centre Information

A healthcare voice assistant becomes significantly more useful when it can do more than generate general responses.

ASHA incorporates a PHC lookup capability designed to provide structured healthcare facility information.

Depending on the available data source, the system can retrieve information such as:

Primary Health Centre details
Operating information
Facility addresses
Available services
Contact information
Location-related information

The important architectural principle is:

The LLM should reason about the request, but factual healthcare facility information should come from a structured source.

Instead of asking the LLM to invent a hospital address or telephone number, the agent can invoke a dedicated lookup tool.

The flow becomes:

User:
"Where is the nearest PHC?"

        ↓

Speech-to-Text

        ↓

ASHA Agent

        ↓

PHC Lookup Tool

        ↓

Structured Healthcare Data

        ↓

LLM formats the result

        ↓

Murf Falcon TTS

        ↓

User hears the response

This separation between reasoning and factual retrieval is especially important in healthcare applications.

10. Patient Context and Memory

Another capability explored in ASHA is persistent conversational context.

A voice assistant becomes more useful when a returning user doesn't have to repeat basic information every time.

The system can maintain application-level context such as:

Age group
Language preference
Previous interaction context
Previous triage outcome
Conversation state

The architecture is:

First Interaction
      ↓
User provides permitted information
      ↓
Consent / Profile Update
      ↓
Profile Storage
      ↓
Future Interaction
      ↓
ASHA retrieves permitted context
      ↓
More contextual conversation

However, memory should not mean storing everything.

A production healthcare system would require:

Explicit consent
Data minimization
Access control
Encryption
Retention policies
Deletion mechanisms
Appropriate compliance review

The principle is simple:

Store only what is necessary, and only when the user has appropriate control over that data.

11. Safety Guardrails

Healthcare is a domain where an AI system needs stronger boundaries than a general-purpose chatbot.

ASHA is therefore designed around several safety principles.

The assistant should not:

Claim to provide a definitive diagnosis
Pretend to have physically examined a patient
Prescribe medication independently
Provide unsafe medication dosages
Give false certainty about serious symptoms

Instead, it should:

Ask clarification questions
Provide general health information
Recognize potentially serious situations
Encourage appropriate professional care
Escalate when configured safety conditions are met

For example, if a user says:

"I have severe chest pain and I'm struggling to breathe."

The correct response is not to confidently diagnose the condition.

The system should recognize the possibility of an emergency and guide the user toward appropriate urgent medical assistance.

This led to one of my biggest design principles:

The goal isn't to make the AI sound like a doctor. The goal is to make the AI useful without pretending to be one.

12. Emergency Detection and Human Escalation

Healthcare conversations introduce situations where the AI should not attempt to handle everything autonomously.

ASHA therefore includes a human-in-the-loop escalation concept.

Potential red-flag symptoms can trigger an escalation workflow.

For example:

User describes symptoms
          ↓
ASHA analyses conversation
          ↓
Potential red flag detected
          ↓
Explain urgency
          ↓
Obtain appropriate confirmation / consent
          ↓
Create escalation event
          ↓
Webhook
          ↓
Human healthcare workflow

The webhook architecture makes this extensible.

An escalation event could eventually be connected to:

Health officer notification
Hospital workflow
Emergency operations system
SMS/notification service
Internal healthcare dashboard

The key principle is:

AI should assist emergency workflows, not replace emergency professionals.

13. SQLite-Based Patient and Analytics Layer

For the prototype, SQLite provides a lightweight persistence layer.

It can support application data such as:

User profiles
Conversation state
Workflow state
Application events
Analytics information

SQLite is useful during development because it requires minimal infrastructure while still providing structured storage.

The analytics architecture can follow an event-oriented approach:

Call Started
     ↓
Conversation Started
     ↓
User Request
     ↓
Tool Invoked
     ↓
Workflow Completed
     ↓
Call Ended

From these events, the application can track metrics such as:

Total calls
Completed interactions
Tool usage
Escalation events
Early disconnects
Workflow outcomes

The important principle is to avoid unnecessarily exposing raw personal information in analytics.

A production implementation would require stronger:

Authentication
Authorization
Encryption
Data retention
Audit logging
Privacy controls

14. Real-Time Analytics Dashboard

To make the system easier to monitor, ASHA includes a FastAPI-based analytics dashboard backed by SQLite.

The dashboard provides an operational view of the voice-agent system.

Rather than focusing on the contents of private conversations, the analytics layer can focus on structured events and system-level metrics.

For example:

┌───────────────────────────────┐
│       ASHA Dashboard           │
├───────────────────────────────┤
│ Total Calls                   │
│ Completed Conversations       │
│ Tool Invocations              │
│ Escalation Events             │
│ Early Disconnects             │
│ Workflow Success Rate         │
└───────────────────────────────┘

This separation is useful because monitoring the system should not require exposing every detail of a user's conversation.

15. Multi-Agent Architecture

As the application grows, putting every capability into one voice agent becomes difficult to maintain.

ASHA therefore explores a multi-agent architecture.

The main ASHA agent acts as the conversational entry point.

When the user moves into a specialized workflow, the conversation can be handed to a specialist.

The architecture looks like:

                    ┌─────────────────┐
                    │   ASHA Agent    │
                    │   Main Agent    │
                    └────────┬────────┘
                             │
                       Intent Detection
                             │
              ┌──────────────┴──────────────┐
              │                             │
              ▼                             ▼
       General Guidance             Appointment Request
                                            │
                                            ▼
                              ┌─────────────────────────┐
                              │ Appointment Specialist  │
                              └────────────┬────────────┘
                                           │
                                           ▼
                                  Booking Workflow

The appointment specialist can focus on:

Understanding appointment intent
Collecting required booking information
Validating the workflow
Communicating with the appropriate booking service
Returning the result to the main conversation

This separation provides several advantages:

Smaller prompts
Clearer responsibilities
Easier testing
Easier debugging
Better maintainability
Easier future expansion

The same architecture could later support specialists for:

Healthcare facilities
Government health programs
Follow-up workflows
Administrative services
Appointment scheduling

16. Why Multi-Agent Instead of One Large Agent?

At first glance, it may seem easier to put everything into one agent.

But that creates a growing problem.

Imagine one agent responsible for:

Health Guidance
+ PHC Search
+ Appointments
+ Patient Memory
+ Emergency Escalation
+ Government Programs
+ Analytics
+ Administrative Workflows

The prompt becomes larger.

The tools become harder to reason about.

Testing becomes more complicated.

A multi-agent architecture instead follows separation of concerns:

ASHA
 │
 ├── General Health Agent
 │
 ├── PHC Specialist
 │
 ├── Appointment Specialist
 │
 └── Escalation Workflow

Each component can have a narrower responsibility.

This makes the architecture easier to extend.

17. Technical Roadblock: Empty Tool Schemas

One of the most interesting problems I encountered involved LLM function calling.

I initially created a zero-parameter handoff function:

transfer_to_appointment_specialist()

From a Python perspective, this is completely valid.

However, the inference endpoint rejected the generated tool schema.

The error was related to a schema where required existed without the expected properties definition.

The problem wasn't the handoff logic itself.

It was the generated JSON schema.

The solution was to provide an explicit parameter:

booking_intent: str = "schedule_appointment"

This produced a valid tool schema while still allowing the same handoff behavior.

The lesson:

LLM tools are API contracts, not merely Python functions.

When integrating function calling across different providers, always inspect the JSON schema being sent to the model.

18. Technical Roadblock: `0.0.0.0` vs `localhost`

Another problem I encountered was related to local networking.

The backend server can bind to:

0.0.0.0

For example:

uvicorn app:app --host 0.0.0.0 --port 8000

But opening:

http://0.0.0.0:8000

in a browser can result in an invalid-address error.

The distinction is:

0.0.0.0

is a server bind address.

For local browser access, use:

http://localhost:8000

or:

http://127.0.0.1:8000

Understanding the difference between a bind address and a client-accessible address prevented me from debugging the wrong component.

19. Running ASHA Locally

Prerequisites

You need:

Python 3.10+
Node.js 18+
uv
pnpm
A LiveKit project
Murf API credentials
Deepgram API credentials
LLM API credentials

Step 1 — Clone the Repository

git clone https://github.com/muthukkumaranb/murf-voice-ai.git
cd murf-voice-ai

Step 2 — Configure Environment Variables

Create the appropriate local environment configuration:

LIVEKIT_URL=wss://<your-livekit-project>.livekit.cloud
LIVEKIT_API_KEY=<your-livekit-api-key>
LIVEKIT_API_SECRET=<your-livekit-api-secret>

MURF_API_KEY=<your-murf-api-key>
DEEPGRAM_API_KEY=<your-deepgram-api-key>

GROQ_API_KEY=<your-groq-api-key>

If your implementation uses additional services, configure their credentials as required.

Never commit API keys to GitHub.

Step 3 — Install Backend Dependencies

cd backend
uv sync

If required by the project:

uv run python src/agent.py download-files

Step 4 — Install Frontend Dependencies

From the repository root:

cd frontend
pnpm install

Step 5 — Start the Agent

From the backend directory:

uv run python src/agent.py dev

Step 6 — Start the Dashboard

If using the analytics dashboard:

uv run python src/dashboard.py

The dashboard can be accessed locally through:

http://localhost:8000

Step 7 — Start the Frontend

From the frontend directory:

pnpm dev

Then open:

http://localhost:3000

Allow microphone access and start the voice session.

20. Deployment Architecture

The application can be structured with separate frontend and backend deployments.

A potential architecture is:

                    ┌──────────────┐
                    │   Vercel     │
                    │   Frontend   │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │   LiveKit    │
                    │    Cloud     │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │   Railway    │
                    │    Agent     │
                    └──────────────┘

This separation allows the frontend and long-running voice agent to scale independently.

I currently don't have a public demo link for ASHA.

The GitHub repository is therefore the primary project reference.

21. What I Learned During the 10 Days

The biggest lesson from these 10 days is that building a voice agent is much more than connecting an LLM to a microphone.

A working voice experience requires multiple systems to cooperate:

Audio
  ↓
WebRTC
  ↓
LiveKit
  ↓
Speech Recognition
  ↓
LLM Reasoning
  ↓
Tool Calling
  ↓
Agent Routing
  ↓
Text-to-Speech
  ↓
Audio Playback

A failure anywhere in that chain can affect the entire user experience.

Lesson 1 — Real-time systems are different

Voice applications are much less tolerant of latency than text interfaces.

Even small delays can make a conversation feel unnatural.

Lesson 2 — Streaming matters

The goal isn't simply to produce an answer.

The goal is to maintain the feeling of a continuous conversation.

Lesson 3 — Tool schemas matter

A Python function can be perfectly valid while its generated JSON schema is invalid for an LLM provider.

Lesson 4 — Provider integration is rarely plug-and-play

Every provider has its own:

API contracts
Authentication
Schema requirements
SDK behavior
Error handling
Streaming implementation

Lesson 5 — Voice UX is different

A response that looks good as text may sound terrible when spoken.

Voice responses should generally be:

Concise
Conversational
Easy to understand
Naturally paced

Lesson 6 — Healthcare requires restraint

The most impressive AI response isn't necessarily the safest response.

For healthcare-oriented applications, knowing when not to make a claim is a critical part of responsible system design.

Lesson 7 — Building on existing infrastructure is a skill

Starting from an existing open-source foundation does not eliminate engineering work.

It shifts the problem.

Instead of building the entire infrastructure from scratch, you have to:

Understand the existing architecture
Identify extension points
Modify components safely
Integrate new workflows
Debug interactions between systems
Keep the resulting application maintainable

That was one of the most valuable lessons from this challenge.

22. What's Next for ASHA?

The current implementation is a foundation rather than the final product.

There are several areas I want to explore next.

Regional Indian Languages

The long-term vision includes stronger support for:

Tamil
Hindi
Telugu
Malayalam
Kannada
Hinglish
Tanglish

The goal is not simply translation.

The system should understand conversational expressions and code-mixed speech naturally.

Telephony

A future version could connect ASHA to telephony infrastructure.

That would allow users to interact with the system without necessarily requiring a web browser.

Potential technologies include SIP-based infrastructure and telephony providers.

Verified Healthcare Information

The PHC and healthcare-information layer could be expanded using authoritative and regularly maintained data sources.

The principle would remain:

Use trusted data sources for facts and use the LLM for reasoning and conversation.

Stronger Human-in-the-Loop Workflows

For high-risk situations, ASHA should become better at routing users toward qualified professionals rather than attempting to handle everything autonomously.

Better Privacy

A production healthcare platform would require considerably stronger security architecture.

Future work would include:

Strong authentication
Fine-grained authorization
Encryption
Consent management
Data minimization
Retention policies
Audit logging
Secure deletion

Production-Ready Infrastructure

The prototype currently relies on lightweight infrastructure such as SQLite.

A production system would likely require:

Scalable databases
Distributed services
Monitoring
Rate limiting
Fault tolerance
Secure secret management
Automated deployment
Observability

23. Final Thoughts

When I started this challenge, the idea seemed simple:

Build an AI that people can talk to.

After 10 days, I realized that the sentence hides an entire engineering stack.

You need:

WebRTC + real-time communication + STT + LLM + TTS + frontend + backend + tool calling + state management + networking + error handling + user experience.

And when the application is aimed at healthcare, there is another layer:

responsibility.

ASHA is not a replacement for doctors or healthcare professionals.

It is a prototype exploring how conversational voice interfaces could make certain kinds of health information and guidance easier to access.

The most valuable part of this challenge wasn't simply getting the agent to speak.

It was understanding everything that happens behind the conversation.

From debugging tool schemas to working with real-time communication, from configuring multiple AI providers to designing specialist workflows, every stage introduced a different engineering problem.

The Murf LiveKit Starter gave me the foundation to explore these technologies without having to build the entire voice infrastructure from zero.

The challenge was then to understand that foundation, adapt it, extend it, and turn it toward a problem that matters.

That is what made these 10 days worth doing.

Ten days.
One voice agent.
Multiple systems.
A lot of debugging.
And plenty of lessons learned. 🚀

24. Project Repository

The complete project is available on GitHub:

👉 ASHA — Murf Voice AI

The repository is based on the Murf LiveKit Starter and contains the project source code and setup instructions.

There is currently no public demo link, so the GitHub repository is the primary way to explore the project.

Technology Stack

LiveKit — Real-time communication
WebRTC — Real-time audio transport
Deepgram Nova-3 — Speech-to-Text
Groq — Low-latency inference
LLaMA 3.3 70B — Conversational reasoning
Murf Falcon — Text-to-Speech
Anisha — Indian English voice
Python — Voice agent backend
Next.js / React — Frontend
SQLite — Lightweight persistence
FastAPI — Analytics/dashboard layer
Webhooks — External workflow notifications
uv — Python package management
pnpm — Frontend package management

Acknowledgements

A huge thank you to the Murf AI team for organizing the 10 Days of AI Voice Agents — #VoiceForBharat Edition challenge.

The challenge gave me an opportunity to move beyond simply experimenting with AI APIs and actually think about:

Real-time architecture
Voice UX
LLM integration
Tool calling
Multi-agent systems
Healthcare safety
Data persistence
Human-in-the-loop workflows

And a special acknowledgement to the team behind the Murf LiveKit Starter, which provided the foundation for the real-time voice infrastructure used in this project.

Building on an existing foundation allowed me to spend more time exploring the actual problem, architecture, and application experience.

Connect With the Project

GitHub:
https://github.com/muthukkumaranb/murf-voice-ai

Demo:
Currently not publicly available.

Challenge:
10 Days of AI Voice Agents — #VoiceForBharat

10DaysofAIVoiceAgents #VoiceForBharat #MurfFalcon #VoiceAI

DEV Community: Muthukkumaran B

Building ASHA: A Real-Time Multi-Agent Voice AI Health Guide for Bharat

Building ASHA: A Real-Time Multi-Agent Voice AI Health Guide for Bharat

Day 10 — 10 Days of AI Voice Agents #VoiceForBharat

1. The Problem

2. Why Voice?

3. Starting Point: Murf LiveKit Starter

4. System Architecture

5. LiveKit: The Real-Time Foundation

6. Speech-to-Text with Deepgram

7. LLM Reasoning with Groq

8. Murf Falcon: Giving ASHA a Voice

9. Primary Health Centre Information

10. Patient Context and Memory

11. Safety Guardrails

12. Emergency Detection and Human Escalation

13. SQLite-Based Patient and Analytics Layer

14. Real-Time Analytics Dashboard

15. Multi-Agent Architecture

16. Why Multi-Agent Instead of One Large Agent?

17. Technical Roadblock: Empty Tool Schemas

18. Technical Roadblock: 0.0.0.0 vs localhost

19. Running ASHA Locally

Prerequisites

Step 1 — Clone the Repository

Step 2 — Configure Environment Variables

Step 3 — Install Backend Dependencies

Step 4 — Install Frontend Dependencies

Step 5 — Start the Agent

Step 6 — Start the Dashboard

Step 7 — Start the Frontend

20. Deployment Architecture

21. What I Learned During the 10 Days

Lesson 1 — Real-time systems are different

Lesson 2 — Streaming matters

Lesson 3 — Tool schemas matter

Lesson 4 — Provider integration is rarely plug-and-play

Lesson 5 — Voice UX is different

Lesson 6 — Healthcare requires restraint

Lesson 7 — Building on existing infrastructure is a skill

22. What's Next for ASHA?

Regional Indian Languages

Telephony

Verified Healthcare Information

Stronger Human-in-the-Loop Workflows

Better Privacy

Production-Ready Infrastructure

23. Final Thoughts

24. Project Repository

Technology Stack

Acknowledgements

Connect With the Project

10DaysofAIVoiceAgents #VoiceForBharat #MurfFalcon #VoiceAI

18. Technical Roadblock: `0.0.0.0` vs `localhost`