A working Asenda Talk persona takes shape by setting its role, first message, and voice, then testing how those choices hold up in Twi and English. The agent can be configured this afternoon; live outbound calling remains gated until a telephony provider decision is approved and made live.
In April 1970, the Apollo 13 crew faced a carbon-dioxide problem after an explosion changed the mission. The lunar module had lithium hydroxide canisters designed for two astronauts, while James Lovell, Jack Swigert, and Fred Haise needed it to support three. Engineers in Houston had to adapt square command-module canisters to round lunar-module fittings using only materials available on the spacecraft. NASA’s Apollo 13 Flight Journal records the improvised solution and the test of whether it would work.
That is a useful shape for a Thursday build. The job is rarely “make an agent sound intelligent.” The job is to assemble a small set of choices that work together under real constraints: what the agent is responsible for, how it opens, which voice carries the conversation, which language the caller uses, and what the system can honestly do today.
Start with a persona narrow enough to test
Begin with one job the agent can complete or hand off clearly. “Customer support agent” is too wide for an afternoon build. “Confirm a delivery detail, repeat it back, and route unresolved cases to a human” gives the persona boundaries.
Write the persona in plain operational language. Include what the agent should collect, what it must confirm, when it should stop, and when it should decline to guess. If the agent handles Twi and English, state that directly. Do not leave language switching as an implied capability that only appears once a caller changes mid-sentence.
A useful first version might tell the agent to greet the caller, explain the purpose of the conversation, confirm consent where applicable, collect one account or delivery detail, repeat the detail back, and record an opt-out when requested. That is enough surface area to expose problems without trying to model an entire support desk.
The point is not to produce a polished script. It is to make the first test falsifiable. You should be able to say where the persona succeeded, where it became vague, and which instruction caused the failure.
Write the first message as the first operational decision
The first message sets the pace and tells the caller what kind of interaction they have entered. It should identify the agent’s purpose, use a natural opening for the audience, and leave room for a reply.
For a Ghanaian support workflow, a short Twi or English greeting may be more useful than an elaborate introduction. The right wording depends on the task, but the test is consistent: can a caller understand why the agent has called or answered, what they can do next, and how to opt out?
Keep the opening short enough that a caller can interrupt. Long introductions create a bad first turn, especially when the caller has an urgent correction or wants to switch languages. The persona should then know how to respond when the caller does not follow the expected path.
This is where native speech work matters. Asenda Talk’s Twi recognition and synthesis are fine-tuned in-house. The build should still be evaluated with the phrases, names, corrections, and switches your callers actually use. A language label alone cannot prove that a conversation preserves meaning. For a useful test case, see Can This System Preserve Meaning When Callers Switch Between Twi and English?.
Choose a voice, then listen for task fit
Voice selection is a configuration choice, but it affects comprehension, trust, and turn-taking. Choose the voice after the persona and first message exist, because the opening gives you something concrete to listen to.
Run the same short scenario through the selected voice. Listen for whether names, numbers, addresses, and repeated details remain understandable. Test a caller who answers in Twi after an English greeting. Test a caller who repeats a detail more slowly. Test the moment where the agent needs to ask for confirmation rather than infer the answer.
Document what happens. A good Thursday build leaves behind more than an agent configuration. It leaves a test set, a list of failed turns, and a clear next change. That record prevents the team from treating one clean demo as proof that the persona is ready for live calling.
Keep the build connected to the controls around it
Asenda Talk uses Vapi for assistant runtime orchestration, while its telephony lifecycle webhook pipeline tracks call truth. Every call is designed to carry consent, opt-out, and audit-trail information. Per-minute billing also stays behind an operator-controlled real-money gate.
Those controls should shape the persona from the beginning. If the agent may call, the build needs a consent and opt-out path. If it may record an account action, the team needs to know what evidence the call record preserves. If a provider has not been approved, do not describe the afternoon’s work as a launch plan.
Apollo 13’s adapter mattered because it worked within the equipment and limits already present in the spacecraft. A useful voice-agent build has the same discipline: make the persona fit the speech system, runtime, call records, consent requirements, and provider status that exist now. For the current boundary, read Asenda Talk’s speech test. Telephony is not live yet..
End the afternoon with one scenario the agent handles reliably, one scenario it fails, and one specific change to test next. That is a working persona: evidence, not a confident-sounding configuration.
Comments
No comments yet.