Testing a voice agent requires more than reading the prompt
A call combines speech recognition, language understanding, workflow state, external systems, telephony, and audio playback. A change that looks harmless in configuration can fail only when those layers interact. That is why production voice automation needs a layered test process rather than a single “try it once” demo call.
Start with isolated agent behavior
Cally provides an in-browser voice test and a text playground. Use the text mode to move quickly through many conversational variations and the voice mode to test turn-taking, pronunciation, interruptions, and pacing. The goal is to find language problems before telephony and workflow variables are added.
Then simulate the workflow graph
The orchestration studio includes routing dry runs that let teams step through graph logic with mock caller inputs and JSON scenarios without placing a phone call. This is where you test branch conditions, required fields, confirmation paths, business-hours behavior, suppression checks, and handoff decisions. A good suite should include expected paths and deliberately malformed inputs.
Test every integration separately
Use the action test bench to validate external API calls with known values. Confirm authentication, request schemas, response mapping, and timeout behavior before the action is exposed to a live agent. For SIP setups, connectivity probes and controlled inbound routing tests should be performed before a public number is assigned to the workflow.
Publish like software
Cally’s versioned graph deployment and agent version capture make it possible to treat changes as releases. Keep a small regression set: ten representative calls, five edge cases, and two failure scenarios that must pass before each deployment. The exact number can change, but the discipline should not.
The cheapest call to debug is the one that never reached a customer. Build simulation into the release process, not into the postmortem.