Sumanyu Sharma

Sumanyu Sharma is co-founder and chief executive of Hamming AI, which builds automated testing and production monitoring for conversational voice agents. His work addresses a practical reliability problem: an agent can sound natural and confident while giving incorrect information, skipping verification, or promising an action it never completes.

From medical-image retrieval to production machine learning

Sharma studied engineering at the University of Waterloo, where he worked on medical-image retrieval. He was first author of a 2016 paper on stacked autoencoders, collaborating with Imaad Umar, Laura Ospina, Davin Wong, and Hamid Tizhoosh. The team encoded X-rays as binary vectors so a query image could retrieve visually similar images. Waterloo’s medical-image-search capstone record also identifies Sharma and his student collaborators.

His subsequent work brought him closer to the problems of operating machine learning in real settings. At Virtual Power Systems, he worked on data-center simulations. At Tesla, where he became a senior staff data scientist, he developed machine-learning systems for its sales program and encountered failures that uptime monitoring could miss: models continued producing plausible scores even as degraded inputs undermined their decisions. In his account of Hamming’s development, he connects these experiences to simulation and the need to inspect more than whether a system remains online.

Sharma later served as head of data at Citizen, the public-safety app. Its audio pipeline had to make sense of police-radio recordings containing static, sirens, overlapping speakers, regional accents, and specialized dispatch language. The team combined automated processing with human verification before distributing alerts. In his AI Engineer talk, he describes listening to thousands of hours of police-radio audio and sending millions of alerts as collective work at Citizen.

Founding Hamming and focusing on voice agents

Sharma co-founded Hamming with Marius Buleandra, a former Citizen colleague. Their initial focus was evaluation for prompts and language-model pipelines. Voice-agent builders revealed a more specific need: they repeatedly called their own agents, found bugs, changed prompts or function definitions, and called again to see whether the changes worked or introduced new failures.

The founders launched automated voice-agent testing in August 2024, during Hamming’s Y Combinator Summer 2024 batch. Their approach used simulated callers to pursue realistic goals while introducing difficult conversational behavior. Drive-through ordering illustrated why clean speech recognition was insufficient: an agent also had to handle allergies, dietary restrictions, distractions, and customers changing their minds. Hamming announced a $3.8 million seed round led by Mischief that December to support automated voice testing and production monitoring.

Finding and prioritizing voice-agent failures

• Turn-by-turn diagnosis: Hamming’s turn-by-turn instrumentation connects audio, transcription, response timing, and interruptions so engineers can distinguish reasoning errors from speech-recognition and conversational-timing problems. A transcript can preserve the words while obscuring the moment an interruption caused the agent to lose the thread. Understanding that mechanism gives a team something more useful to repair than a failed-call label.
• Cross-conversation analysis: Sharma’s reliability framework combines failure discovery, testing, and production monitoring. He recommends starting by listening to calls manually: individual conversations give engineers the context and intuition needed to define useful evaluations. Fixed rubrics can then track known problems, such as latency, interruptions, verification, and task completion. But those checks cannot anticipate every emerging behavior. His emphasis on cross-conversation analysis is about finding patterns that become visible across many calls rather than within one interaction.
• Frequency and severity: He prioritizes failures by frequency and severity. Repetition may be a minor annoyance in one call but a persistent product problem across a deployment. An agent failing to freeze a credit card has more serious consequences. Systematic, high-impact failures deserve the highest priority, while recurring annoyances still matter to the quality of the service. His personal example is an appointment he believed he had booked: he arrived at the physician’s office and discovered he was absent from the schedule. He uses it to explain how the same failure could carry greater costs for someone seeking a procedure or facing more difficult circumstances.

Validating repairs and monitoring risk

Testing a repair requires more than replaying that failed conversation once. Sharma recommends repeated runs to expose inconsistent outcomes, then preserving the caller’s intent while varying wording, accent, speaking style, and additional requests. Those variations test whether a fix generalizes beyond the original example. Regression checks ask whether it has damaged another part of the experience. He also recognizes simulation’s limits: the opening words and vocal quality of an outbound call may need A/B testing with real users because synthetic conversations cannot establish how people will respond.

His concern about voice-agent safety centers on the reach of shared software. A single prompt or architecture change can affect many users, spreading the same weakness across a deployment. Giving agents access to more data and tools also creates more opportunities for adversarial callers to bypass verification or obtain information they should not receive. Sharma describes Hamming’s red-teaming work as finding such failures and advocates continuous red teaming when bad interactions could have substantial consequences. His recommended monitoring examines both what agents do and whether callers are trying to manipulate them.

Sharma sees voice interfaces as a way to replace rigid telephone menus and long hold queues with more natural service. Making that useful depends on a continuing cycle: discover failures, assess their consequences, repair them, test the changes, check for regressions, and monitor what happens when users call.