🎙️ Building ShikshaMitra AI: 10 Days of Building a Voice-First Learning Companion for Bharat
10 Days of Voice Agents — VoiceForBharat Edition | Learning & Literacy Track
What happens when you combine voice AI, education, multilingual conversations, and agentic workflows into one project?
For the past 10 days, I worked on ShikshaMitra AI — a voice-first learning companion designed to make learning more conversational and accessible for students in Bharat.
The goal was not simply to build another chatbot.
I wanted to explore what a learning platform could look like when a student can simply speak, ask questions naturally, practice a concept, receive feedback, and ask for human help when AI isn't enough.
This project took me from a basic voice agent to a system involving:
🎙️ Real-time voice conversations 🌐 English, Hindi, and Hinglish interaction 🧠 Learner memory 🛠️ Learning tools 👨🏫 Human escalation 📊 Call analytics 📞 Telephony and outbound calling 🧮 A specialist Maths agent 🔄 Multi-agent handoffs
And, of course, a lot of debugging.
🎓 What Is ShikshaMitra AI?
ShikshaMitra AI is a real-time, voice-first learning assistant.
Instead of forcing students to type every question, the learner can speak naturally and receive a spoken response.
The broader idea is simple:
Make learning feel more like having a conversation with a helpful study companion.
The system is designed around learning areas such as:
Python Mathematics Spoken English Science Technology General learning and practice
A particularly important requirement was making the experience suitable for Indian learners.
That means supporting conversations in:
English → Hindi → Hinglish
without making language feel like a barrier to interaction.
🏗️ The Architecture
A voice agent is much more than an LLM connected to a microphone.
There are multiple real-time systems working together.
The high-level flow looks like this:
The interesting part isn't any individual component.
It's getting all of them to work together with low latency and reliable state management.
🗓️ My 10-Day Build Journey
I approached the project incrementally.
Rather than trying to build the entire platform at once, I added capabilities layer by layer.
Day 1 — Define the Problem 🎯
The first step wasn't writing code.
It was defining the problem.
Students can access enormous amounts of educational content, but access to content doesn't automatically create:
consistent practice confidence interaction immediate feedback personalized support
I wanted ShikshaMitra to focus on the gap between understanding something and actually practicing it.
The initial product question became:
Can voice make learning more natural and interactive for students?
That question became the foundation for everything that followed.
Day 2 — Design the Learning Experience 📚
Once the problem was clear, I mapped the basic learner journey.
Learner starts session ↓ Chooses / asks about a topic ↓ Speaks naturally ↓ AI understands the request ↓ Learning activity / explanation ↓ Learner responds ↓ AI evaluates ↓ Feedback
I also started thinking about what shouldn't happen.
A learning assistant shouldn't simply answer every question immediately.
Sometimes the better response is:
ask a follow-up question give a hint provide an exercise evaluate an answer recommend additional practice involve a teacher
That changed the design from a simple Q&A chatbot into a potential learning agent.
Day 3 — Build the Voice Foundation 🎙️
The next step was getting the basic voice loop working.
The fundamental pipeline was:
Speech ↓ Speech-to-Text ↓ LLM ↓ Text-to-Speech ↓ Speech
For real-time communication, I used LiveKit.
For speech recognition, I integrated Deepgram.
For speech generation, I used Murf Falcon.
Once this worked, the project became much more interesting.
The first successful voice conversation was an important milestone because the system was no longer just processing text.
It could actually listen and speak.
Day 4 — Make Conversations More Natural 🌐
A voice assistant designed for Bharat shouldn't assume that every learner will communicate in perfect English.
Real conversations can naturally move between languages.
For example:
"Can you explain photosynthesis?"
followed by:
"Thoda simple language mein samjhao."
A useful voice assistant needs to handle this kind of interaction naturally.
So multilingual and Hinglish interaction became an important part of the experience.
The objective wasn't merely language translation.
It was to make the learner feel comfortable communicating in the language they already use.
Day 5 — Add Memory and Learning Context 🧠
A voice conversation becomes significantly more useful when the system can remember relevant context.
For example:
Student: "I am preparing for Python basics." Later: "Give me another practice question."
The assistant should understand that the learner is still working on Python.
Memory can help capture useful information such as:
learner preferences current subject previous exercises learning progress relevant conversation context
But memory also introduces an important engineering responsibility:
Store only what is useful, and protect learner information.
Privacy should be part of the architecture rather than an afterthought.
📞 Day 6 — Connect Voice AI With Telephony
This was one of the most technically challenging parts.
A browser-based voice assistant is one thing.
Making an AI agent participate in a real telephone conversation introduces another layer of infrastructure.
The architecture becomes:
AI Agent ↓ LiveKit ↓ SIP / Telephony ↓ Outbound Call ↓ Learner
Now the system has to deal with:
real-time sessions telephony configuration SIP connectivity backend services call state audio transport failures across multiple services
This taught me an important lesson:
Voice AI is as much an infrastructure problem as it is an AI problem.
A great prompt doesn't help if the call drops.
A great TTS model doesn't help if audio transport fails.
Every layer has to work together.
👨🏫 Day 7 — Give the AI a Human Escape Hatch
One of the design principles I wanted to keep was:
AI should know when it needs help.
There are situations where a student may need a teacher rather than another AI-generated response.
So I introduced a human-help flow.
A learner can request assistance, and the system can create a support request that a human can review.
Conceptually:
Learner ↓ AI Agent ↓ Needs Human Support? ↓ Create Help Request ↓ Teacher / Human Support ↓ Learner
The support workflow can contain information such as:
request status urgency language learner request relevant context
This creates a human-in-the-loop architecture instead of pretending AI can solve every problem.
I think this is especially important when building systems for education.
📊 Day 8 — Build Real Call Analytics
The next challenge was understanding whether the voice sessions were actually accomplishing their learning objective.
I defined a successful learning call as a session where the learner successfully completes the intended learning exercise.
The analytics layer tracks metrics such as:
Total Calls Successful Calls Failed Calls Success Rate
The data flow looks like:
Voice Session ↓ Learning Exercise ↓ Exercise Result ↓ Database ↓ Analytics API ↓ Dashboard
The important distinction is that these metrics should come from actual application events.
They shouldn't simply be hardcoded numbers displayed on a dashboard.
While implementing this, I ran into backend/API issues where the frontend loaded correctly but the analytics service wasn't responding as expected.
That debugging session reinforced something I've repeatedly experienced while building AI applications:
The AI is often not the hardest part.
Integration is.
🧮 Day 9 — Introduce a Maths Specialist
By this stage, the main agent was doing several different jobs.
But giving one agent responsibility for everything isn't always the best architecture.
So I experimented with a specialist agent dedicated to mathematics practice.
The flow became:
Learner ↓ Main Agent ↓ Detect Maths Request ↓ Maths Specialist ↓ Practice Problem ↓ Evaluate Answer ↓ Feedback
For example, a learner could say:
"I want to practice maths."
The main agent can identify the intent and hand the conversation to the Maths Specialist.
The specialist can then focus specifically on:
generating practice problems asking questions evaluating answers giving hints explaining mistakes continuing the exercise
The learner doesn't need to restart the entire conversation.
🤖 Moving Toward a Multi-Agent System
This introduced a more interesting architecture:
Learner
│
▼
Voice / Web UI
│
▼
LiveKit
(WebRTC)
│
▼
Deepgram
(Speech-to-Text)
│
▼
Main Agent + LLM
│
├──► Learning Tools
│
├──► Learning Memory
│
└──► Specialist Agents
│
├──► Maths Specialist
│
└──► Teacher Help
│
▼
Human Escalation
│
▼
Human Support
Main Agent
│
▼
Murf Falcon
(Text-to-Speech)
│
▼
Voice Response
│
▼
Learner
Support Maths Practice
The main agent handles general interaction.
Specialized agents handle focused tasks.
This makes the system easier to reason about as the number of capabilities grows.
Instead of creating one enormous prompt containing every possible instruction, responsibilities can be distributed between specialized components.
🚀 Day 10 — Testing, Refinement & Reflection
The final day wasn't simply about adding another feature.
It was about stepping back and testing the entire system.
I tested:
voice input speech recognition AI responses speech output multilingual conversations learning interactions memory specialist handoffs human escalation analytics telephony flows
I also focused on documenting what worked, what didn't, and what still needs improvement.
After 10 days, the project had evolved significantly from the original voice-agent prototype.
🛠️ Tech Stack
The core stack looks like this:
Technology Role React / Next.js Frontend and learner interface Python Agent/backend logic LiveKit Real-time voice communication Deepgram Speech-to-Text LLM Reasoning and conversation Murf Falcon Text-to-Speech SQLite / Database Memory and analytics SIP / Telephony Voice calling
The exact architecture can evolve as the application scales, but this stack was enough to explore the core voice-agent workflow.
🎙️ What Actually Makes a Voice Agent?
It's tempting to think:
LLM + Microphone = Voice Agent
In practice, it's closer to:
Voice Input ↓ Speech Recognition ↓ Conversation State ↓ LLM Reasoning ↓ Tool Selection ↓ Memory / Context ↓ Specialist Handoff ↓ Response Generation ↓ Text-to-Speech ↓ Real-Time Audio
And around all of this you need:
observability error handling authentication data protection latency management session management API reliability
That's what makes production voice AI interesting.
🔐 A Quick Security Reminder
Voice applications can process sensitive information.
That makes credential and data security especially important.
Never commit API credentials directly into the repository.
Use environment variables:
MURF_API_KEY=your_key_here DEEPGRAM_API_KEY=your_key_here LIVEKIT_API_KEY=your_key_here LIVEKIT_API_SECRET=your_secret_here
And keep sensitive files out of version control:
.env .env.local
Also avoid publishing:
API keys phone numbers private learner information call recordings authentication credentials internal service secrets
Building a useful AI system also means building it responsibly.
🧪 How I Test the Agent
Once the backend and frontend are running, the basic testing flow is:
Start Backend ↓ Start Frontend ↓ Open Browser ↓ Allow Microphone ↓ Connect to Agent ↓ Start Conversation
A simple test could be:
"Can you help me practice Python?"
Then test the specialist flow:
"I want to practice maths."
The expected behavior is that the main agent recognizes the request and transfers the relevant context to the Maths Specialist.
This kind of testing is important because a voice agent isn't successful merely because it can answer a question.
It needs to complete a useful interaction.
💡 What I Learned From the 10 Days 1. Voice AI is a systems problem
The LLM is only one component.
Latency, networking, STT, TTS, state, telephony, APIs, and frontend behavior all matter.
- Specialization can beat one giant agent
A single general-purpose agent can become complicated very quickly.
Specialized agents provide clearer responsibilities and potentially more predictable behavior.
- Human-in-the-loop matters
AI shouldn't always be the final destination.
Sometimes the correct action is:
"I can't solve this reliably." ↓ "Let me get human help."
That's a feature, not a failure.
- Analytics should measure outcomes
Counting conversations isn't enough.
For an educational application, we eventually want to know:
Did the learner actually learn or practice something?
That means measuring meaningful outcomes rather than vanity metrics.
- Multilingual interaction is more than translation
For Bharat-focused products, language flexibility should be part of the user experience from the beginning.
A learner shouldn't have to change their natural communication style just to use an AI system.
🇮🇳 Why Build for Bharat?
India has an enormous diversity of:
languages educational backgrounds devices connectivity conditions learning styles levels of digital literacy
Voice can remove some of the friction associated with typing and traditional interfaces.
A student doesn't necessarily need to know how to formulate the perfect prompt.
They can simply ask:
"Mujhe fractions samjhao."
or:
"Can you explain this in simple English?"
or:
"Ek maths question do."
That feels much closer to how people naturally learn.
🔮 What's Next?
The 10-day challenge is only the beginning.
Some areas I'd like to explore next are:
🌐 More Indian Languages
Expand beyond English, Hindi, and Hinglish.
🎯 Personalized Learning Paths
Adapt difficulty and content based on learner performance.
🗣️ Pronunciation Feedback
Especially for spoken English practice.
🧮 More Specialist Agents
For example:
English Speaking Coach Science Tutor Coding Mentor Interview Coach Reading Assistant 📊 Better Learning Analytics
Move from call analytics toward actual learning analytics.
🎮 Interactive Exercises
Make learning more engaging through voice-based quizzes, challenges, and practice sessions.
📞 Better Telephony Reliability
Improve call quality, failure handling, and large-scale reliability.
👩🏫 Stronger Human Support
Build better workflows between AI assistance and teachers.
❤️ Final Thoughts
Ten days ago, this started as an experiment with voice agents.
By the end, it had become something much more interesting:
a voice-first learning system with memory, tools, human escalation, analytics, telephony, and specialist agents.
The biggest lesson I learned isn't about any particular AI model.
It's this:
A good voice agent isn't simply one that can talk. It's one that knows how to help.
For education, that means understanding the learner, providing useful practice, adapting to their language, recognizing its own limitations, and involving a human when necessary.
That's the direction I want to continue exploring with ShikshaMitra AI.
🎙️ ShikshaMitra AI — Learn · Practice · Understand · Grow
🙌 Thank You
I'm grateful for the opportunity to participate in the 10 Days of Voice Agents — VoiceForBharat Edition and spend 10 days building, breaking, debugging, and learning.
This challenge gave me a practical look at what it takes to move from:
Idea ↓ Prototype ↓ Voice Agent ↓ Tools + Memory ↓ Human-in-the-Loop ↓ Analytics ↓ Multi-Agent System
And I'm only getting started.
🔗 Project Links
GitHub: [Add your GitHub repository here]
Live Demo: [Add your deployed demo here]
Demo Video: [Add your demo video here]
LinkedIn: [Add your LinkedIn profile here]
🏷️ Tags
VoiceForBharat #10DaysOfVoiceAgents #VoiceAI #AI #GenerativeAI #LearningAndLiteracy #MurfFalcon #LiveKit #Deepgram #Python #NextJS #MultiAgentAI #EdTech #BuildInPublic #India
🎙️ Building ShikshaMitra AI: 10 Days of Building a Voice-First Learning Companion for Bharat
10 Days of Voice Agents — VoiceForBharat Edition | Learning & Literacy Track
What happens when you combine voice AI, education, multilingual conversations, and agentic workflows into one project?
For the past 10 days, I worked on ShikshaMitra AI — a voice-first learning companion designed to make learning more conversational and accessible for students in Bharat.
The goal was not simply to build another chatbot.
I wanted to explore what a learning platform could look like when a student can simply speak, ask questions naturally, practice a concept, receive feedback, and ask for human help when AI isn't enough.
This project took me from a basic voice agent to a system involving:
🎙️ Real-time voice conversations 🌐 English, Hindi, and Hinglish interaction 🧠 Learner memory 🛠️ Learning tools 👨🏫 Human escalation 📊 Call analytics 📞 Telephony and outbound calling 🧮 A specialist Maths agent 🔄 Multi-agent handoffs
And, of course, a lot of debugging.
🎓 What Is ShikshaMitra AI?
ShikshaMitra AI is a real-time, voice-first learning assistant.
Instead of forcing students to type every question, the learner can speak naturally and receive a spoken response.
The broader idea is simple:
Make learning feel more like having a conversation with a helpful study companion.
The system is designed around learning areas such as:
Python Mathematics Spoken English Science Technology General learning and practice
A particularly important requirement was making the experience suitable for Indian learners.
That means supporting conversations in:
English → Hindi → Hinglish
without making language feel like a barrier to interaction.
🏗️ The Architecture
A voice agent is much more than an LLM connected to a microphone.
There are multiple real-time systems working together.
The high-level flow looks like this:
Learner → Voice/Web UI → LiveKit → Deepgram → Main Agent + LLM → Memory / Specialist Agents / Tools / Analytics → Human Escalation → Murf Falcon → Audio Response
The interesting part isn't any individual component.
It's getting all of them to work together with low latency and reliable state management.
🗓️ My 10-Day Build Journey
I approached the project incrementally.
Rather than trying to build the entire platform at once, I added capabilities layer by layer.
Day 1 — Define the Problem 🎯
The first step wasn't writing code.
It was defining the problem.
Students can access enormous amounts of educational content, but access to content doesn't automatically create:
consistent practice confidence interaction immediate feedback personalized support
I wanted ShikshaMitra to focus on the gap between understanding something and actually practicing it.
The initial product question became:
Can voice make learning more natural and interactive for students?
That question became the foundation for everything that followed.
Day 2 — Design the Learning Experience 📚
Once the problem was clear, I mapped the basic learner journey.
Learner starts session ↓ Chooses / asks about a topic ↓ Speaks naturally ↓ AI understands the request ↓ Learning activity / explanation ↓ Learner responds ↓ AI evaluates ↓ Feedback
I also started thinking about what shouldn't happen.
A learning assistant shouldn't simply answer every question immediately.
Sometimes the better response is:
ask a follow-up question give a hint provide an exercise evaluate an answer recommend additional practice involve a teacher
That changed the design from a simple Q&A chatbot into a potential learning agent.
Day 3 — Build the Voice Foundation 🎙️
The next step was getting the basic voice loop working.
The fundamental pipeline was:
Speech ↓ Speech-to-Text ↓ LLM ↓ Text-to-Speech ↓ Speech
For real-time communication, I used LiveKit.
For speech recognition, I integrated Deepgram.
For speech generation, I used Murf Falcon.
Once this worked, the project became much more interesting.
The first successful voice conversation was an important milestone because the system was no longer just processing text.
It could actually listen and speak.
Day 4 — Make Conversations More Natural 🌐
A voice assistant designed for Bharat shouldn't assume that every learner will communicate in perfect English.
Real conversations can naturally move between languages.
For example:
"Can you explain photosynthesis?"
followed by:
"Thoda simple language mein samjhao."
A useful voice assistant needs to handle this kind of interaction naturally.
So multilingual and Hinglish interaction became an important part of the experience.
The objective wasn't merely language translation.
It was to make the learner feel comfortable communicating in the language they already use.
Day 5 — Add Memory and Learning Context 🧠
A voice conversation becomes significantly more useful when the system can remember relevant context.
For example:
Student: "I am preparing for Python basics." Later: "Give me another practice question."
The assistant should understand that the learner is still working on Python.
Memory can help capture useful information such as:
learner preferences current subject previous exercises learning progress relevant conversation context
But memory also introduces an important engineering responsibility:
Store only what is useful, and protect learner information.
Privacy should be part of the architecture rather than an afterthought.
📞 Day 6 — Connect Voice AI With Telephony
This was one of the most technically challenging parts.
A browser-based voice assistant is one thing.
Making an AI agent participate in a real telephone conversation introduces another layer of infrastructure.
The architecture becomes:
AI Agent ↓ LiveKit ↓ SIP / Telephony ↓ Outbound Call ↓ Learner
Now the system has to deal with:
real-time sessions telephony configuration SIP connectivity backend services call state audio transport failures across multiple services
This taught me an important lesson:
Voice AI is as much an infrastructure problem as it is an AI problem.
A great prompt doesn't help if the call drops.
A great TTS model doesn't help if audio transport fails.
Every layer has to work together.
👨🏫 Day 7 — Give the AI a Human Escape Hatch
One of the design principles I wanted to keep was:
AI should know when it needs help.
There are situations where a student may need a teacher rather than another AI-generated response.
So I introduced a human-help flow.
A learner can request assistance, and the system can create a support request that a human can review.
Conceptually:
Learner ↓ AI Agent ↓ Needs Human Support? ↓ Create Help Request ↓ Teacher / Human Support ↓ Learner
The support workflow can contain information such as:
request status urgency language learner request relevant context
This creates a human-in-the-loop architecture instead of pretending AI can solve every problem.
I think this is especially important when building systems for education.
📊 Day 8 — Build Real Call Analytics
The next challenge was understanding whether the voice sessions were actually accomplishing their learning objective.
I defined a successful learning call as a session where the learner successfully completes the intended learning exercise.
The analytics layer tracks metrics such as:
Total Calls Successful Calls Failed Calls Success Rate
The data flow looks like:
Voice Session ↓ Learning Exercise ↓ Exercise Result ↓ Database ↓ Analytics API ↓ Dashboard
The important distinction is that these metrics should come from actual application events.
They shouldn't simply be hardcoded numbers displayed on a dashboard.
While implementing this, I ran into backend/API issues where the frontend loaded correctly but the analytics service wasn't responding as expected.
That debugging session reinforced something I've repeatedly experienced while building AI applications:
The AI is often not the hardest part.
Integration is.
🧮 Day 9 — Introduce a Maths Specialist
By this stage, the main agent was doing several different jobs.
But giving one agent responsibility for everything isn't always the best architecture.
So I experimented with a specialist agent dedicated to mathematics practice.
The flow became:
Learner ↓ Main Agent ↓ Detect Maths Request ↓ Maths Specialist ↓ Practice Problem ↓ Evaluate Answer ↓ Feedback
For example, a learner could say:
"I want to practice maths."
The main agent can identify the intent and hand the conversation to the Maths Specialist.
The specialist can then focus specifically on:
generating practice problems asking questions evaluating answers giving hints explaining mistakes continuing the exercise
The learner doesn't need to restart the entire conversation.
🤖 Moving Toward a Multi-Agent System
This introduced a more interesting architecture:
Learner
│
▼
Voice / Web UI
│
▼
LiveKit
(WebRTC)
│
▼
Deepgram
(Speech-to-Text)
│
▼
Main Agent + LLM
│
├──► Learning Tools
│
├──► Learning Memory
│
└──► Specialist Agents
│
├──► Maths Specialist
│
└──► Teacher Help
│
▼
Human Escalation
│
▼
Human Support
Main Agent
│
▼
Murf Falcon
(Text-to-Speech)
│
▼
Voice Response
│
▼
Learner
The main agent handles general interaction.
Specialized agents handle focused tasks.
This makes the system easier to reason about as the number of capabilities grows.
Instead of creating one enormous prompt containing every possible instruction, responsibilities can be distributed between specialized components.
🚀 Day 10 — Testing, Refinement & Reflection
The final day wasn't simply about adding another feature.
It was about stepping back and testing the entire system.
I tested:
voice input speech recognition AI responses speech output multilingual conversations learning interactions memory specialist handoffs human escalation analytics telephony flows
I also focused on documenting what worked, what didn't, and what still needs improvement.
After 10 days, the project had evolved significantly from the original voice-agent prototype.
🛠️ Tech Stack
The core stack looks like this:
Technology Role React / Next.js Frontend and learner interface Python Agent/backend logic LiveKit Real-time voice communication Deepgram Speech-to-Text LLM Reasoning and conversation Murf Falcon Text-to-Speech SQLite / Database Memory and analytics SIP / Telephony Voice calling
The exact architecture can evolve as the application scales, but this stack was enough to explore the core voice-agent workflow.
🎙️ What Actually Makes a Voice Agent?
It's tempting to think:
LLM + Microphone = Voice Agent
In practice, it's closer to:
Voice Input ↓ Speech Recognition ↓ Conversation State ↓ LLM Reasoning ↓ Tool Selection ↓ Memory / Context ↓ Specialist Handoff ↓ Response Generation ↓ Text-to-Speech ↓ Real-Time Audio
And around all of this you need:
observability error handling authentication data protection latency management session management API reliability
That's what makes production voice AI interesting.
🔐 A Quick Security Reminder
Voice applications can process sensitive information.
That makes credential and data security especially important.
Never commit API credentials directly into the repository.
Use environment variables:
MURF_API_KEY=your_key_here DEEPGRAM_API_KEY=your_key_here LIVEKIT_API_KEY=your_key_here LIVEKIT_API_SECRET=your_secret_here
And keep sensitive files out of version control:
.env .env.local
Also avoid publishing:
API keys phone numbers private learner information call recordings authentication credentials internal service secrets
Building a useful AI system also means building it responsibly.
🧪 How I Test the Agent
Once the backend and frontend are running, the basic testing flow is:
Start Backend ↓ Start Frontend ↓ Open Browser ↓ Allow Microphone ↓ Connect to Agent ↓ Start Conversation
A simple test could be:
"Can you help me practice Python?"
Then test the specialist flow:
"I want to practice maths."
The expected behavior is that the main agent recognizes the request and transfers the relevant context to the Maths Specialist.
This kind of testing is important because a voice agent isn't successful merely because it can answer a question.
It needs to complete a useful interaction.
💡 What I Learned From the 10 Days 1. Voice AI is a systems problem
The LLM is only one component.
Latency, networking, STT, TTS, state, telephony, APIs, and frontend behavior all matter.
- Specialization can beat one giant agent
A single general-purpose agent can become complicated very quickly.
Specialized agents provide clearer responsibilities and potentially more predictable behavior.
- Human-in-the-loop matters
AI shouldn't always be the final destination.
Sometimes the correct action is:
"I can't solve this reliably." ↓ "Let me get human help."
That's a feature, not a failure.
- Analytics should measure outcomes
Counting conversations isn't enough.
For an educational application, we eventually want to know:
Did the learner actually learn or practice something?
That means measuring meaningful outcomes rather than vanity metrics.
- Multilingual interaction is more than translation
For Bharat-focused products, language flexibility should be part of the user experience from the beginning.
A learner shouldn't have to change their natural communication style just to use an AI system.
🇮🇳 Why Build for Bharat?
India has an enormous diversity of:
languages educational backgrounds devices connectivity conditions learning styles levels of digital literacy
Voice can remove some of the friction associated with typing and traditional interfaces.
A student doesn't necessarily need to know how to formulate the perfect prompt.
They can simply ask:
"Mujhe fractions samjhao."
or:
"Can you explain this in simple English?"
or:
"Ek maths question do."
That feels much closer to how people naturally learn.
🔮 What's Next?
The 10-day challenge is only the beginning.
Some areas I'd like to explore next are:
🌐 More Indian Languages
Expand beyond English, Hindi, and Hinglish.
🎯 Personalized Learning Paths
Adapt difficulty and content based on learner performance.
🗣️ Pronunciation Feedback
Especially for spoken English practice.
🧮 More Specialist Agents
For example:
English Speaking Coach Science Tutor Coding Mentor Interview Coach Reading Assistant 📊 Better Learning Analytics
Move from call analytics toward actual learning analytics.
🎮 Interactive Exercises
Make learning more engaging through voice-based quizzes, challenges, and practice sessions.
📞 Better Telephony Reliability
Improve call quality, failure handling, and large-scale reliability.
👩🏫 Stronger Human Support
Build better workflows between AI assistance and teachers.
❤️ Final Thoughts
Ten days ago, this started as an experiment with voice agents.
By the end, it had become something much more interesting:
a voice-first learning system with memory, tools, human escalation, analytics, telephony, and specialist agents.
The biggest lesson I learned isn't about any particular AI model.
It's this:
A good voice agent isn't simply one that can talk. It's one that knows how to help.
For education, that means understanding the learner, providing useful practice, adapting to their language, recognizing its own limitations, and involving a human when necessary.
That's the direction I want to continue exploring with ShikshaMitra AI.
🎙️ ShikshaMitra AI — Learn · Practice · Understand · Grow
🙌 Thank You
I'm grateful for the opportunity to participate in the 10 Days of Voice Agents — VoiceForBharat Edition and spend 10 days building, breaking, debugging, and learning.
This challenge gave me a practical look at what it takes to move from:
Idea ↓ Prototype ↓ Voice Agent ↓ Tools + Memory ↓ Human-in-the-Loop ↓ Analytics ↓ Multi-Agent System
And I'm only getting started.
🔗 Project Links
Github: aryajain19/murf-livekit-starter
LinkedIn: https://www.linkedin.com/posts/arya-jain-008295330
🏷️ Tags
