Brand AI assistant character: how to develop
The branding team spent half a year outlining the character: voice, values, even favorite phrases. The assistant was launched — and within a week complaints started coming into support: the bot apologizes with exaggerated care, or coldly rejects the user with a bureaucratic refusal in a neighboring dialog. The document was perfect. The character in production — not so much.
Why does one assistant end up with a 'split personality'
Researchers have termed this phenomenon AIDIS — AI Dissociative Identity Syndrome, a phenomenon in which a model demonstrates inconsistent behavior due to conflicts between the goals of different system layers. The bot demonstrates inconsistent behavior not because someone wrote a poor prompt, but because the goals of different system layers conflict with each other and are not integrated. The model responsible for text generation 'pulls' toward naturalness and varied formulations. The safety layer 'pulls' toward template-like, legally secure phrases. The information search layer feeds facts without considering tone. The result is an assistant that sounds like a caring adviser in one response and like a customer support answering machine from the nineties in the next.
One particularly dangerous nuance is that the model delivers an incorrect answer with the same calm and confident intonation as a correct one. The user does not perceive the difference in reliability — they perceive confidence as competence. Here, identity dissociation does not function as a quirky bug, but as a source of trust in incorrect information.
How to translate 'friendly' and 'professional' into rules, not adjectives
Adjectives from the brand book are not useful for the model directly. "Friendly" for one developer means emojis and exclamation marks, for another — short phrases without jargon. The line needs to be broken down into measurable parameters: sentence length, lexicon that can and cannot be used, specific formulations for typical situations — refusal, uncertainty, escalation to a person.
A good model for this is the R/GA agency framework, which describes an AI assistant through four elements, rather than through a single 'personality':
- Character — speech style, vocabulary, rhythm of phrases;
- Memory — that the assistant remembers about the user and how it uses this information;
- Intelligence — the boundaries of competence, what he knows how to solve by himself;
- Principles — ethical and reputational constraints that are never violated.
This is broader than the customary 'person in tone and voice' and immediately sets operational points: intelligence and memory are architectural solutions, not text in a prompt.
There are also data in favor of precise adjustment rather than general formulations: in a telecom study covering 57 000 interactions, the match between the bot's personality and the user's personality — introvert or extrovert — improved both buyer behavior and dialogue duration. An abstract 'friendly tone for all' works worse than a communication pattern calibrated for a specific audience segment.
Character document and character in production are different objects
The key mistake of the industry: persona exists in a beautiful PDF on Google Drive, but is not encoded in the system prompt. If the decision about how the assistant reacts to rudeness or to a request for a medical consultation is not written in the instruction followed by the model in real time — then it simply does not exist. The phrase 'You are a helpful, friendly assistant' does not solve anything: the model does not know what the sentence length should be, whether jokes are allowed, or what to do when uncertain about the answer.
| Persona-document | Persona-in-production |
|---|---|
| Describes the character in words: "warm", "expert", "with humor" | Sets the rules: phrase length, lexicon, templates for refusal and escalation |
| Lives in the presentation or wiki, is read once at startup | Lives in system prompt, output filters, access restrictions to tools |
| Not automatically verified | Tested on specific scenarios before release and monitored after |
| Belongs to the brand team "on paper" | Belongs to the product manager as a versioned product artifact |
Why one prompt is not enough: character control architecture
Relying solely on the system prompt is unsafe — the model may circumvent the instructions under the pressure of context, a long dialogue, or a manipulative user query. A character that remains grounded is built on multiple levels at once:
- System prompt — basic style and boundary rules.
- Tool permissions — what actions and data are allowed to be invoked by the assistant.
- Output filtering — verification of the response after generation before showing to the user.
- Retrieval constraints — limitations on which sources can be used to form an answer.
- Human review — manual verification of problematic or high-risk cases.
Each level catches what the previous one missed. The lack of this multi-layered approach, and not 'bad prompting,' explains most public failures of brand assistants.
Where the character hits the brand's reputation
The most common mistake is trying to make the assistant as human and emotional as possible. This looks impressive in a presentation, but in practice pushes the product into the uncanny valley: users don't trust a bot that 'tries too hard' to portray emotions, and prefer clear competence to theatrical warmth.
The second mistake is a legal disclaimer instead of a thoughtfully designed refusal. A phrase like 'I can't give you a medical recommendation, please see a doctor' destroys the character and sounds like a system failure. A working variant is one designed as part of the character: 'I won't give you a specific medical advice, but I'll help you formulate questions for the doctor' — a refusal that doesn't fall out of the brand's voice and at the same time covers the legal risk.
The third error is a confident tone with incorrect facts. If a character is programmed to sound equally convincing at all times, mistakes become especially dangerous: the user receives no signal that 'I am not sure here'.
How to check the character before launch and not lose it afterwards
Before release, it is necessary to run the assistant through a set of stress scenarios: an aggressive user, a request outside competence, a request to violate the rules, a long dialogue with attempts to manipulate the tone. Each response is compared not to 'feeling', but to specific rules from the specification — phrase length, lexicon, refusal format. Without such a test, the character exists only in theory, and the first tester becomes a live user in production, which is almost always more expensive.
After launch, the character degrades gradationally, not all at once. Updating the base model changes the manner of formulations even with an unchanged system prompt. A new source in the retrieval layer brings facts in a different stylistic approach. The support team adds a 'temporary' response template for a frequent complaint — and after six months, a third of dialogs sound off-specification, because nobody has been cross-checking them against the template since launch. Therefore, the character must be monitored just like conversion metrics: with regular sampling of real dialogs, cross-checking against reference scenarios, and versioning of prompts and filters to enable rollback in case of regression.
The practical conclusion is simple: a brand character in an AI product is not a creative task that is completed once at the launch stage, but an operational process with an owner, metrics, and a check schedule.
The branding team spent half a year outlining the character: voice, values, even favorite phrases. The assistant was launched — and within a week complaints started coming into support: the bot apologizes with exaggerated care, or coldly rejects the user with a bureaucratic refusal in a neighboring dialog. The document was perfect. The character in production — not so much.
Why does one assistant end up with a 'split personality'
Researchers have termed this phenomenon AIDIS — AI Dissociative Identity Syndrome, a phenomenon in which a model demonstrates inconsistent behavior due to conflicts between the goals of different system layers. The bot demonstrates inconsistent behavior not because someone wrote a poor prompt, but because the goals of different system layers conflict with each other and are not integrated. The model responsible for text generation 'pulls' toward naturalness and varied formulations. The safety layer 'pulls' toward template-like, legally secure phrases. The information search layer feeds facts without considering tone. The result is an assistant that sounds like a caring adviser in one response and like a customer support answering machine from the nineties in the next.
One particularly dangerous nuance is that the model delivers an incorrect answer with the same calm and confident intonation as a correct one. The user does not perceive the difference in reliability — they perceive confidence as competence. Here, identity dissociation does not function as a quirky bug, but as a source of trust in incorrect information.
How to translate 'friendly' and 'professional' into rules, not adjectives
Adjectives from the brand book are not useful for the model directly. "Friendly" for one developer means emojis and exclamation marks, for another — short phrases without jargon. The line needs to be broken down into measurable parameters: sentence length, lexicon that can and cannot be used, specific formulations for typical situations — refusal, uncertainty, escalation to a person.
A good model for this is the R/GA agency framework, which describes an AI assistant through four elements, rather than through a single 'personality':
- Character — speech style, vocabulary, rhythm of phrases;
- Memory — that the assistant remembers about the user and how it uses this information;
- Intelligence — the boundaries of competence, what he knows how to solve by himself;
- Principles — ethical and reputational constraints that are never violated.
This is broader than the customary 'person in tone and voice' and immediately sets operational points: intelligence and memory are architectural solutions, not text in a prompt.
There are also data in favor of precise adjustment rather than general formulations: in a telecom study covering 57 000 interactions, the match between the bot's personality and the user's personality — introvert or extrovert — improved both buyer behavior and dialogue duration. An abstract 'friendly tone for all' works worse than a communication pattern calibrated for a specific audience segment.
Character document and character in production are different objects
The key mistake of the industry: persona exists in a beautiful PDF on Google Drive, but is not encoded in the system prompt. If the decision about how the assistant reacts to rudeness or to a request for a medical consultation is not written in the instruction followed by the model in real time — then it simply does not exist. The phrase 'You are a helpful, friendly assistant' does not solve anything: the model does not know what the sentence length should be, whether jokes are allowed, or what to do when uncertain about the answer.
| Persona-document | Persona-in-production |
|---|---|
| Describes the character in words: "warm", "expert", "with humor" | Sets the rules: phrase length, lexicon, templates for refusal and escalation |
| Lives in the presentation or wiki, is read once at startup | Lives in system prompt, output filters, access restrictions to tools |
| Not automatically verified | Tested on specific scenarios before release and monitored after |
| Belongs to the brand team "on paper" | Belongs to the product manager as a versioned product artifact |
Why one prompt is not enough: character control architecture
Relying solely on the system prompt is unsafe — the model may circumvent the instructions under the pressure of context, a long dialogue, or a manipulative user query. A character that remains grounded is built on multiple levels at once:
- System prompt — basic style and boundary rules.
- Tool permissions — what actions and data are allowed to be invoked by the assistant.
- Output filtering — verification of the response after generation before showing to the user.
- Retrieval constraints — limitations on which sources can be used to form an answer.
- Human review — manual verification of problematic or high-risk cases.
Each level catches what the previous one missed. The lack of this multi-layered approach, and not 'bad prompting,' explains most public failures of brand assistants.
Where the character hits the brand's reputation
The most common mistake is trying to make the assistant as human and emotional as possible. This looks impressive in a presentation, but in practice pushes the product into the uncanny valley: users don't trust a bot that 'tries too hard' to portray emotions, and prefer clear competence to theatrical warmth.
The second mistake is a legal disclaimer instead of a thoughtfully designed refusal. A phrase like 'I can't give you a medical recommendation, please see a doctor' destroys the character and sounds like a system failure. A working variant is one designed as part of the character: 'I won't give you a specific medical advice, but I'll help you formulate questions for the doctor' — a refusal that doesn't fall out of the brand's voice and at the same time covers the legal risk.
The third error is a confident tone with incorrect facts. If a character is programmed to sound equally convincing at all times, mistakes become especially dangerous: the user receives no signal that 'I am not sure here'.
How to check the character before launch and not lose it afterwards
Before release, it is necessary to run the assistant through a set of stress scenarios: an aggressive user, a request outside competence, a request to violate the rules, a long dialogue with attempts to manipulate the tone. Each response is compared not to 'feeling', but to specific rules from the specification — phrase length, lexicon, refusal format. Without such a test, the character exists only in theory, and the first tester becomes a live user in production, which is almost always more expensive.
After launch, the character degrades gradationally, not all at once. Updating the base model changes the manner of formulations even with an unchanged system prompt. A new source in the retrieval layer brings facts in a different stylistic approach. The support team adds a 'temporary' response template for a frequent complaint — and after six months, a third of dialogs sound off-specification, because nobody has been cross-checking them against the template since launch. Therefore, the character must be monitored just like conversion metrics: with regular sampling of real dialogs, cross-checking against reference scenarios, and versioning of prompts and filters to enable rollback in case of regression.
The practical conclusion is simple: a brand character in an AI product is not a creative task that is completed once at the launch stage, but an operational process with an owner, metrics, and a check schedule.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
