How to Design Conversational Agents with Generative AI

By Soledad Ferrer, Senior UX Content & Conversational Designer at Santex

There’s a conversation I keep hearing. Someone suggests adding an AI agent to a product. The team discusses the model, the integration, the tech stack, and then, almost as an afterthought, someone asks: “So, who’s writing the system prompt*?”*

There’s a trap hidden in that question. Not because it’s difficult to answer, but because it assumes the system prompt is the starting point. In practice, it’s the end of a process that most teams never go through.

What needs to be defined before writing a single line of a prompt

A conversational agent powered by generative AI doesn’t work like a traditional bot. A bot does what it was programmed to do; if something wasn’t programmed, it simply doesn’t exist. A generative AI agent needs something deeper than rules: it needs character.

That means that before opening an editor and writing instructions, you need to define the agent’s complete identity: its personality, values, boundaries, voice, tone system, conversational patterns, and emotional archetypes. Not as supporting documentation, but as the architecture that holds everything else together.

Over the past few weeks, I’ve been doing exactly that for a generative AI conversational agent in fintech. The process left me with five key learnings worth sharing.

Five layers that determine whether a conversational agent actually works

1. A core identity that remains consistent.

The agent may play different roles depending on the situation: informing, assisting, escalating, or providing reassurance. But one thing doesn’t change: who it is. That core identity is what allows it to respond consistently in situations no one explicitly programmed.

2. A voice and tone system grounded in concrete examples.

An adjective isn’t enough for AI. Saying “friendly” or “professional” doesn’t tell the system much. You need to show it what to say and what never to say, using real examples and the language of the people it will interact with. The difference between an agent that feels natural and one that feels robotic often comes down to this level of detail.

3. Conversational patterns documented across three layers.

What the pattern means for the business, how it should behave from a design perspective, and how it needs to be implemented by developers. A pattern that exists only in the designer’s head won’t survive the first integration.

4. Emotional archetypes of the user.

Not who the user is, but the emotional state they bring into the conversation. Someone checking their balance at 11 p.m. because they’ve just noticed a charge they don’t recognize is not in the same state of mind as someone browsing financial products on a Saturday morning. The agent needs to understand that difference and respond accordingly.

5. Antipatterns documented as part of the design.

This last layer is the least visible and, in my experience, the most decisive.

Why antipatterns are a fundamental part of the system prompt

We spend a lot of time discussing what we want the agent to do. We spend far less time thinking about what happens when it does something we don’t want it to do.

That’s exactly what antipatterns address: documented decisions about what the agent is not, what it should not do, and what should happen when it behaves differently than intended. They aren’t supporting documentation. They are a structural part of the system prompt.

How do you identify them? You discover them. They emerge when you ask what would happen if the agent did this in this particular context, and the response turns out to be inappropriate or simply not what the experience requires.

The process I followed had three stages:

1. Research and anticipation. Before the agent existed, I analyzed real scenarios from other systems. What happens when someone keeps pushing for an answer the agent cannot — and should not — provide? What happens when the system interprets an intent that doesn’t match what the user actually meant?

2. Documentation and definition. Every guideline came from understanding what could go wrong, examining that scenario, and defining how the agent should respond before it ever happens.

3. Validation with the full team. Design, development, and business need to be part of the same conversation. An antipattern that makes perfect sense from a UX perspective may be technically impossible to sustain, or it may carry legal implications that UX alone won’t see.

The result isn’t just another document. It’s the foundation that any agent, new flow, or future integration can rely on to remain consistent, feel human, and respond with judgment.

How AI fits into my own design process

There’s a common misconception worth clearing up: I don’t use AI to design conversations. I use it to think better while I design them. That distinction matters.

During the briefing and exploration stage, AI helps me anticipate user intents I may not have considered, identify edge cases, and surface questions I wasn’t asking yet.

During research, it helps me process volume. Language is the primary data source in conversational design: how someone describes a problem, which words they choose, what they assume without saying. When there are hundreds of conversations to analyze, AI can process in hours what would take me days. But the interpretation is still mine.

During design and prototyping, I use it to generate variations. The same message in three different tones. Five different ways to respond to ambiguity. Not so AI can automatically choose the best one, but so I have more options on the table and can make the decision with judgment.

During iteration, once the experience is live and real conversations start revealing what I didn’t anticipate, AI helps me identify abandonment patterns, friction points, and intents we failed to model.

There is one thing I don’t delegate at any stage: understanding why something fails. Recognizing when a technically correct message is emotionally wrong, deciding what needs to change, and understanding why — that requires judgment. And judgment can’t be automated.

AI expands what I can do. It doesn’t replace what I know how to do.

Conversational design as a system, not a copy layer

A common mistake in conversational AI implementations is treating conversational design as a superficial layer of the experience. It gets added at the end, once the system has already been defined, simply to “polish” the language.

That order is backwards.

When interaction happens through language, conversational design stops being just a writing concern and becomes part of the system architecture. Conversational systems operate across structural content layers that define how an agent interprets, processes, and responds to user intent:

• Intent design: how the tasks users want to accomplish are modeled, and how the system recognizes them within a conversation.

• Knowledge architecture: the structure of the information the agent can access, retrieve, or infer, and the rules that determine when and how that information should be used.

• System behavior: the strategies that define how the agent responds to ambiguity, uncertainty, or incomplete information.

• Language strategy: the principles that guide tone, clarity, precision, and consistency.

• Conversational flow orchestration: how the conversation progressively guides the user toward an action, decision, or resolution.

Nielsen Norman Group describes this shift as a move from command-based interfaces toward intent-based models, where users express the outcome they want and the system determines how to achieve it. In that paradigm, design means shaping how the system interprets language, refines intent, and collaborates with the user to reach an outcome.

If words are the interface, conversational agents are the system. And we are the ones designing how that system interprets, decides, and guides an interaction.

The question that changes the order of the work

Could some conversational experiences offer better usability than certain websites or apps simply because they eliminate the need to navigate?

When speed and immediate resolution are the goal, conversation can be the most natural path. But putting a bot inside a chat window isn’t enough. You need to design how the system understands, responds, and guides people toward what they need.

And that design doesn’t happen in isolation. For a conversational experience to truly solve problems, designers need to work closely with development, analysis, and business teams. Each discipline contributes a different part of the context: what the user needs, what the system can technically support, which rules it must follow, and what outcome makes sense for the business.

The best experiences emerge when those decisions are made together from the start — not when conversational design is brought in at the end to adjust the wording of a system that has already been defined.

Designing for generative AI isn’t about writing fewer rules. It’s about creating stronger foundations, together with everyone who makes the experience possible.