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.
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.
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:
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.
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.
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.
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.
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.
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)
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.
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
And if a “premium” presentation would see data the standard one can’t, it isn’t a presentation. It’s a different agent.
The separation only helps while a presentation stays a presentation. Every proposed change should pass one question.
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.
One Agent, Many Presentations: An Architecture for In-Person, Voice-First AI Assistants was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.