Run Cekura evaluators and read results from a Sazabi thread

Last verified on Nov 8, 2026.

Voice and chat agents fail in ways a health check cannot see. The service is up, the call connects, and the agent still gives a wrong answer, skips a confirmation step, or loops. Cekura tests those behaviors by running simulated conversations against your agent and scoring them with metrics.

The Cekura connector puts that testing loop next to your service logs. The Sazabi agent, part of Sazabi's AI-native observability and security platform, can run an evaluator after a deploy, read the result, and then check your backend logs for what the failing runs hit.

What the Sazabi agent can do with Cekura

Sazabi stores your Cekura API key and sends it as the X-CEKURA-API-KEY header to Cekura's hosted MCP server. Cekura's docs describe what an assistant can do through it: list agents, create metrics, generate evaluators, run tests, inspect transcripts and analyze results. Sazabi's page summarizes the same set as running evaluations, retrieving results and run history, triggering on-demand checks, and browsing workflow definitions and test case libraries.

Two details from Cekura's reference matter in practice:

• scenarios_run starts a run over any connection type. You pass a transport such as voice, sip, text, email, websocket or one of the platform-specific values, with the evaluators and the fields that transport needs. The per-transport tools, such as scenarios_run_text, still work.
• An agent's enabled_connections lists the transports it can run over. A transport that is not enabled is rejected with that list, so the agent should read the agent first.

Because starting a run uses your Cekura account, you may prefer a read-only connection for investigation and a separate one for people who run tests.

Questions it answers

• Did the evaluators for this agent pass after the last deploy?
• Which runs in the latest result failed their metrics, and what did the transcript show?
• Is the failure a flaky run or a repeatable one?
• Which transports can this agent be tested over?
• Which error in the backend logs lines up with the failing run?

A worked example: a regression after a prompt change

A scheduling voice agent was updated at 15

The booking agent changed at 15:00 UTC. In Cekura, check the booking agent's
enabled_connections, then run the regression evaluators over text with
scenarios_run. When the result finishes, tell me success_runs_count,
failed_runs_count and success_rate, and read the transcript of one failed run.

The agent calls Cekura to retrieve the agent and its enabled_connections, which tells it whether text is allowed. It then calls scenarios_run with transport set to text, a cheaper simulation than live voice. It polls until the result reaches a terminal status, and this is where Cekura's own warning applies: a completed result only means the runs ended, so the agent reads success_runs_count, failed_runs_count and success_rate for the verdict and opens a failed run's transcript.

With the transcript in hand, the agent searches call-router logs for the same time window. If the failing run asked for a slot and the calendar call timed out, the cause is in the backend, and the prompt change is not to blame. If the calendar call succeeded and the agent still booked the wrong time, the prompt change is the lead. Either way you have a run to show, and a text-only result does not prove that voice behaves the same way, so rerun the failing evaluator over voice before closing the incident.

How it fits with other integrations

Cekura tests an agent before and after changes. For production runs, The Context Company and Langfuse cover agent behavior, and Cekura lists ElevenLabs among the voice platforms it connects to. Cekura also documents CI workflows, which pair with the GitHub page, and the AI frameworks category lists related tools. The integrations index shows every method.