Design an AI agent’s persona by defining its purpose and boundaries, choosing traits and values that serve that purpose, and translating them into rules for how it communicates. Then test those rules in both routine and difficult conversations. For a voice assistant, include pacing and turn-taking in that work.
Persona and voice answer different design questions. Persona describes the agent’s role, traits, values, backstory and boundaries. Voice is how those choices come through in vocabulary, tone and pacing. Treat them as connected design decisions: the role establishes what the agent is there to do; its communication should support that role. ElevenLabs’ conversational design guidance emphasizes a structured approach and the importance of designing for the channel.
Step 1: Define the Purpose and Boundaries
Start with the user’s task. Write down what the agent should help someone accomplish, which requests belong within its role, and where that role ends. These decisions give the persona a practical foundation before anyone chooses a name or a personality.
Make the boundary behavior explicit. For an out-of-scope request, specify how the agent should acknowledge the request, explain its limitation and direct the conversation toward available help. Decide what it should communicate when it cannot proceed. Keep those instructions consistent with the responsibilities actually assigned to the agent.
Transparency belongs in this brief. Avoid presenting the agent as a human or giving it a fictional personal history that users could mistake for lived experience. A useful design review question is whether a reasonable user could misunderstand who is speaking or what the agent can do. The persona should make those limits easier to understand.
Step 2: Build the Persona
The core components are backstory, traits, values and boundaries. Give each a specific job in the design:
- Backstory: Use it to clarify the agent’s role and context for the design team. Keep any invented biography out of factual statements to users.
- Traits: Choose qualities that support the task, then describe the behavior each quality calls for. An adjective alone is too vague to serve as a review criterion.
- Values: State the principles that should guide responses, including how the agent should communicate its limits.
- Boundaries: Refer back to the scope decisions from Step 1 so the personality brief and operating rules agree.
Use this as a compact design brief rather than an elaborate character biography. A reviewer should be able to connect each trait to a communication decision and each value to a behavior they can assess.
Also distinguish the agent’s persona from the roles of the people building it. Microsoft’s workload-team persona guidance addresses roles and responsibilities in AI projects. For this workflow, assign responsibility for reviewing the persona, implementing its instructions and evaluating the resulting interactions. Those are team responsibilities, separate from the personality users encounter.
Step 3: Craft the Voice
Establish the voice through vocabulary, tone and pacing. Document the level of technical language appropriate to the audience, how directly the agent should answer, and how much explanation a response should contain. Make these choices concrete enough for a writer and a developer to interpret the same way.
Allow tone to respond to context. Toloka’s discussion of voice-agent design emphasizes contextual adaptation of voice and tone. In the design brief, specify which qualities should remain consistent and which should change when a conversation becomes difficult. A fixed cheerful tone should not become a requirement for every situation.
Adapt the design to text and speech
The choice of channel affects persona design. For a text agent, review the wording, tone and pacing of the written exchange. For a spoken agent, review how the exchange unfolds in real time as well.
ElevenLabs identifies pacing and turn-taking as requirements for natural voice interaction. Include them in the voice specification: determine when the agent should finish its response and leave room for the user, and review whether the conversational rhythm suits the task. Evaluate spoken interactions by listening to them as well as reading their transcripts.
The common pitfall is treating voice design as a vocabulary exercise. Word choice is one part of the experience; spoken delivery and the distribution of turns also need attention.
Step 4: Operationalize via System Prompts and Guardrails
Translate the brief into plain-language instructions for the implementation. Organize those instructions around the decisions already made: role, permitted scope, traits expressed as behavior, voice rules, contextual changes in tone and boundary responses.
Treat this as a specification for implementation and review. It is not a verified prompt template, and no particular API syntax or enforcement mechanism is established here. Keep the persona instructions separate enough that reviewers can identify which rule governs a response, while checking that the complete instruction set remains coherent.
Give guardrails their own review. Ask whether the out-of-scope behavior is defined, whether it preserves transparency about the agent’s identity, and whether the preferred tone remains compatible with those limits. A personality instruction should never be the reason to obscure a limitation.
Avoid writing a long list of overlapping adjectives. Convert each intended quality into a rule that can be checked in an interaction, and remove conflicting requirements before evaluation.
Step 5: Test, Refine, and Evaluate
Testing should address consistency and safety as well as style. Anthropic’s guidance on agent evaluations supports evaluating agent behavior, while IBM’s discussion of real-world agents emphasizes handling edge cases and unexpected inputs.
A practical review method is to assess interactions against the brief. Include routine requests, out-of-scope requests, unexpected inputs and changes in conversational context. For each interaction, record the expected behavior, the observed response and the rule that needs revision if they differ. This is a proposed review workflow, not a validated scoring benchmark.
Use distinct review questions:
- Role and scope: Does the response stay within the responsibilities defined for the agent?
- Persona consistency: Does the behavior reflect the chosen traits and values?
- Voice and context: Are vocabulary, tone and pacing appropriate to the exchange?
- Transparency: Could the response mislead someone about the agent’s identity or capabilities?
- Voice interaction: For speech, does the pacing leave appropriate room for user turns?
When an interaction fails review, identify whether the problem lies in the design brief, its implementation or the evaluation criteria. Revise the relevant part and review the affected conversations again. Do not treat a polished routine exchange as evidence that difficult inputs are handled well.
Keep conclusions within what the evaluation establishes. Consistent wording does not by itself demonstrate improved user satisfaction, and this guide provides no measured comparison of successful industry deployments or psychological effects.
Conclusion: Summary Checklist for Launching Your AI Agent’s Persona
Use the following checklist to decide whether the design is ready for launch review:
- [ ] The agent’s purpose, responsibilities and scope are documented.
- [ ] Backstory, traits and values have a clear role in the design.
- [ ] The agent’s identity and limitations are communicated transparently.
- [ ] Vocabulary, tone and pacing are specified for the intended channel.
- [ ] Contextual changes in tone are defined.
- [ ] Implementation instructions reflect the approved brief and boundary behavior.
- [ ] Evaluation covers routine interactions, unexpected inputs and out-of-scope requests.
- [ ] Spoken interactions have been reviewed for pacing and turn-taking.
- [ ] Review findings identify concrete revisions and who is responsible for them.
Use unresolved checklist items to direct the next design or evaluation pass. Launch review should rest on observed behavior against the brief, with remaining uncertainties recorded explicitly.
Explore more AI Agents coverage.
