Asenda Talk
← All posts

Native Twi speech versus a multilingual voice API wrapper: what African teams should evaluate in recognition, synthesis, code-switching and deployment readiness.

5 min read · Published August 31, 2026
Two call center agents focused on customer service, wearing headsets in an office.

Photo by Antoni Shkraba on Pexels

A native Twi speech stack is worth evaluating when Twi is central to the calls your team needs to handle, especially when callers move between Twi and English. A multilingual API wrapper can be a practical starting point, but its quality depends on how well the underlying provider recognizes local speech patterns, preserves meaning through code-switching, and fits your deployment controls.

Start with the calls you actually need to support

Build an evaluation set from real, consented conversations or scripts that reflect your call flow. Include greetings, names, places, numbers, product terms, incomplete sentences, background noise, and callers who change language halfway through a request.

A generic multilingual model may perform well on clean English and still miss the part that matters in Twi: a negation, a name, a payment amount, or a request to stop future calls. Test the language your customers use when they are speaking naturally, not the language your team uses in planning meetings.

Keep the task narrow at first. For a support desk, test account questions, complaint handling, escalation requests, and opt-outs. For an outbound campaign, test consent language, interest signals, callback requests, and refusal handling. The evaluation should measure whether the agent reaches the right next action, not only whether a transcript looks readable.

Test recognition for meaning, not transcript appearance

Speech recognition is often judged by word error rate, but a team running calls needs to know whether recognition changes the decision. A transcript with minor spelling issues may be usable. A transcript that turns a rejection into agreement is not.

Review each test call for:

  • The caller’s intent, including whether the agent identified it correctly.
  • Names, account details, dates, quantities, and phone numbers.
  • Negation and uncertainty, such as “I have not received it” or “I am not sure.”
  • Consent and opt-out language.
  • The point where a caller moves from Twi to English, or back again.

Ask your reviewers to compare the audio, transcript, extracted intent, and resulting agent action. That exposes failures hidden by a transcript that appears broadly correct. For higher-risk use cases, retain the audio reference and a decision audit trail so a disputed call can be investigated later.

The same discipline matters when a caller code-switches. A familiar English product term inside a Twi sentence should not cause the system to discard the surrounding Twi constraint. See Twi and English Code-Switching: Why Voice Agents Must Preserve Context for the operational risk behind that failure.

Listen for synthesis that callers can follow

Text-to-speech evaluation should go beyond asking whether a voice sounds pleasant. Listen for intelligibility, pacing, pronunciation of names and numbers, and whether the voice maintains clear delivery when a script includes both Twi and English.

Use the same script across the options you are comparing. Include a greeting, a short explanation of the call, a confirmation question, amounts or dates if your use case needs them, and an opt-out statement. Have fluent Twi speakers rate what they hear without seeing the original script first. Their ability to repeat the message accurately is more useful than a vague score for “naturalness.”

A native Twi system may offer better control over language-specific pronunciation because its recognition and synthesis are trained for Twi directly. That still needs to be demonstrated in your scripts. A wrapper may be sufficient when Twi usage is limited, the call flow is simple, and your team can accept the quality and coverage shown in testing.

Make code-switching a release gate

Code-switching is a normal part of many conversations. Treat it as a deployment requirement, not an edge case.

Test cases should include a caller beginning in Twi, inserting English product or technical terms, then returning to Twi to clarify a condition. Also test the reverse. The agent should retain the caller’s prior constraint, language preference, and intent across the switch.

For example, if a caller agrees to receive information but asks for it tomorrow, the agent must preserve both parts of the request after the language changes. An English-language confirmation that drops the timing constraint creates a wrong follow-up.

Review the full call record, not only the final transcript. Your team should be able to connect audio, transcript events, agent decisions, and telephony lifecycle events. This is particularly important for consent disputes and opt-out complaints. What Evidence Do You Need Before Calling Again After a Twi Opt-Out Complaint? outlines the evidence worth retaining before another call is attempted.

Check the deployment path before choosing a model

Speech quality does not decide deployment readiness on its own. Confirm how calls are started, stopped, logged, billed, and reviewed.

For each provider or platform, verify:

  • Where speech audio and transcripts are processed and stored.
  • How consent, opt-outs, and audit records are captured per call.
  • Whether secrets are masked, write-only where appropriate, and separated by environment.
  • How telephony webhooks report ringing, answer, completion, failure, and other lifecycle events.
  • Who can enable real-money usage and what controls exist before minutes are charged.
  • What happens when recognition confidence is low or the agent cannot safely continue.

Asenda Talk currently provides native, in-house fine-tuned Twi recognition and synthesis, configurable voice agents, call-truth tracking through a telephony webhook pipeline, consent and audit records, and controlled metered billing. Its assistant runtime is Vapi-orchestrated. It remains in early access, and outbound calling is gated behind an explicit telephony-provider decision that is not yet live. Plan any pilot around the capabilities available at the time of testing.

Run a short, scored pilot

Choose one call type, define the allowed outcomes, and prepare a Twi-English test set before committing to a provider. Score recognition accuracy, synthesis intelligibility, code-switching context retention, correct next action, auditability, and operator controls.

Do not launch because a demo sounds convincing. Launch the smallest controlled pilot only after fluent reviewers can trace each tested call from audio to outcome and your team has a clear escalation path for low-confidence or sensitive conversations.

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.