How Blue Machines Actually Builds Their Voice AI: Floe, Aurora, Polaris and BM Zap Explained

This is Part 8 of the Voice AI guide. Part 7 compared cascaded and speech-to-speech architectures in general. This part looks at one specific Indian stack in detail: Blue Machines AI, the enterprise voice AI platform spun out of the Apna Group. The question is simple — how is their voice AI actually built, model by model.

Who Blue Machines is, in one paragraph

Blue Machines AI is an enterprise-grade voice AI platform launched publicly in October 2025. It started as an internal R&D project inside Apna, India's largest jobs marketplace, and now sells voice agents into banks, insurers, mutual funds, healthcare, telecom and government in India. Founder and CEO Nirmit Parikh also runs Apna; CTO Abhishek Ranjan is CTO across both companies. Headquarters is Bengaluru. Named customers include Aditya Birla Capital, Muthoot Finance, Star Air and GCAS (Gujarat's statewide higher-education admissions platform). The marketing line is "the world's fastest enterprise-grade voice AI platform".

The five models they ship

Unlike most Indian voice-AI startups that orchestrate third-party STT, LLM and TTS APIs, Blue Machines publishes five in-house models on bluemachines.ai/models. Four of them are clearly their own, one is more subtle. Here they are in the order the audio flows through them.

1. Noise cancellation (front end)

A classical audio pre-processor sitting ahead of the recogniser. Its job is to clean background noise out of 8 kHz telephony audio before anything downstream has to look at it. This matters because recognition quality on Indian call-centre traffic drops sharply with hold-music bleed, call-centre babble and bad handsets. No numbers are published for it, but it is standard DSP-plus-neural-network territory.

2. Answering-machine detection (call setup)

A small classifier that decides, within the first second or two, whether the live party on the other end is a human or a voicemail greeting. On a voicemail hit, the workflow either hangs up, leaves a prerecorded message or schedules a retry. Every outbound dialer in collections, verification and lead qualification needs this; getting it wrong at scale burns money and annoys customers.

3. Floe — the language-switch router

Floe is the model that makes the rest of the stack multilingual-correct. It is a context-aware language-detection model trained on how Indians actually speak, not on clean monolingual text.

The important thing Floe does is distinguish borrowed words from a real language switch. In the sentence "mujhe apni payment date check karni hai", the words "payment date check" are English, but the caller is still speaking Hindi and expects a Hindi reply. A naive detector would flip the language on every English word. Floe reads several turns of conversational context and only triggers a switch when the caller actually changes language preference.

Published characteristics:

• 11 supported languages: English, Hindi, Tamil, Telugu, Gujarati, Kannada, Malayalam, Marathi, Bengali, Odia and Punjabi.
• Under 10 ms CPU inference per decision, according to internal measurements.
• Its output steers three things downstream: the STT language model, the LLM response language, and the TTS voice.

This is the piece most competitors in India don't have. Sarvam, Smallest, Skit and Gnani all handle code-mixing to varying degrees, but none ship a dedicated router with a published sub-10 ms budget. Floe is the "invisible" model that makes everything else usable.

4. Aurora — speech-to-text tuned for Indian BFSI

Aurora is their speech recogniser, built specifically for Indian banking, financial services and insurance (BFSI) conversations. It is trained for Indian English, Hindi and Hinglish, and tuned to pick up the entities that actually matter in a financial call: amounts, policy numbers, account references, loan numbers, dates and product terminology.

Aurora runs on 8 kHz telephony audio (not clean studio audio) and handles the real-world mess of call-centre traffic — hold music, cross-talk, codec artefacts, caller accents. Deployment is flexible: managed cloud, private VPC, or on-premises for banks that cannot send audio outside their perimeter.

The internal benchmark numbers they publish on their BFSI test set are:

These are their own benchmarks on their own data, so they are not directly comparable to Whisper, AI4Bharat IndicWhisper, Sarvam Saarika or Deepgram Nova on public sets like Kathbath or FLEURS. They are good internal targets, not independent leaderboard numbers. The architecture family is a modern streaming recogniser — Conformer or Zipformer encoders with RNN-T or TDT decoders — because that is the only family that hits sub-300 ms streaming WER at these numbers today.

5. Polaris — the conversational LLM

Polaris is the conversational brain. The marketing describes it as a mixture-of-experts (MoE) model that "activates a subset of experts for each token", which is exactly the standard MoE inference pattern. For complex reasoning turns, the conversation stack can route to a frontier model (Claude, GPT or Gemini class) and even switch models mid-call while preserving context.

Everything below is the most interesting part of this teardown, because Blue Machines has not published a parameter count, a training-token count, a base-model name or a benchmark for Polaris. Compare that to Aurora, which gets four hard WER numbers, and Floe, which gets a latency figure. When a company ships a model, they publish numbers for it. When they ship an adaptation, the numbers get softer.

Is Polaris pretrained from scratch, or a fine-tune?

Short answer: it is almost certainly a fine-tune — or more precisely a post-trained adaptation — of an open mixture-of-experts base. Five reasons stack up and point the same way.

1. The timeline doesn't fit a from-scratch MoE

The company's own origin story (shared by the CTO publicly) is that it began as an internal R&D project "a few months" before the October 2025 launch, with a "small budget" and a small team. A frontier MoE pretraining run — even a modest 20B-active-parameter one — takes six to twelve months on a serious GPU cluster, costs the better part of ten million dollars, and needs a dedicated pretraining team. That is not what the public timeline describes.

2. The parent-company shape is wrong for pretraining

Blue Machines is operationally fused with Apna — same CTO across both companies, same engineering org, legal entity ApnaTime Tech. Apna is a profitable jobs marketplace and recruiter-call platform, not a frontier-model lab. There is no public evidence of an owned GPU cluster at the scale needed. The money and the data advantage sit in Apna's recruiter-call corpus (useful for Aurora, enormous moat), not in a pretraining pipeline.

3. The description is deployment language, not training language

Everything the Polaris page says — MoE routing, subset activation per token, mid-call model switching — describes how the model behaves at inference. Nothing describes how it was trained. For a model you built from scratch, you lead with the pretraining story: dataset size, compute, architecture choices, scaling behaviour. For a model you adapted, you lead with the behaviour. The copy is written like the second case.

4. The frontier-model fallback is a tell

A company that trusted its own LLM to run every turn would not need to route to a frontier model for "complex reasoning". Routing out is a standard pattern for teams running a small-to-mid fine-tuned open model as the default and reserving a Claude or GPT call for the hard turns, where the cost of a frontier call is justified by the stakes. That is exactly the shape Blue Machines describes.

5. The gap in published artifacts

Aurora: four BFSI metrics, deployment modes, latency implied by streaming design. Floe: 11 languages, under 10 ms, specific use case. Polaris: a one-sentence architecture description and a routing diagram. When a company has a real pretrained LLM, they talk about it the way Mistral talks about Mixtral or DeepSeek talks about V3. The silence here is informative.

Most likely base model (ranked)

Treating this as a tiered guess rather than a claim, the open MoE bases Polaris is most likely sitting on are, in rough order of probability as of late 2026:

Single best bet: Qwen3-MoE fine-tuned on Apna's internal Hindi and Hinglish call corpus, aligned on BFSI dialogue, and placed behind Floe for language routing — with a frontier model called in for the complex turns.

BM Zap — the glue nobody talks about

The five models above would not matter if they could not be strung together inside a strict real-time budget. The orchestration layer that does that is called BM Zap. Blue Machines treats it as a product-level piece of IP: it is their in-house low-latency voice framework, the thing that owns VAD, barge-in, turn detection, streaming between stages, interruption handling and call-level state. It is to Blue Machines what LiveKit Agents or Pipecat are to open-source cascaded voice teams.

The reason BM Zap matters more than any single model is the latency arithmetic from Part 7. On a cascaded pipeline, the end-to-end budget is roughly 800 ms to 1.2 s from the caller's last word to the first audible word of the agent's reply. The budget is spent in slices: VAD and turn detection (50 to 150 ms), STT finalisation (100 to 300 ms), LLM first token (150 to 400 ms), TTS first byte (100 to 300 ms), network and jitter (50 to 150 ms). If the orchestration layer is sloppy, the pipeline is slow even with best-in-class models. If the orchestration layer is tight, mid-tier models still feel fast. BM Zap is the bet that disciplined orchestration beats expensive components.

The full pipeline, end to end

Putting it all together, a Blue Machines call flows roughly like this:

• The call lands over SIP from a telephony carrier (Twilio, Plivo, Exotel or a direct carrier connection).
• Answering-machine detection runs in the first second. If it is voicemail, the workflow branches.
• Incoming audio enters BM Zap. Noise cancellation cleans the stream.
• VAD and turn detection decide when the caller has stopped speaking.
• Aurora transcribes the final utterance, streaming where possible.
• Floe reads the recent turn-level context and decides the active language. Its output steers STT, LLM and TTS language choices.
• Polaris generates the response. For a complex turn, the router hands off to a frontier model, carrying the conversation state across the handoff.
• TTS (an in-house or partner voice model, not publicly named) renders the reply in the correct language and voice.
• BM Zap streams the audio back to the carrier, handling barge-in if the caller interrupts.
• The whole call is logged for compliance, QA sampling, and the data flywheel that trains the next Aurora checkpoint.

This is a cascaded pipeline, not a speech-to-speech model. Part 7 covers why cascaded still wins in Indian enterprise voice: 8 kHz telephony neutralises the acoustic advantage of S2S, Indic TTS quality in Realtime is weaker than open models like Veena, observability is a hard requirement for BFSI, and cost per minute matters.

What Blue Machines actually competes on

Taking Polaris out of the equation — because it is probably a well-executed fine-tune, not a differentiator — the real moat sits in three places:

• Aurora. A streaming recogniser pretrained on an unusually clean, India-heavy, BFSI-skewed corpus (Apna's recruiter-call data plus licensed enterprise audio) is a defensible asset. Nobody else in India has quite this training set.
• Floe. The code-mix routing problem is specific to India and under-served by Western voice stacks. Floe is small, cheap and essential.
• BM Zap. The orchestration layer is where most Indian voice-AI startups silently lose the latency race. Owning this layer lets Blue Machines pick a mid-sized fine-tuned LLM and still feel fast.

The weak spot is TTS. The Polaris model page talks about Floe steering TTS, but Blue Machines does not publicly name a TTS model of their own. This is almost certainly where open models like Veena and partner vendors (ElevenLabs, Cartesia, Smallest) show up in the stack. It is also where a competitor with a strong Indic TTS could land a punch.

How it compares to the alternatives

What this tells you if you are building your own voice AI

Three takeaways that generalise beyond Blue Machines:

• Pick your fights. Blue Machines pretrains speech models, not LLMs. For an Indian voice-AI team today, that is the right split: speech is where India-specific data moats exist, and LLMs are a commodity you can rent and fine-tune.
• The router matters more than the model. Floe is a tiny model that unlocks the usefulness of every bigger model behind it. Code-mixing, turn detection and end-of-utterance prediction are the unsexy pieces that decide whether a voice agent feels fast or clumsy.
• Own the orchestrator. Whether you call it BM Zap, LiveKit Agents or your own in-house framework, the layer that owns VAD, barge-in and streaming is the single most important piece of production voice AI. It is also the piece that most teams underinvest in because it does not look like "AI".

FAQ