One Agent, Many Presentations: An Architecture for In-Person, Voice-First AI Assistants

The face, voice, personality and gestures can change for every visitor's preference. Without changing the knowledge, rules and responsibility behind them.

Imagine, you walk into a support centre in person. Instead of a counter, there is a screen at eye level with the face of an AI agent on it. You don't type anything. You ask your question out loud, and the agent answers you by voice, looking at you, nodding, pointing to the steps on the screen.

The agent you meet could look and sound like a woman or a man. It could be warm and patient, or brisk and to the point. It could use calm, small gestures or lively ones. The next visitor might choose a completely different one.

Each of these is a presentation: a combination of appearance, voice, personality and gestures. But behind every presentation is the same agent, with the same knowledge, the same rules and the same responsibility for every answer.

Here I will be describing an architecture for that: one agent, many presentations. The hard part isn't rendering an avatar. It's deciding exactly where the agent ends and the presentation begins, and making sure a presentation can never change what the agent knows, may do, or must follow.

The rule

Put the boundary in the wrong place and one of two things happens. Either every presentation turns into a separate assistant, with its own prompt, knowledge and review. Or a presentation becomes a side door, through which extra documents, tools or softer rules get attached without anyone noticing.

A presentation is how the agent appears, not who it is. It holds no knowledge, no permissions and no rules. Everything that decides what the assistant may say or do belongs to the agent.

What a presentation is made of

For an in-person, voice-first assistant, a presentation is much more than a name and a picture. It is everything about how the agent looks, sounds and behaves on the screen:

Personality needs the most care. Personality changes how something is said, never what is said or done. A warm presentation and a brisk one may word a refusal differently, but both must refuse. A friendly presentation cannot waive a fee the policy doesn't allow. So personality should be a small set of reviewed presets, never a free-text field. A free-text personality is a second, unreviewed policy, and an easy place to inject instructions.

Gestures are performed, not decided. The model may suggest a nod or a smile, but the runtime only plays gestures from a fixed list and ignores anything else.

In configuration, a presentation is nothing more than this:

# presentations/ava.yaml
id: ava
agent: branch-support          # owned by exactly one agent
appearance: avatar_a
voice: voice_f1
personality: warm              # a reviewed preset, never free text
gestures: gentle               # an allow-listed set
locale: en

# presentations/ava.yaml
id: ava
agent: branch-support          # owned by exactly one agent
appearance: avatar_a
voice: voice_f1
personality: warm              # a reviewed preset, never free text
gestures: gentle               # an allow-listed set
locale: en

There is no field for instructions, documents or tools, so a presentation has nowhere to carry them.

A presentation doesn't even have to be human. A friendly animal character, say a wren, is just another appearance and voice over the same agent, held to exactly the same rules.

The AI disclosure belongs to the agent. However human a presentation looks and sounds, every one of them says it is an AI.

Three Design Lessons

If a presentation is expensive, the boundary is wrong

Adding a presentation should be a small change: a row of configuration, not a new prompt, new retrieval or a new review. If a presentation needs any of those, it is quietly becoming a second agent.

The model will over-perform the presentation

Give a presentation a name and a personality in the prompt, and a model may start treating it as a character to play, for example by introducing itself again in every answer. Keep persona instructions short and tell the model plainly that the visitor has already been greeted. A presentation is a name and a manner the agent uses, not a character it performs.

Switching presentations must not reset anything that matters

If a visitor switches from one presentation to another mid-conversation, the conversation, the knowledge and the rules stay exactly as they were. Only how the next answer is delivered changes. Otherwise people quickly learn to "ask the other one" for a different answer.

The in-person setting

A chat window is forgiving. A screen in a public support centre is not: strangers touch it, anyone nearby can hear it, and the next person in the queue is standing right behind you.

• The kiosk is a thin client. It captures voice and touch, plays audio, draws the avatar and shows captions. It holds no API keys, no conversation history and no business logic. Every decision happens on the server.
• Voice is untrusted input. The microphone can pick up someone else, or a recording. A transcript goes through the same checks as typed text, and anything consequential, like blocking a card, needs a tap on the screen, not just a spoken "yes".
• Only checked text is spoken. Streaming model output straight into speech is tempting for speed, but it speaks words that validation might reject a second later. Cover the wait with a "thinking" gesture instead.
• Captions are always on, for visitors who can't hear well, for noisy rooms, and for when the audio fails.
• One visitor, one session. When someone says goodbye or walks away, the screen, audio and session are wiped. The next person always starts fresh, and nothing personal is read aloud for the queue to hear.
• A voice is not an identity. Never authenticate a visitor by their voice; voices can be cloned. Use a code on their phone or a check by staff.

In code, the hand-off from the agent to the runtime is small, and it closes two easy mistakes: unknown gestures and injected speech markup.

GESTURES = {"nod", "smile", "point_to_screen", "thinking", "open_palms"}

def perform(answer, presentation):
    cues = [c for c in answer.cues if c in GESTURES]       # unknown cues are dropped
    ssml = render_ssml(voice=presentation.voice,           # from config, not the model
                       text=xml_escape(answer.text))       # model text can't add tags
    return Performance(ssml=ssml, gestures=cues, captions=answer.text)

GESTURES = {"nod", "smile", "point_to_screen", "thinking", "open_palms"}

def perform(answer, presentation):
    cues = [c for c in answer.cues if c in GESTURES]       # unknown cues are dropped
    ssml = render_ssml(voice=presentation.voice,           # from config, not the model
                       text=xml_escape(answer.text))       # model text can't add tags
    return Performance(ssml=ssml, gestures=cues, captions=answer.text)

Who chooses the presentation?

The visitor, or the location's default. Not the camera.

It's tempting to let the kiosk look at the visitor, guess their age or gender, and pick a presentation to match. Don't. It's biometric processing, it gets people wrong in public, and it bakes in stereotypes. Let people choose by touch or by voice, and keep appearance, voice, personality and gestures independent of each other. If the female presentation is always the warm one and the male presentation always the authoritative one, the product teaches a stereotype.

Enforce it in the database too

Every presentation belongs to exactly one agent, and every reference to a presentation carries that agent. Then the database itself refuses another agent's presentation, even if the application has a bug:

ALTER TABLE devices
  ADD FOREIGN KEY (tenant_id, agent_id, default_presentation_id)
      REFERENCES presentations (tenant_id, agent_id, id);   -- same agent, or rejected

ALTER TABLE devices
  ADD FOREIGN KEY (tenant_id, agent_id, default_presentation_id)
      REFERENCES presentations (tenant_id, agent_id, id);   -- same agent, or rejected

And if a "premium" presentation would see data the standard one can't, it isn't a presentation. It's a different agent.

One question for every change

The separation only helps while a presentation stays a presentation. Every proposed change should pass one question.

The human side

• Make sameness visible. Tell people it's the same assistant: "Same assistant, different look and voice." Otherwise some will ask one presentation for a second opinion on another's answer.
• No borrowed authority. No uniforms, badges, or likenesses of real staff. A voice that imitates a real person needs that person's consent.
• Design for everyone. Captions, a touch alternative to speech, a slower voice option, and a screen reachable from a wheelchair.
• Watch for trust effects. A human-like face and voice can make an answer feel more authoritative than its sources justify. That's a question for user research, not a solved problem.

What to test

• Parity across presentations. Every presentation gives the same decision on a fixed set of policy questions. Only the wording and delivery may differ.
• Switching presentations mid-conversation keeps the context, knowledge and rules.
• A presentation from another agent is refused, with the same error as an unknown one.
• The model can't inject speech markup or gestures outside the fixed list.
• After a session ends, nothing of it remains on the device.

A stable agent, flexible presentations

This architecture gives you one place to change the experience and one place to govern the assistant. Add a presentation, a voice, a personality or a new kiosk without touching knowledge, tools or policy. Any change to what the assistant knows or may do shows up as an agent change, where it gets reviewed.

For an organisation that has to stand behind what its assistant says across a counter, that makes approval simple: approve one agent's responsibilities, then let visitors choose how they meet it.

The presentation can change during a conversation. The responsibility for the answer stays with the agent.

This article is based on my real experience developing agents with multiple presentations, including an AI-powered university admissions assistant.