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

An architecture called "one agent, many presentations" separates an in-person, voice-first AI assistant's appearance, voice, personality and gestures from the single agent that holds its knowledge, permissions and rules, so each visitor can pick a different presentation without creating a separate assistant. Under the design, a presentation is limited to configuration fields such as appearance, voice, a reviewed personality preset, an allow-listed gesture set and locale, with no field for instructions, documents or tools, and gestures are only played from a fixed list even if the model suggests others. The AI disclosure that the assistant is an AI belongs to the agent rather than any presentation, and switching presentations mid-conversation leaves the conversation, knowledge and rules unchanged.

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: presentations/ava.yamlid: avaagent: branch-support owned by exactly one agentappearance: avatar avoice: voice f1personality: warm a reviewed preset, never free textgestures: gentle an allow-listed setlocale: 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. 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 https://pub.towardsai.net/one-agent-many-presentations-an-architecture-for-in-person-voice-first-ai-assistants-a1ee5eaa466d was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.