Building an English Learning Voice Agent in 10 Days with Murf Falcon

Kusumarani Jana — Sat, 15 Aug 2026 04:12:42 +0000

Introduction

Over the last 10 days, I built English Learning Coach, a voice AI that helps learners practice English through natural conversations. Instead of being just another chatbot, it can remember users, use tools, escalate to a teacher when needed, track call outcomes, and hand off math questions to a specialist.

This project was built for the Learning & Literacy track in 10 Days of Voice Agents — VoiceForBharat Edition, powered by Murf Falcon.

The Problem

Many learners hesitate to practice spoken English because they don't always have someone available to practice with. A voice-based assistant makes practice feel more natural than typing and gives immediate feedback during conversations.

What My Voice Agent Can Do

By the end of the challenge, my agent includes:

🎙️ Natural voice conversations using Murf Falcon

🛡️ Clear behavior and safety guardrails

🧠 Memory for returning users

🧰 Tool-based actions instead of only generating text

📞 Outbound calling support

👩‍🏫 Human escalation with consent and reference IDs

📊 Real-time call analytics dashboard

🔀 Specialist agent handoff for math practice

How the System Works

The project combines four main components:

Speech-to-Text to understand spoken input

LLM to decide how the agent should respond

Murf Falcon Text-to-Speech for natural voice replies

LiveKit for real-time voice communication

SQLite stores memory, escalation requests, and call analytics.

My Favorite Features
Human Escalation

If a learner becomes frustrated or asks for a teacher, the agent asks permission before sharing a short summary, creates a support request, and provides a reference ID.

Call Analytics

The dashboard tracks:

Total Calls

Successful Calls

Failed Calls

These values come from real conversations instead of hardcoded numbers.

Specialist Handoff

The main English coach hands math questions to a dedicated Math Practice Specialist, keeping responsibilities focused.

The Hardest Part

The biggest challenge was integrating LiveKit's telephony and shutdown callbacks.

I encountered issues such as:

SIP configuration problems

callback errors during shutdown

analytics not saving correctly

API differences between LiveKit versions

Instead of restarting the project, I fixed each issue step by step by testing, reading logs, and making small changes until the workflow became stable.

That debugging process taught me much more than a perfect first attempt would have.

How to Run the Project

Clone the repository.

Install dependencies.

Add API keys inside .env.local.

Start the backend.

Start the frontend.

Open the browser and begin a voice conversation.

Never commit API keys or private user data.

GitHub Repository

👉 https://github.com/kusumaranikusumarani3232-hub/Murf-ai

What's Next

If I continue improving this project, I'd like to add:

Better multilingual conversations

More specialist agents

Smarter progress tracking

Richer analytics

Final Thoughts

This challenge helped me understand that building a voice agent isn't just about generating speech. It's about designing conversations, protecting users, knowing when to ask for human help, and creating experiences that solve real problems.
Thanks to Murf AI for organizing this learning journey.

I built an AI that debugs my logs — then made the AI itself debuggable with SigNoz

Kusumarani Jana — Sat, 25 Jul 2026 11:49:16 +0000

I built AI SRE Copilot for the WeMakeDevs "Agents of SigNoz" hackathon — a Streamlit app that reads raw application logs and tells you the root cause, severity, and fix, using Groq's Llama 3.3 70B model instead of manually scrolling through stack traces.

That solves the log-debugging problem. But it creates a new one: an AI tool that just hands you an answer is a black box. If the model is slow, or fails silently, or behaves worse on certain logs, you'd never know unless you happened to be watching at that exact moment. So alongside the AI feature, I instrumented the AI call itself with OpenTelemetry and shipped the traces to SigNoz — treating the Groq call as a real, observable dependency, the same way I'd treat a database query.

How it's wired up

Every time a log gets analyzed, I wrap the request in an OpenTelemetry span and attach custom attributes to it:

ai.model — which model handled the request
ai.response_latency_ms — how long Groq took to respond
log.size_bytes — size of the input log
analysis.status — success or failure
analysis.type — what kind of analysis ran
user.action — what triggered the trace

These traces get exported through the OpenTelemetry SDK to SigNoz, where they show up as searchable, queryable data instead of disappearing into a terminal log.

What SigNoz actually showed me

To watch this over time instead of one trace at a time, I built a custom panel in SigNoz using the Query Builder, plotting signoz_latency.count over the last three days:

![SigNoz custom panel plotting signoz_latency.count over the last 3 days, showing a sharp spike around 7/24 that settles back down]
There's a clear latency spike around 7/24 that I never would have caught by just watching the app — I wasn't looking at that exact moment. But because the trace data was sitting in SigNoz, I could go back afterward and actually see it happened, and roughly when.

That's the real value of this setup: the AI's behavior doesn't just vanish after each request. It's there, on a dashboard, whenever I want to check it.

Takeaway

The AI half of this project — prompting Groq, formatting a response — was the easy part. The useful lesson was realizing observability doesn't stop at your own app code. If your app calls out to an AI model, that call is a dependency like any other, and it deserves to be traced and measured, not left invisible. SigNoz made that possible without me having to build any tracing infrastructure myself.