Asenda Talk
A cheerful call center agent talking on the phone with a headset.

Photo by Yan Krukau on Pexels

The first routine bilingual call should test whether verification, consent, troubleshooting context, and call records survive a switch from English to Twi. A natural voice matters, but continuity determines whether the agent can finish the job safely.

In April 1970, Apollo 13’s crew faced rising carbon dioxide inside the spacecraft. The command module’s square lithium hydroxide canisters would not fit the lunar module’s round openings. NASA engineers in Houston had to devise an adapter using materials available aboard the spacecraft, then relay instructions to astronauts Jim Lovell, Jack Swigert, and Fred Haise before the air became unsafe.

The mechanism is documented in Jim Lovell and Jeffrey Kluger’s book Lost Moon. It offers a useful analogy for bilingual voice support: two capable systems can still fail at the point where one format must carry essential information into another.

The call begins in English

Imagine the first routine support call at 9:07 AM. The caller answers in English. The Asenda Talk agent delivers its configured first message, identifies the purpose of the call, and completes the required verification steps.

The interaction is ordinary by design. That is useful. Routine calls reveal whether the underlying controls work without the distraction of a dramatic edge case.

The agent records consent. It follows the configured persona and voice. The telephony lifecycle pipeline receives the call events needed for call-truth tracking. If the caller opts out, that choice must enter the audit trail and affect what happens next.

Then troubleshooting begins.

The agent asks the standard questions in English. The caller gives short answers, but the issue remains unresolved. A repeated prompt does not help. The caller switches to Twi to describe what happened in the words that come most naturally.

That switch is the real test.

Twi must carry the existing context

Asenda Talk uses native Twi speech recognition and synthesis fine-tuned in-house. It does not depend on a generic third-party Twi voice wrapper. That technical choice is important because the difficult part of a support call often contains the most specific language: the sequence of events, the caller’s correction, or the detail that separates one problem from another.

Recognition quality alone cannot preserve the call.

The agent must retain what it already established in English. It should not ask the caller to verify the same identity again without a policy reason. It should not lose the consent state. It should know which troubleshooting steps have already failed and continue from that point in Twi.

This is the adapter problem from Apollo 13 in a different setting. English and Twi can each work well on their own. The operational risk sits at the boundary, where identity, intent, prior answers, and policy state must pass from one language context into the next.

A polished Twi response that forgets the English verification produces a fluent but broken call. The same applies if the transcript preserves the words while the audit trail loses when consent was given or when an opt-out occurred.

For a closer look at that boundary, see What Happens When the Hardest Part of a Support Call Switches to Twi?.

Call truth matters after the voice stops

The caller eventually explains the failed step in Twi. The agent responds in Twi, confirms the relevant detail, and either proceeds with the configured workflow or records that the issue needs human attention.

The review should not stop with the audio.

A credible test checks the event sequence across the whole call: when it started, whether it connected, what consent state was recorded, when the language changed, which troubleshooting steps ran, how the call ended, and whether billing reflects the verified duration. Those records matter when a support manager in Accra investigates a complaint or tries to understand why a workflow failed.

Asenda Talk has a telephony lifecycle webhook pipeline with call-truth tracking, metered per-minute billing, and an operator-controlled real-money gate. It also keeps consent, opt-out, and audit records for every call. Those controls make the routine call inspectable.

They do not make paid outbound calling live by default. Asenda Talk remains in active early access, and outbound calling is gated behind an explicit telephony-provider decision that has not yet been made live. Teams can build and evaluate agents now, but they should not treat provider approval or production outbound availability as complete.

That distinction protects the same boundary NASA engineers had to respect in 1970: the design on the ground must match the system that will actually carry it.

Define the test before 9:07 AM

Before evaluating a bilingual support agent, write down what must remain true across the language switch.

Use a deterministic caller scenario. Specify the verification result, the consent state, the English troubleshooting steps, the point where the caller changes to Twi, and the detail the agent must preserve. Then inspect the transcript, lifecycle events, audit trail, and metered duration against that script.

Include failure conditions. Stop the test if the agent loses consent state, repeats verification without cause, restarts troubleshooting, misrecords an opt-out, or reports a call outcome that conflicts with provider events.

Apollo 13’s improvised adapter worked because the team designed for the materials and openings that existed aboard the spacecraft. A bilingual voice agent needs the same discipline. Test the connection between languages, records, and controls before the first paid call is allowed through the gate.

Asenda Talk

A self-serve platform for building and running voice AI agents, built on native African-language speech (Twi, with more languages in progress) instead of a wrapper around a third-party voice API.

Try Asenda Talk

Comments

No comments yet.