Rubricon is a product company working on one problem: phone conversations that a machine can hold, and a measurement layer honest enough that a business will let it. Both halves are ours, because the second is what makes the first deployable.
Founded. Building on voice and call-quality systems shipped into production before it.
Haryana, India. Built for Indian call volumes first; deployments run in the customer's region.
No outside capital. Revenue-funded from customer deployments.
Product line. Voice, and the scoring that makes it deployable — no general software work alongside it.
Getting a voice agent to sound good in a demo is now the easy part. The place deployments stop is the review meeting: an operations head is asked to put a machine on live customers and has no way to answer what it will do on the calls nobody watched.
The honest answer to that question is a measurement, on the buyer's own definition of a good call, over all of the calls rather than a sample. That is a product in its own right — it is worth running on a human team before there is any agent at all — so we built it first and built the agent behind it.
It also fixes the incentive. A vendor that ships only the agent has no reason to surface its failures. When the same rubric grades our agent and your people, and your supervisors can overturn any score, our failures land in your dashboard by default.
That constraint decides most of what is on this site: bounded call types rather than a general assistant, ground truth before scores are shown, budgets published as budgets, and a measured number reported per deployment instead of a benchmark printed on a home page.
India is where we start, and not only because we are here. An Indian queue switches language inside a sentence, which is the case general speech systems handle worst — so it is at once the market we can reach and the problem where being close to the audio is worth the most.
A live call is latency-critical, stateful for its duration and bursty with call volume. Scoring a back catalogue is throughput-critical, embarrassingly parallel and spiky at onboarding. They share storage and the rubric, and almost nothing else.
The call arrives on the customer's own trunk. Rubricon terminates one leg and keeps a persistent media socket for the duration.
The latency-critical path. Every stage streams; a call holds a session for its whole duration, so capacity scales with concurrent calls rather than requests.
Conversation state, tool calls, retrieval and the escalation rules. Runs as containers autoscaled against concurrent-call count, with a warm floor because a cold start inside a phone call is not recoverable.
Asynchronous and queue-driven. Diarisation, transcription and rubric grading run per call; onboarding a customer means scoring months of back catalogue at once, which is the largest single compute spike we handle.
Audio, transcripts, rubric versions, scores, overrides and the tool-call audit trail. Region-pinned to wherever the customer's calls are made.
Per-turn latency telemetry is a product surface, not just an internal metric — the measured distribution is what we report to the customer instead of a headline number.
They carry names, addresses, payment references and health or financial detail, in a form that cannot be redacted before it is captured. The handling rules follow from that.
Electrical engineering at IIT Delhi. Previously founded Silversparro, where he built computer-vision and speech systems running in manufacturing plants and contact centres, and led engineering teams at scale afterwards. Writes the real-time pipeline.
LinkedIn ↗Send them before the first call if that is easier — residency, retention, sub-processors, the DPA. We would rather answer them up front than at the pilot.
