Waani — India-First Voice AI Infrastructure

Active Development — Waani is currently being built. This page documents the architecture, decisions, and progress as the project evolves.

Overview

Waani is an India-first developer platform for building production-ready AI phone agents.

The voice AI space is growing fast — but the infrastructure behind it is still painful to build. Every team that wants to ship a voice agent has to independently solve telephony, WebSocket audio streaming, speech-to-text, LLM orchestration, text-to-speech, conversation state, multi-tenancy, and provider reliability. That's a significant distributed systems problem before you've written a single line of actual product logic.

Waani's goal is to solve that infrastructure layer once — and expose it through a clean, developer-focused API. So a team building a support bot, a voice IVR, or a Hindi-language assistant can focus on the experience they're building, not the plumbing underneath it.

I'm building this because I've worked through those infrastructure problems myself, and I believe there's a real gap in the Indian market specifically — where telephony, language, and cost constraints make generic global platforms a poor fit.

The Problem

Building a voice AI agent is genuinely hard the first time.

It looks approachable from the outside — connect a phone number, run some audio through an LLM, play back a response. But in practice, you're dealing with:

• Telephony providers with their own quirks and failure modes
• WebSocket audio that needs to flow bidirectionally without buffering or gaps
• STT that needs to produce clean transcripts fast enough for a conversation to feel natural
• LLM responses that need to arrive before the caller gets impatient
• TTS that needs to sound good enough not to break the experience
• Conversation memory that persists across multiple turns
• Provider failures that can silently kill a session mid-call
• Multi-tenant isolation so one customer's calls don't affect another's

Every one of these is a solvable problem. But solving all of them together, reliably, at scale, is a real engineering effort — one that most product teams shouldn't have to repeat from scratch.

What I'm Building

Waani is the infrastructure layer that handles all of this, exposed as a developer platform.

A team using Waani can:

1. Create an AI agent with instructions, language, and persona
2. Connect an Indian phone number through Exotel
3. Receive or initiate a call
4. Have a real-time multi-turn AI conversation — STT → LLM → TTS, all coordinated
5. Automatically save the transcript and call metadata
6. Inspect everything through a dashboard or API

The intended workflow from signup to first real call is:

Sign up → Create Agent → Configure Agent → Connect Number → Make a Call → Inspect Transcript

const agent = await waani.agents.create({
  name: "Support Agent",
  language: "hi-IN",
  instructions: "You are a helpful support agent for Acme Corp."
});

const call = await waani.calls.create({
  agentId: agent.id,
  to: "+91XXXXXXXXXX"
});

The API is the primary interface. The dashboard handles configuration and gives operational visibility into calls, transcripts, and agent performance.

Architecture

The system is built around a realtime voice runtime — the core engine that coordinates the telephony connection, audio stream, STT, LLM, and TTS layers for each active call.

The architecture is deliberately modular. Each provider sits behind an interface, so STT, LLM, TTS, and telephony can be swapped or upgraded independently without touching the core conversation logic. That makes future provider changes, fallback strategies, and performance tuning much easier to introduce.

Multi-tenancy is enforced at the data and API layer — not as a frontend concern. Each organization's agents, calls, transcripts, and keys are isolated from day one.

Key Engineering Decisions

WebSocket-first audio transport. Real phone calls don't work with request/response. The voice runtime maintains a persistent WebSocket connection for the duration of each call, handling bidirectional audio in real time.

Provider abstraction from the start. Indian voice AI has limited provider options compared to global markets. Locking business logic to a single STT or TTS provider early would make future improvements painful. Every external service sits behind an interface so the underlying provider can change without breaking the conversation pipeline.

Explicit timeout and failure handling. If an external provider hangs, the call should recover — not wait indefinitely. Every step in the pipeline has explicit timeouts and failure paths so a single slow provider can't stall the entire session.

Tenant isolation enforced at the data layer. Ownership is checked at the database and API level on every request. Frontend filtering is not a security boundary.

Why India-First

Most voice AI platforms are built for English-speaking, US/EU markets. When you try to use them for Indian use cases, you run into gaps immediately:

• Telephony integrations that don't support Indian carriers
• STT models that handle Indian English or Hindi poorly
• Latency characteristics that don't account for Indian network conditions
• Pricing that doesn't make sense at Indian market rates

Waani is being built with these constraints as first-class design requirements — not as afterthoughts. The initial focus is on Indian telephony (Exotel), Sarvam for Hindi/Indic language STT and TTS, Hinglish support, and cost-conscious infrastructure designed for Indian market economics.

Current Status

The first milestone is one complete, end-to-end workflow: create an agent → connect an Indian phone number → make a real call → have a multi-turn AI conversation → save the transcript → inspect the call in the dashboard.

Once that loop works reliably, the next stage covers provider fallback, multilingual support, voice quality evaluation, model routing, and deeper observability.

Building in public and shipping toward something real — not just a prototype.

What This Project Demonstrates

For anyone reviewing this as part of hiring or due diligence:

This project represents the kind of engineering problem I actively seek out — not a tutorial project or a CRUD application, but a genuine distributed systems challenge with real constraints around latency, reliability, and provider dependencies.

It shows experience with realtime systems, WebSocket infrastructure, multi-tenant architecture, API design, provider abstraction patterns, and the ability to scope and execute a non-trivial solo product from architecture to working system.

Waani is unfinished. That's the point — it's being built right now. The decisions being made here reflect how I actually think about systems, not just what I can ship in a weekend.