A completed call only proves the connection ended normally. To know whether the request survived a Twi-to-English switch, the support team must compare the transcript, captured fields, call events, and final record across both languages.
At 4:38 p.m. in Accra, Ama Mensah, a composite support lead with cold tea beside her keyboard, opens the first mixed-language call from the afternoon test queue. The customer begins in Twi, explains the reason for calling, then switches to English while giving the final instruction.
The dashboard shows “completed.” No provider error. No failed webhook. Nothing red.
But the saved request contains only the English instruction. The reason given in Twi has disappeared.
If Ama approves the test based on call status alone, the support desk could act on an incomplete request. The customer may receive the wrong response, and the team would have no obvious technical failure telling them where the meaning was lost.
A successful call can still produce a failed record
Voice systems create several versions of what happened. There is the audio the customer produced, the speech recognition output, the conversation state available to the agent, the structured fields saved during the call, and the final record sent to another system.
Those versions can disagree while the call remains technically healthy.
Ama listens again. In Twi, the customer gives the context that determines how the request should be handled. In English, the customer confirms what should happen next. Each part makes sense on its own, but the final instruction depends on the earlier explanation.
This is the practical risk in code-switching. A language change may look like a clean boundary to a system even when the speaker intends one continuous thought. If context resets, weakens, or gets summarized at that boundary, the request that reaches the support desk can be grammatical and incomplete.
The wider issue is explored in Twi and English Code-Switching: Why Voice Agents Must Preserve Context. For Ama, the immediate lesson is smaller and more urgent: “completed” cannot be the only definition of success.
Trace meaning across the language switch
Ama needs to reconstruct the call without guessing. She checks the original language turns, the English turns, the agent’s responses, the extracted request, and the lifecycle events recorded from connection through completion.
The telephony events answer one question: did the call progress through the expected stages?
The transcript answers another: what words did the system recognize?
The conversation state and saved fields answer the question that matters most to the support desk: did the meaning carry through?
Asenda Talk is being built for this kind of review. Its Twi speech recognition and synthesis are fine-tuned in-house rather than passed through a generic third-party speech wrapper. The platform also records telephony lifecycle events, consent, opt-out state, and an audit trail for each call. Vapi orchestrates the assistant runtime.
Those components give an operator evidence to inspect. They do not make every mixed-language request correct by default. Native Twi handling must still be evaluated against realistic conversations, especially when a customer introduces the request in one language and completes it in another.
That distinction matters in early access. A platform can capture the audio, produce plausible text, and close the call while still mishandling the relationship between two turns. The review process must test continuity of meaning, not fluency alone.
Treat disagreement as a launch gate
Ama finds the turn where the record breaks. The Twi context appears in the transcript, but the structured request created after the English switch omits it. That narrows the investigation. Speech recognition captured the earlier statement; the downstream state did not preserve enough of it.
Now she has something actionable. The call should fail the evaluation even though its lifecycle status remains completed.
A useful mixed-language test should require the reviewer to answer four concrete questions:
- Can the reviewer see what the caller said before and after the switch?
- Does the agent respond as though both parts belong to one request?
- Does the final structured record preserve the facts supplied in both languages?
- Can the team trace any disagreement back to a specific turn or event?
If one answer is no, the team should hold the affected workflow. That is particularly important for outbound calling, where a plausible but incomplete record can trigger another action. Asenda Talk keeps real-money calling behind an operator-controlled gate, and live outbound calling remains gated while the telephony-provider decision is unresolved.
A normal completion signal should never override that uncertainty.
The same evidence standard applies when the disputed detail is consent or an opt-out. A generated summary cannot replace the underlying record, as discussed in Opt-Out Complaint Review: Why Source Records, Not AI Summaries, Are Proof.
Build the test around one continuous request
Before the next review, Ama rewrites the test case. The caller must begin the reason in Twi, switch to English for the requested action, and refer back to a fact stated only before the switch. Passing requires more than a natural reply. The final record must retain that earlier fact, and the audit trail must let Ama verify where it came from.
She also keeps the expected result beside the transcript instead of relying on memory. That turns an impression such as “the conversation sounded fine” into a comparison the team can repeat after each change to recognition, prompting, orchestration, or field extraction.
At 5:12 p.m., Ama marks the call complete at the telephony layer and failed at the request layer. The distinction keeps the test honest.
The cold tea is still there. So is the missing Twi context, now attached to a precise turn, a failed acceptance condition, and a reason the workflow stays gated until the record matches the request.
Comments
No comments yet.