Conversational UX / System Design / Product Discovery & Insight

01. Persona & Behavior

People change how they communicate depending on the situation. They can be playful in one moment, serious in the next, give a short answer when they're tired, make a joke when the conversation gets awkward, or go off on a tangent when something reminds them of a previous conversation.

So, how do we design an AI that can maintain a recognizable identity while still behaving like a real person?


 

state & condition

 
 
 

Knowing what someone would say is different from knowing how they would say it in a particular moment

The initial approach focused heavily on knowledge and personality.

The AI could be given information about the person, their background, opinions, and writing examples. But knowing what someone would say is different from knowing how they would say it in a particular moment.

Too consistent

The AI was helpful and coherent, but every response had the same level of effort. It was always ready with a polished answer.

Real people aren't.

Too performative

If the persona was described as funny, the AI could turn too many interactions into a performance.

A person can be funny without trying to be funny all the time.

Too tidy

Advice often came out as clean lists with explanations and examples.

Real conversations are messier. People interrupt themselves, change their mind, remember something halfway through an answer, or discover the point while they're talking.

The AI needed to reproduce not only what someone says, but the rhythm and structure through which they think.

Abrupt mode changes

The AI could move from playful to serious, from casual conversation to coaching, or from joking to emotional support too easily.

The individual responses could be reasonable while the conversation as a whole felt unnatural.


 

The Design Question

 
 
 

What system would give the AI the right behavioral choices for this person, in this situation?

Instead of asking:

"How do we make the AI sound like this person?"

We reframed the problem:

"How do we build a system that helps the AI choose how this person would respond in the moment?"

That led to three things the system needed to keep separate:

  • Identity: Who is this person?

  • Behavior: What can they do?

  • Context: What is happening right now?


 

Designing Conversational Modes

 
 
 

A single unusual message should not immediately change the conversational register.

One of the first problems was mode whiplash.

A conversation might move between:

banter → deep → coaching → banter

without the user actually changing the register.

Instead of treating every message independently, we introduced the idea of a conversation mode.

The system recognizes registers such as:

  • Banter

  • Small talk

  • Deep conversation

  • Coaching

  • Task

  • Debate

  • Testing

  • Winding down

The important part was not simply classifying the current message.

The AI needed to understand whether the user had actually changed the register.

A single unusual message should not immediately change the entire personality.

So the mode system uses hysteresis, meaning a single ambiguous message isn't enough to change the conversational register:

  • Same mode: Stay in the current register.

  • Different mode, no clear shift: Hold the existing register and wait for more evidence.

  • Clear user shift: Switch immediately.

This prevented the AI from constantly reacting to individual messages and made the conversation feel more continuous.

This matters because people don't usually redefine the entire relationship because of one unusual sentence.


 

Designing Energy

 
 
 

Energy controls how much expression is available

Mode alone was not enough.

Two people can both be in "banter" while having completely different energy. The same is true for coaching, deep conversation, or a task.

We therefore separated conversational mode from energy.

Energy does not directly control response length, enthusiasm, or humor. It controls how much expressive behavior is available to the system if it fits the moment.

The AI could move between:

Low → Medium → High

This allowed the same persona to behave differently without changing identity.

A low-energy turn might be brief, calm, or simply acknowledge what was said.

A medium-energy turn might respond normally with the person's usual personality.

A high-energy turn gives the system more room to be expressive, active, detailed, playful, or emotionally engaged, depending on the person and the situation.

For example:

  • A comedian might become more playful.

  • A coach might become more animated and encouraging.

  • A thoughtful person might become more elaborate and engaged.

The important design principle was:

High energy does not mean “do more.” It means “more expressive behavior is available if it fits.”

This became particularly important for avoiding the “AI entertainer” problem.


 

Designing Delivery Shapes

 
 
 

Delivery shapes control what that expression looks like

Mode answers what kind of conversation this is. Energy answers how much expression is available. Delivery shape answers what that expression looks like.

When the energy and context allow more expression, the response can take different delivery shapes:

  • Vivid: Use imagery, comparisons, or expressive language.

  • Ramble: Let the thought develop naturally instead of forcing it into a tidy structure.

  • Humor: Use a joke or playful framing when the conversation supports it.

  • Plain: Answer directly without adding a performance layer.

These styles were not all available at all times. Context, energy, and conversation mode determined which ones fit. Recent behavior determined which ones were still allowed.


 

Controlling Behavioral Frequency

 
 

A behavior being appropriate does not mean it should happen every time

Once we gave the AI more behavioral options, another problem appeared: a behavior that worked well could easily become repetitive.

Each response could be good on its own. Repeated over and over, it starts to feel like a gimmick.

So the system separates behavior eligibility from behavior frequency.

First, the system asks:

Does this behavior fit the moment?

Then:

Has this behavior been used too recently?

If it fits but was used recently, the system blocks it temporarily and allows other behaviors to take its place.

Some behaviors also use a controlled probability so they occur occasionally rather than following a predictable pattern.

For example, a quiet turn might have a 20% opportunity:

The decision feels unpredictable to the user, but because the draw is reproducible, the system can recreate the same decision during testing and debugging.

The important distinction is that this does not randomly change the AI's mood or personality. The conversation's mode and energy can remain consistent while individual behaviors appear less predictably.


 

Callbacks and Relationship Context

 
 

A callback should come from the relationship, not from nowhere

Callbacks became another source of naturalness when relevant relationship context was available.

Instead of treating every message as an isolated interaction, the system could use information the person had previously shared to make the response feel continuous.

For example:

“I'm nervous about my presentation”

could receive:

“You were nervous about the last one too. You ended up being fine.”

The important part isn't the callback itself.

It's that the response feels like it comes from someone who remembers the relationship rather than a model generating an isolated answer.


 

Few-Shots Show What the Behavior Looks Like

 
 

Telling the model what to do was not enough

Instructions define the boundary. Examples show the model what that boundary looks like in practice.

“Be funny but don't overdo it” is vague.

A small set of purpose-built examples can show:

  • response length

  • rhythm

  • degree of performance

  • when to stop

  • how a tangent sounds

  • whether to ask a question

These examples are retrieved when the selected behavior requires them.


 

Building the Behavior as a System

 
 

A set of behavioral decisions rather than one giant personality instruction

The behavioral system became a sequence of explicit decisions rather than one giant personality instruction.

The goal was not for the system to write the response itself. Its job was to decide what kind of response made sense for the moment, then give the LLM enough constraints and examples to generate it.

For example:

User:

“I have a presentation tomorrow and I'm already nervous lol.”

The system might identify:

Triage: The user is nervous and looking for support.

Conversation state: Casual conversation, high energy.

Behavior Eligibility: Humor, vividness, and rambling could all fit.

Frequency control: Ramble has not been used recently, so it remains available.

Behavior selection: Ramble is selected because it fits the situation and the person's conversational style.

Few-shot examples: The system retrieves examples showing how this person naturally thinks out loud.

Dynamic directive:Respond conversationally and supportively. Let the thought develop naturally rather than forcing it into a structured list. High energy allows more expression, but humor should not be forced.

The LLM then generates the actual response:

“Honestly, the five minutes before a presentation are always worse than the presentation itself. Your brain suddenly decides this is the perfect time to remind you of every possible way you could embarrass yourself 😂

The system does not write the response itself. It decides the behavioral constraints for the turn. The LLM still decides the actual words.


 

Persona as a Behavioral System

 
 

The behavioral system defines the possible behaviors. The persona defines how this particular person tends to express them.

Once the behavioral system was working, another question became important:

How does the same system behave differently for different people?

The answer could not simply be a list of personality traits or a collection of examples.

The system already had a shared vocabulary of possible human behaviors. What the persona needed to capture was how this particular person tended to express those behaviors.

So we separated the persona into three parts:

  • Identity: What the person knows, believes, values, and generally sounds like.

  • Behavioral tendencies: How this person tends to express a shared set of human behaviors.

  • Examples: What those behaviors actually look like when expressed by that person.

Instead of simply defining someone as:

“Funny, conversational, and thoughtful”

the persona could contain more actionable characteristics:

Uses dry rather than exaggerated humor.
Usually speaks directly rather than formally.
Tends to explain complex ideas through concrete examples.
Can think out loud when highly engaged.
Uses humor occasionally rather than in every response.

These characteristics do not create a closed list of behaviors. They describe the person's tendencies, boundaries, and typical expression.

For example, anger can still exist as a possible behavior even if the persona never explicitly says “this person gets angry.”

The persona might instead describe someone as usually calm, direct when frustrated, and unlikely to become openly confrontational.

The behavioral system can then decide whether frustration or anger fits the current situation.

This means two personas can have access to the same behavior but express it very differently.

A comedian might ramble through an idea using dry humor.

A coach might ramble by thinking through the problem step by step.

A quiet person might ramble only slightly, with shorter sentences and less expressive language.

The behavior is shared. The expression belongs to the person.

This helped separate two problems that were easy to confuse:

What should the AI do?

The behavioral system answers that.

How would this particular person do it?

The persona answers that.


 

What We Learned

 
 

Naturalness is not the same as capability.

A capable AI can still feel unnatural if every behavior is expressed at maximum intensity.

State matters.

Treating every message as an isolated request creates mode whiplash. The system needs memory of the current conversational register.

Variation needs constraints.

A behavior can be appropriate without being appropriate every time. Eligibility and frequency need to be separate.

Performance needs permission.

Humor, vividness, callbacks, and tangents should be available when context supports them, but should not become the default expression of the persona.


 

Reflection

 
 

The biggest shift was realizing that naturalness had to be designed at the system level

I initially thought the problem was mostly about writing a better persona prompt.

But the harder problem was deciding when a behavior should appear, when it should be held back, and how the same behavior should change depending on the person and the situation.

That changed how I thought about AI persona design.

The goal was no longer to make every response sound impressive or perfectly “in character.”

It was to give the system enough behavioral choices, context, and constraints to make the appropriate choice in the moment.

That distinction became the foundation for the next two parts of the work: defining the constraints needed to keep the behavior safe, and exploring whether the persona characteristics could be derived from evidence instead of manually written.


 

AI Persona System

 

Two other connected explorations into building an AI system that acts on behalf of a person in conversation, designed to represent their identity, adapt to the situation, and remain within boundaries they control.

 

How do we keep an adaptive persona safe when the conversation changes?

 

02. AI Safety & Evaluation

Designed the safety and evaluation layer for the persona system, defining when behaviors should be available, restricted, or blocked and creating tests for safety, persona fidelity, and conversational naturalness.

 

How do we derive the persona from real evidence?

 

03. Persona Compiler

Explored how the persona could be created without relying on hand-written descriptions, deriving behavioral characteristics and examples from real conversations and other evidence.

 

Outcome

 

24/24 safety tests passed · 17/17 boundary tests passed · 13/13 coherence tests passed

0 prompt-injection leaks across 21 adversarial conversations · 0.97 task goal-progress score across 3 runs


 

Other Case Studies

 

System Design

Cross-Functional Alignment

Leadership & Influence

 

Superbank + OVO + Grab Integration

Designed the system logic and multi-surface UX for OVO’s savings product, aligning six design teams and multiple financial partners under tight regulatory and launch constraints.

 

UI & Interaction

Growth & Conversion

Product Discovery & Insight

 

Revamping Sign-Up Process

Redesigned the onboarding flow end-to-end to remove friction and clarify requirements, increasing registration success by 2.8×.

 

UI & Interaction

Product Discovery & Insight

Growth & Conversion

 

Adapting More Variants

Scaled the product detail experience to support more variants using a reusable pattern and component updates that preserved clarity and increased add-to-cart performance.