Cekura enables Conversational AI teams to automate QA across the entire agent lifecycle—from pre-production simulation and evaluation to monitoring of production calls. We also support seamless integration into CI/CD pipelines, ensuring consistent quality and reliability at every stage of development and deployment.
This is the 4th launch from Cekura. View more
Cekura
Launching today
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.
Free Options
Launch Team
Cekura
Hey Product Hunt!
Sidhant here, co-founder of Cekura
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 here
Refocus
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.
Cekura
@igorgurovich 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.
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
@hazy0 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.
the loop-closing part is the interesting claim. the failure mode i would worry about is the simulator quietly becoming the thing you optimise against, so the agent gets very good at passing your scenario set and no better in production.
we run agents against third-party systems we do not control, and the split that ended up mattering most was "the agent did the right thing" versus "the other side actually accepted it". those two look identical in a transcript and come apart constantly in practice.
curious how the regression sweep decides a fix generalised rather than fit the scenarios. is the held-out set drawn from real production calls, or generated the same way the training scenarios were?
Cekura
@whateverneveranywhere That’s exactly the failure mode we guard against. We separate “the agent attempted the right action” from “the external system accepted it” using provider state, tool results, and outcome signals—not transcripts alone.
The regression sweep includes the full validation set plus happy/edge cases, with overfitting checks for scenario-specific fixes. Production-derived held-out cases are the strongest validation.
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.
Cekura
@almuddin_ansari Totally agree. We test interruptions, background noise, long pauses and unexpected responses, not just clean scripted conversations.
Cekura
@almuddin_ansari 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: https://docs.cekura.ai/documentation/key-concepts/evaluators/conditional-actions
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.
Cekura
@peter_victor Completely agree. We trace the full conversation to find where behavior first diverged, rather than patching only the final symptom.
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.
Cekura
@kimberly_west 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