Venky B is a co-founder of Plivo, the communications company he built with Michael Ricordeau. Also identified in the supplied sources as Venky Balasubramanian, he was named Plivo’s co-founder and CEO in 2022 and is credited with a Plivo affiliation in his recorded voice-agent talk. His work has developed from programmable telephony into voice AI, with a recurring concern: giving developers control over the mechanisms that make customer conversations reliable.
Early work and lessons from customers
Before founding Plivo, Balasubramanian worked at Subex, Narus Networks, and Huawei Technologies, moving through software development, sales engineering, and solutions consulting. In his account of that period, difficulties calling home while traveling in Latin America motivated a prototype for inexpensive international calls that did not depend on a reliable internet connection. He then explored whether the approach could serve businesses.
His career also included a brief departure from technology to run a small dumpling outlet in Ahmedabad. He later connected that experience to product development: customers judged whether an offering met their needs, and adapting it mattered more than preserving its original form. That lesson became relevant when developers wanted more from Plivo than application code.
Building Plivo and funding its growth
Balasubramanian met Ricordeau through GitHub in 2011, when both were developing telephony applications. Together they produced the Plivo open-source framework, released that May. Built with Python, gevent, Flask, and FreeSWITCH, it let developers create calling applications while selecting their own carriers and hosting. Familiar web-development tools made telephony easier to program without removing control of the infrastructure underneath it.
Customers also wanted the founders to manage cloud hosting and carrier relationships. That demand led Plivo toward a hosted voice and SMS platform. Following an initial rejection, the company entered Y Combinator’s summer 2012 batch and launched its cloud service that July. In his August 2021 essay on financing the business, Balasubramanian described roughly $2 million in early funding followed by nine years of revenue-funded growth. His preference for capital-efficient growth tied spending to profitability, customer retention, and expansion: customers whose applications grew also consumed more communications services.
From communications infrastructure to voice agents
Plivo subsequently moved further into customer-service applications. Its October 2021 launch of Contacto combined communication channels, automated qualification, and handoffs to human representatives for businesses unable to assemble a customized call center themselves. In his later voice-agent talk, Balasubramanian described another extension of the business: programmable agents and a visual agent builder running above Plivo’s existing SIP trunking, audio streaming, and carrier infrastructure. He distinguished that offering’s speech-recognition, language-model, and speech-synthesis pipeline from a native speech-to-speech model.
Engineering reliable telephone conversations
His engineering advice addresses the failures that appear when a fluent demonstration becomes a real telephone conversation. A caller may wait too long for a response, give a name the recognizer cannot spell, or request an appointment whose time remains ambiguous. Each problem requires a mechanism that engineers can inspect and test.
Response latency: For latency, he weighs cost, capability, and response time together. Extended model reasoning can delay a spoken reply beyond what a caller will tolerate. He describes smaller, self-hosted open models as an option where their instruction following and tool use meet the task’s requirements, while recognizing the hosting burden and the difficulty of fine-tuning mixture-of-experts models. He also discusses using a smaller conversational model alongside a larger tool-calling model. For multilingual agents, token throughput alone is insufficient: a model that needs more tokens to express each word can take longer to produce useful speech.
Transcription reliability: He assumes transcription will be unreliable around proper names, specialized vocabulary, phone numbers, accents, and language switching. Dynamic keyword boosting supplies recognition hints for the current task rather than keeping every possible keyword active throughout the call; excessive hints can introduce mistaken recognitions. Contextual cleanup can then repair likely substitutions, while transliteration and script normalization prevent inconsistent text from spreading into the language model and speech synthesizer.
Validated data collection: His most developed argument treats caller-data collection as interface design. Engineers should define typed, validated fields before asking questions. A phone-number field supplies digit and length constraints; an apparent letter among its digits should trigger confirmation or a request to repeat. An unfamiliar name may require letter-by-letter spelling. “Next Wednesday at eight” requires a reference date and clarification about morning or evening. Tool calls and validation rules turn these requests into constrained collection tasks. Field-level evaluations then test each task independently, making it possible to find a broken field without repeatedly testing an entire conversation. Clear states, confirmation, and recovery reduce dependence on repeated prompt adjustments.
Speech preparation: He applies the same discipline to outgoing speech. A speech-output normalization layer removes Markdown and emojis, prepares emails, dates, currencies, and phone numbers for reading aloud, and supplies pronunciation rules for names, brands, and acronyms. Slowing delivery around an important entity can help a caller understand it. He uses his own surname and Plivo’s name as pronunciation checks and argues that customer-facing products should give users similar controls. Keeping these transformations in the application makes their behavior less dependent on which speech provider performs synthesis.
Balasubramanian briefly addresses turn detection, interruptions, and backchanneling at the talk’s close, but develops latency, transcription, data collection, and speech preparation in greater depth. Across those areas, his emphasis is concrete: an agent must capture the right information and communicate it intelligibly through the imperfect conditions of a real call.
Venky B of Plivo explains why a working voice demo can fail on a real call, and how model selection, transcript cleanup, typed fields, speech normalization and conversation timing change the result.
Optimize time to first audio across the complete response path. Fast token throughput and a good median model latency can still leave callers waiting.
Venky reports a 2.5–3× multilingual token-fertility advantage for Gemma 4 over Qwen 3.5 in his team's evaluations. Fewer tokens per word can improve word-generation speed; the reported comparison does not establish a reproducible advantage for unspecified checkpoints or workloads.
Use call state to narrow recognition and interpretation: boost relevant keywords dynamically, clean transcripts with context and normalize multilingual scripts.
Define typed fields before collecting data. Validation should turn suspicious input into confirmation or repetition, and field-level evaluations should identify which collection behavior fails.
Turn detection, barge-in and backchanneling remain separate engineering concerns. A modular pipeline can support them without requiring a dedicated speech-to-speech model.
▶ Watch ↗