DEV Community

Muthukkumaran B
Muthukkumaran B

Posted on

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

#agents #ai #devchallenge

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 │
                    └──────────────────┘
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Voice requires something closer to:

Audio Stream
   ⇅
Real-Time Communication
   ⇅
Audio Stream
Enter fullscreen mode Exit fullscreen mode

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

The basic architecture becomes:

Browser
   │
   ▼
LiveKit
   │
   ▼
Voice Agent
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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         │
└───────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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()
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For example:

uvicorn app:app --host 0.0.0.0 --port 8000
Enter fullscreen mode Exit fullscreen mode

But opening:

http://0.0.0.0:8000
Enter fullscreen mode Exit fullscreen mode

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

The distinction is:

0.0.0.0
Enter fullscreen mode Exit fullscreen mode

is a server bind address.

For local browser access, use:

http://localhost:8000
Enter fullscreen mode Exit fullscreen mode

or:

http://127.0.0.1:8000
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

If required by the project:

uv run python src/agent.py download-files
Enter fullscreen mode Exit fullscreen mode

Step 4 — Install Frontend Dependencies

From the repository root:

cd frontend
pnpm install
Enter fullscreen mode Exit fullscreen mode

Step 5 — Start the Agent

From the backend directory:

uv run python src/agent.py dev
Enter fullscreen mode Exit fullscreen mode

Step 6 — Start the Dashboard

If using the analytics dashboard:

uv run python src/dashboard.py
Enter fullscreen mode Exit fullscreen mode

The dashboard can be accessed locally through:

http://localhost:8000
Enter fullscreen mode Exit fullscreen mode

Step 7 — Start the Frontend

From the frontend directory:

pnpm dev
Enter fullscreen mode Exit fullscreen mode

Then open:

http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

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     │
                    └──────────────┘
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)