Cekura - The self-improvement loop for voice agents

Cekura is the testing, observability, and self-improvement platform for production voice and chat AI agents. It simulates thousands of scenarios, catches failures, diagnoses the root cause, rewrites prompts and config, then re-validates with a full regression sweep. Unlike tools that hand failures back to your team, Cekura closes the loop by fixing the agent itself and proving the fix holds without overfitting.

Add a comment

Replies

Best

Hey Product Hunt!

Sidhant here, co-founder of

Today we are launching self-improving loops for voice agents.

Fixing a voice agent has always been fragmented. Your testing tool tells you what failed, you diagnose it from transcripts, patch the prompt, re-run, and something else breaks. The tools find problems, but the fixing has always been a human walking between them.

Cekura collapses that loop. It runs thousands of simulated calls and groups every failure, explained in plain English. Optimise agent hands them to the Cekura Agent, or any coding agent you use, Claude Code, Codex, anything. It reproduces each failure, makes the change, and reruns until everything passes, then verifies nothing else broke. You review the diff.

Two rules: it must reproduce a bug before fixing it, and every fix is proven on simulated calls on a clone, never your live agent.

Free for everyone to try, starting today. We are in the comments all day. If you want to chat more, please feel free to book time

Root cause diagnosis for voice agents is genuinely hard because failures compound across turns. If it traces that accurately, that alone is worth the pitch.

 Completely agree. We trace the full conversation to find where behavior first diverged, rather than patching only the final symptom.

I've been burned by agents that pass QA and fail in production because the test scenarios were too clean. Genuinely curious how realistic it's simulated conversations sound.

 Totally agree. We test interruptions, background noise, long pauses and unexpected responses, not just clean scripted conversations.

 Great question , our simulated conversations use Conditional Actions, so the testing agent reacts dynamically to what the agent actually says (branching, interruptions, background noise, live data), not a fixed script. Please do check out our docs for more:

How does Vocera handle accuracy and context when conversations get more complex or users have different speaking styles? Congrats & team!

 Thank you! Cekura tests agents across varied scenarios, speaking styles, interruptions, and multi-turn context—not just isolated turns. It also preserves conversation history and evaluates whether the agent completed the intended outcome, so accuracy holds up as interactions get more complex.

 Our evaluators are written against intent, not exact wording — conditions like "the agent asks for your name" match semantically regardless of how a specific agent phrases it, and grading runs over the full conversation using LLM/rubric-based judging rather than pattern matching. So the same test generalizes across agents with different tones, styles, or conversational complexity, without needing to be rewritten per agent.

Voice agents are unforgiving compared to chat, a bad pause or mistimed interruption sticks out immediately. I appreciate that it treats voice and chat as needing the same rigor rather than bolting voice support onto a chat-first tool.

 Thanks! That's basically what we built Cekura for.

Cekura doesn't answer the calls, it stress tests the agent that does. We generate personas that talk like real users: different accents, interruptions, mumbled order numbers, background noise, code switching mid sentence.

And we score full conversations, not single turns. Did the agent hold state after a topic switch? Did it recover from mishearing something on turn 3?

When it fails, you get the root cause and the fix passed to your coding agent, not just a red flag on a dashboard.

  This is the exact thing we refused to compromise on. The moment you evaluate a voice agent by reading its transcript, you've deleted the dimension where it actually fails — timing, barge-in, overlapping speech. So voice is tested at the audio layer, not as chat with extra steps. Appreciate you calling it out.

Love what you and the Cekura crew are building! This is truly solving the problem end to end. I got struck on this loop even for a simple voice agent I built with ElevenLabs for my personal website. So getting this solved for mission critical voice agents is a game changer! Rooting for you guys :)

 Thanks for your encouraging comment. Means the world to us. If you get a chance do try cekura for your agent at

What stands out to me is the regression sweep after every fix. I've seen too many "self-healing" tools introduce new bugs while patching old ones. Curious how it measures whether a fix actually generalizes across edge cases.

 Great question. Every fix passes through an Overfitting Gate first to catch issue-specific or overly narrow fixes, then gets re-validated with a full regression sweep across the evaluator set

The rule that a bug has to be reproduced before it gets fixed, and validated on a clone instead of the live agent, is the part that stands out to me. I build a voice companion that calls aging parents daily, and my worst fear is a silent regression in an emotionally sensitive call that nobody catches until it actually matters. How do you generate realistic edge cases for messy real speech (long pauses, hearing loss, someone talking over the agent) versus clean synthetic voices? That gap is where most of our failures hide.

 That's exactly the gap we designed for. Our simulations use Conditional Actions to reproduce real pauses, mid-sentence interruptions, and real-voice recordings, not just clean TTS , along with personalities for speaking pace and background noise. That's where messy-speech edge cases get caught before production.

Reading this made me think about how much time my team spends manually reproducing a bad call just to figure out what went wrong. Automating that alone would be huge.

 Couldn't agree more. Hunting down logs to replay a bad call takes way too much time. Automating that reproduction and root-cause diagnosis was step one for us. Really appreciate the support!

The rule that a fix has to be reproduced and validated on a clone before touching the live agent is the right engineering call for anything running in production customer support. The part I want to understand is the CI/CD integration: when a new prompt version or agent config gets committed, does Cekura run the regression suite automatically as a pipeline step that can block a deploy, or is the test run still something the team triggers manually? That boundary between an automated gate and a manual check is usually where teams cut corners under deadline pressure.

 Cekura evals can run as a step in your CI/CD pipeline via our GitHub Actions integration. We also provide a curated Infrastructure Suite that we recommend adding to that pipeline for infra regression checks.

123
•••
Next