Askimo

Askimo — EvoTalk Voice Agent

Multilingual voice agent for SME sales operations, with live CRM context injected mid-call and sub-second end-to-end latency held across roughly twenty concurrent conversations.

Role
NLP Engineer / Systems Architect / Python Backend
Period
Feb 2026–May 2026

01 Problem What was actually hard

Indian SMEs needed a voice agent that speaks regional languages, pulls a caller's real history out of the CRM while the call is still live, and executes workflows — book a callback, look up stock, hand off to a human — without breaking the conversation. The difficulty was orchestration, not raw inference: 200ms of ASR, 300ms of generation and 150ms of synthesis compound into a pause long enough for a caller to talk over the agent.

02 Data Sourcing and preparation

Built annotated regional-language voice datasets (Hindi, Telugu, Kannada) from partner call-centre recordings, labelled for intent, emotion and turn boundary. Turn-taking in these languages does not look like English — pauses, intonation and backchannels differ — so the VAD was fine-tuned on that annotated data rather than used off the shelf. Caller context was normalised out of partner CRM APIs into one JSON schema and cached in Redis on a short TTL so prompt assembly costs nothing at call time.

03 Models Evaluated, kept, cut

5 evaluated 3 kept 2 cut

Kept 3

  • Sarvam Models

    Native Indian-language ASR and synthesis, CPU-efficient enough to run per-call

  • Silero VAD

    Voice-activity detection fine-tuned on regional pause patterns for turn detection

  • Mistral 7B Instruct

    Intent classification and tool routing at a token rate the loop can absorb

Cut 2

  • Google Cloud TTS

    Passed 500ms under concurrency; replaced with local synthesis

  • GPT-4 Turbo

    External round trip plus per-call cost incompatible with the price point

04 Architecture How it fits together

An asyncio orchestrator runs the pipeline: Sarvam ASR into fine-tuned Silero VAD for turn detection, into Mistral for intent, into a function-calling router that hits CRM lookup, booking or transfer, into local synthesis. Prompt augmentation injects the live CRM record — caller name, account status, open issues — so the agent opens with context instead of asking for it. WebSocket servers hold the client connections, a Redis-backed queue routes calls to free inference workers, and PostgreSQL keeps transcripts, intents and tool invocations for compliance audit.

Architecture flow: Caller audio then Sarvam ASR then Silero VAD then Mistral 7B then Tool router then Local synthesis 01 Caller audio WebSocket stream 02 Sarvam ASR Hindi / Telugu / Kannada / English 03 Silero VAD turn detection on regional pause patterns CRM context (Redis) 04 Mistral 7B intent + tool choice 05 Tool router lookup · booking · transfer 06 Local synthesis spoken reply

05 Production Deployment and operation

AWS EC2 m6i instances for CPU-bound inference behind an application load balancer, with SQS distributing incoming calls. Inference batching amortises model load; connection pooling on Redis and PostgreSQL removes per-call setup. Dashboards track latency percentiles, call success rate and tool-invocation accuracy, and new prompts are A/B tested against production traffic.

06 Deep dive The long version, in full

Problem

Indian SMEs running sales and management operations faced a critical gap: existing voice AI solutions either didn’t support regional languages or introduced latency that frustrated customers. Agents needed to dynamically fetch customer context (previous purchase history, account details, pending issues) mid-call and execute workflows—booking a callback, looking up inventory, transferring to a human agent—without breaking conversation flow.

The challenge wasn’t just inference speed; it was orchestration. A 200ms ASR delay, a 300ms LLM inference, a 150ms synthesis latency—each compounded into a frustrating user experience. We needed sub-second end-to-end performance across 20+ concurrent calls on reasonable hardware.

Data Preparation

We built custom voice datasets for Indian regional languages (Hindi, Telugu, Kannada) by partnering with call centers to collect natural customer interactions. These were annotated for speaker intent, emotion, and turn boundaries. The key insight: turn-detection in Indian languages is different from English—pauses, intonation, and backchannels follow different patterns. We fine-tuned a Silero VAD model on this annotated regional data.

Customer context (name, order history, account balance, pending issues) was normalized from partner CRM APIs into a structured JSON schema, cached in Redis with 5-minute TTL for zero-latency injection into LLM prompts.

Models Evaluated

Model Result Note
Sarvam Models Kept Native regional language ASR/TTS, CPU-efficient, <100ms inference
Silero VAD Kept Lightweight voice-activity detection; fine-tuned on regional speech
Custom Turn-Detection Kept Regional pause patterns; trained on partner call data
Mistral 7B Instruct Kept Compact LLM for intent + tool routing; 50–80ms per token
Google Cloud TTS Cut 500ms+ latency on concurrency; switched to local synthesis
GPT-4 Turbo Ruled out External API latency + cost incompatible with SMS/voice price point

Architecture

The pipeline flows through a async orchestrator (Python asyncio):

[Audio Input] -> Sarvam ASR -> Silero VAD (turn-detect)
  v
LLM Intent (Mistral) <- [CRM Context from Redis]
  v
Tool Router (function-calling) -> CRM Lookup / Booking / Transfer
  v
Local Synthesis -> [Audio Output]

Real-time call context is injected via prompt templating: “Customer [NAME] called on [DATE]. Order history: [ORDERS]. Pending issue: [ISSUE]. How do you respond?”

WebSocket servers maintain persistent client connections; a Redis-backed queue routes calls to available inference workers. Call logs (audio transcripts, intent, tool invocation, outcome) are written to PostgreSQL for compliance audits and model monitoring.

Production & Scale

Deployed on AWS EC2 m6i instances (CPU-bound inference workload). Horizontal scaling through an Application Load Balancer; incoming calls distributed via SQS. Inference batching (2–4 sequences per batch) amortizes model load overhead. Connection pooling on Redis and PostgreSQL eliminates per-call overhead.

Monitoring dashboards track latency percentiles (P50, P95, P99), call success rate, and tool invocation accuracy. A/B testing framework allows testing new prompts or models against production without customer impact.

Result: Sub-1s median end-to-end latency, 99.2% uptime, 94% accurate intent classification. Cost per call: ₹0.12 (USD ~0.0015) including infrastructure and AI labor.

end-to-end latency
under 1s median
concurrency held
~20 simultaneous calls