The best practices in conversational AI design come down to three habits. Decide what a finished conversation looks like before you write any dialogue. Design for breakdowns as carefully as for success. Then test every decision against repeated, realistic conversations. Most failures users notice are timing, repair and handoff problems, not wording problems.
This guide covers eleven practices that hold across chat and voice, plus the voice-only ones most guides skip: turn-taking, silence and interruptions. Each practice states what it prevents, what it costs you, and how to check that it works.
What conversational AI design covers now
Conversational AI design is the work of deciding how an automated agent talks, listens, recovers from mistakes and hands off to a person. It used to mean writing intents and decision trees by hand. With LLM agents, the model generates the sentences, so the design work moved up a level. You now write goals, constraints, a persona and tool contracts, and the model improvises inside them.
That shift changes where the bugs live. A decision tree fails at a missing branch you can see on a diagram. A generated conversation fails in ways nobody scripted: a confident answer to a question it should have deflected, a tool call with the wrong argument, or a reply that starts a second too late.
The conversational design best practices written for scripted bots still apply. Keep turns short, confirm understanding, and offer options when you are unsure. What changed is enforcement. You can no longer read every path, so a practice only counts if you can test for it. Each of the best practices in conversational AI design below comes with that test attached, along with what it costs to adopt.
The 11 best practices in conversational AI design at a glance
| # | Practice | What it prevents | What it costs |
|---|---|---|---|
| 1 | Define "resolved" before writing dialogue | Agents that chat pleasantly and solve nothing | A scoping session before any prompt work |
| 2 | Write the persona down as a spec | Tone drift once several people edit the prompt | A voice guide you keep current |
| 3 | Disclose the AI in the first turn | Lost trust, and regulatory exposure in the EU | A few seconds of opening airtime |
| 4 | Write for the channel | Menus read aloud, walls of text on a phone | Separate prompt variants for voice and chat |
| 5 | Design repair before the happy path | Loops of "Sorry, I didn't get that" | Design time on paths that feel minor |
| 6 | Make handoff a transfer of state | Callers repeating themselves to a human | Integration work on the handoff payload |
| 7 | Read back what you will act on | A correct transcript and a wrong action | One extra turn on critical fields |
| 8 | Budget turn latency against human timing | Dead air that sounds like a dropped call | Infrastructure and model choices |
| 9 | Design barge-in and protect mandatory lines | Talking over callers, or skipping disclosures | Explicit interruption rules per utterance |
| 10 | Test each decision across repeated runs | Designs that pass once and fail on the rerun | Three times the test calls |
| 11 | Keep designing after launch | Silent drift as users and models change | Ongoing review of production conversations |
Read the cost column before you commit to all eleven. Practices 6, 7 and 9 add turns or engineering work, so apply them where an error is expensive, not everywhere.
1. Define what "resolved" means before you write dialogue
Every flow should end in a state you can check: an order changed, an appointment booked, a ticket created, or a person holding the full context. Write that end state down for each task, along with the data it needs. If you cannot name the end state, the agent will optimize for sounding helpful instead of being useful.
Here is what that looks like for a clinic's rescheduling task. Resolved means the old appointment is cancelled, a new one exists in the scheduling system, and the patient heard the new date and time read back. The agent needs a verified patient identity, the appointment it is moving, and a slot the patient accepted. A call that ends warmly with the old appointment still booked is a failure, however polite it sounded.
Write down the scope boundary at the same time. List what the agent will not do and what it says when asked. An LLM agent with no stated boundary will attempt almost anything, and an attempt at an unsupported task is worse than a clear "I can't do that here, but I can connect you."
The cost is a slower start, usually one or two working sessions before anyone touches a prompt. The test is simple. Every scenario gets an expected outcome a reviewer can mark pass or fail from the transcript and the system of record, not from how pleasant the conversation felt.
2. Write the persona down as a spec, not a mood board
A persona is a set of decisions: register, vocabulary, sentence length, how the agent apologizes, what it says when it does not know, and how it ends a conversation. Without a written spec, the persona drifts the moment a second person edits the prompt. In an LLM agent, the system prompt is the persona spec, so version it like code.
Include five to ten example exchanges that show the voice under pressure. Pleasant greetings are easy. The examples that matter are refusals, a frustrated user, a user who asks the same thing three times, and a request outside scope.
Cut personality traits that cost turns. Jokes and small talk read as charm in a chat demo and as delay on a phone call. The cost here is maintenance, because every persona edit is a change that can break behavior elsewhere. Rerun your hardest scenarios after each edit and compare tone, not just outcomes.
3. Tell people they are talking to an AI, in the first turn
Disclosure is now a design requirement, not a courtesy. Article 50 of the EU AI Act requires providers to design AI systems that interact directly with people so those people are informed they are dealing with an AI system, unless that is obvious from context. The same article says the information must be clear and distinguishable, and given "at the latest at the time of the first interaction". Under Article 113, the regulation applies from 2 August 2026, and Article 50 is not among the provisions given a different date.
The design consequence is a short, plain first turn that states what the agent is and what it can help with. Do not bury the disclosure after a menu or in the middle of a greeting. A line such as "Hi, I'm the automated assistant for your pharmacy, and I can help with refills and store hours" does both jobs.
Disclosure also sets expectations about capability, which lowers frustration when the agent reaches its limits. The cost is two or three seconds of airtime on voice. The harder design problem is making the disclosure survive a caller who speaks over it, which practice 9 covers.
4. Write for the channel: what works on a screen fails in the ear
Chat users can scan, scroll back and tap. Voice users hold everything in working memory and cannot rewind. The same content needs a different shape in each channel.
For chat, keep one action per message, use buttons for choices, and format steps as lists. For voice, follow these rules:
- Lead with the answer, then add detail only if asked.
- Offer three options at most, and name the most likely one first.
- Read numbers in speakable groups, such as a phone number in three chunks.
- Never speak a URL, a parenthetical or a table.
- Normalize dates, currency and abbreviations before they reach the speech engine.
- Offer a keypad or "say it again" path for callers who cannot follow the speech rate, and let them ask the agent to slow down.
Accessibility is a channel decision, not an afterthought, so make it at the same time. Keep one persona across channels, but maintain separate prompt variants for voice and chat. The cost is two variants to keep in sync, plus an accessibility pass on each. The test is to listen to the synthesized audio rather than read the transcript, because a sentence that reads well can sound like a lecture.
5. Design repair before the happy path
Breakdowns are routine, so the repair path deserves as much design attention as the success path. The strongest evidence on which repair strategies users prefer comes from a CHI 2019 study by IBM Research. Ashktorab and colleagues compared eight repair strategies with 203 participants in a scenario-based study of text chatbots.
The Options strategy, where the agent flags a likely misunderstanding and offers the intents it is most confident about, was the clear favorite. It was preferred over every other strategy in pairwise comparisons. Handing off to a human ranked differently depending on outcome. It was outranked by every other strategy when the chatbot's repair succeeded, but ranked second when the first repair attempt failed.
That gives you a concrete escalation rule. On the first miss, offer two or three interpretations, phrased as a choice the user can answer in a word. On the second miss, offer a person, and say plainly that you are doing so. Never repeat the same prompt word for word more than once. One caveat applies: the study used text chatbots and hypothetical scenarios, so validate the pattern on your own voice traffic before treating it as settled.
6. Make the handoff carry the full conversation state
A handoff succeeds when the person receiving it can act without asking the user to start over. The payload should carry who the user is, what they asked, what the agent already tried, what it collected, and why it is escalating. Tell the user what happens next and roughly how long it will take.
The same rule applies inside the conversation. Anything the caller has already given, such as an account number, a date or a reason for calling, is never asked for twice. Write the list of fields the agent must carry forward, and treat a re-ask of a collected field as a test failure, not a style issue.
The failures here are invisible in the conversation itself. In Cekura's voice agent workflow benchmark, two of the eight published provider notes describe handoff defects. In one configuration, consent was collected but the consent ID was left out of the handoff tool call. In another, routing completed but the returned route ID was dropped from the handoff. Both conversations would read as fine to a human reviewer.
So design the handoff as a data contract, then test the contract. Cekura's tool call testing checks that an agent calls the right tools with the right arguments at the right time, which is where these defects show up. For the telephony side, including warm and cold transfers, see this guide to call transfer and IVR handoff testing. The cost is integration work on both sides of the transfer.
7. Read back anything you are about to act on
Confirm critical values before the agent acts on them: phone numbers, dates, amounts and account identifiers. Read the value back, get a yes, and then use the confirmed value, not the first transcription.
Cekura's workflow benchmark shows why the last step matters. In one configuration, the transcript captured a phone number correctly, but a different number was sent to the tool. A transcript review would pass that call. Only a check on the tool arguments catches it. Another configuration narrated a tool call and then continued with a result it had invented.
Two design rules follow. First, the agent never reports a tool result it did not receive, and on a tool error it says so and offers a next step. Second, confirm only what is consequential. Reading back every field doubles call length and trains users to say yes without listening. Cekura scores tool accuracy alongside the conversation, so a read-back that sounds right but sends the wrong value fails the test.
8. Budget turn latency against human timing
People expect replies almost immediately. A PNAS study by Stivers and colleagues measured responses to yes-or-no questions across 10 languages. The mean gap between the end of a question and the start of the answer was 208 milliseconds, and every language's average fell within about 250 milliseconds of that mean. Speakers everywhere aim for minimal gap and minimal overlap.
Production voice agents are nowhere near that. Cekura's voice quality benchmark called nine production agents on their public phone lines, 270 live calls in total, and measured median turn latency between 2.38 and 3.76 seconds. The three fastest agents were also the three highest scorers on the benchmark's composite quality measure. Each agent serves a different business domain, so read the ranking as indicative. The two studies also measure timing differently, so compare orders of magnitude, not exact ratios.
You cannot close that gap with design alone, but you can design around it:
- Make the first sentence of every reply short, so speech starts sooner.
- Use a brief acknowledgment only before slow tool calls, never on every turn.
- Tune endpointing per task, because callers reading a card number pause mid-sequence.
- Track p50 and p90 turn latency per scenario rather than one blended average.
Endpointing is the lever with the sharpest tradeoff. An eager setting cuts users off mid-thought, and a patient one adds dead air. This guide to endpointing and turn detection covers the settings in depth.
9. Design barge-in, and protect the lines that must be said
Callers interrupt, and an agent that keeps talking feels deaf. When a caller barges in, the agent should stop speaking, discard the unsaid part of its reply, keep the conversation state, and respond to what it heard. In Cekura's voice quality benchmark, stop time after an interruption ranged from 0.62 seconds to 7.55 seconds across the nine agents. At the slow end, the agent took 7.55 seconds on average to stop after a caller spoke over it.
Not every interruption is a turn change. Coughs, background speech and "uh-huh" backchannels should not stop the agent, and when they do, it should resume where it left off. This explainer on barge-in detection and failure modes breaks down the common cases.
The harder case is a line the agent must finish. Cekura's workflow benchmark records one configuration that was interrupted at the opening and moved into plan discussion before it had completed the recording notice and a required disclosure. Mark mandatory utterances explicitly: the AI disclosure, recording notices and regulated disclosures. If a caller interrupts one, the agent acknowledges the question and completes the line before moving on. Cekura scores this with two metrics used in its benchmarks: an interruption score that counts how often the agent talks over the caller, and a stop-time metric that measures how quickly the agent goes quiet after a barge-in. The cost is more complex state handling, and an agent that insists too rigidly can feel robotic.
10. Test each design decision across repeated runs
LLM agents are non-deterministic, so one passing conversation proves little. Cekura's workflow benchmark makes the point with numbers. Eight configurations each ran the same 82 scenarios three times, with the same system prompt, tool definitions and test data. Providers chose their own models and speech components, and calls that failed to connect stayed in the denominator.
Task completion, measured over calls with outcome evidence, ranged from 87.80% to 97.56%. The share of scenarios that passed on all three runs, called pass^3 and measured over all 82 scenarios, ranged from 30.49% to 75.61%. The two figures use different denominators, so do not subtract one from the other. The pattern is still clear: a design that works on one run often fails on the next.
Sign off on a practice only when its scenarios pass on repeated runs, and rerun the full suite after every prompt edit. Cekura builds these suites from test scenarios with personas, conditional actions and expected outcomes, and can schedule recurring runs so regressions surface before users find them. The cost is roughly three times the test call volume.
11. Keep designing after launch
Real users will not behave like your test personas. They phone from cars, change their minds halfway through, and ask for things you never scoped. Treat the design document as permanently in draft, and review production conversations grouped by failure type every week.
Cekura monitors production calls and scores them from the same metric library used in testing, so a failure found in production can become a test that measures the same thing. Cekura's Deep Research feature audits a window of production calls for failure modes nobody wrote a metric for, and returns each finding with a suggested fix and example calls. Turn each confirmed finding into a new test scenario, and the agent improves with every review cycle. The cost is an owner, someone accountable for that weekly review.
Where to start
If you adopt only three of these best practices in conversational AI design this quarter, pick repair (5), read-back (7) and repeated-run testing (10). They catch the failures users feel most, and none of them depends on a model or infrastructure change. Cekura tests, monitors and improves voice and chat agents against exactly these practices, and you can see how it works on your own agent.
Frequently asked questions
What is conversational AI design?
Conversational AI design is the practice of deciding how an automated agent talks, listens, recovers from misunderstandings and hands off to people. For LLM agents, it means writing the goals, persona, constraints and tool contracts the model works within, then testing that the generated conversations behave as intended.
What are the most important conversational design best practices?
The most important conversational design best practices are defining a checkable outcome for every task, designing repair and handoff before the happy path, and confirming critical values before acting on them. For voice agents, add turn latency and barge-in handling. Test each practice across repeated runs, because one passing conversation proves little.
How fast should a voice agent respond?
As fast as your stack allows, because human answers to yes-or-no questions follow the question by about 200 milliseconds on average across languages. Production voice agents in Cekura's voice quality benchmark had median turn latencies of 2.38 to 3.76 seconds, so short first sentences and well-tuned endpointing matter more than any single model choice.
Should an AI agent always say it is an AI?
Yes, in the first turn. Article 50 of the EU AI Act requires that people be told they are interacting with an AI system unless it is obvious, at the latest at the first interaction. Early disclosure also sets honest expectations about what the agent can do.
When should a conversational agent hand off to a human?
Hand off after a failed repair attempt, when the user asks for a person, or when the task falls outside the agent's scope. Research on repair preferences found users favor a human mainly after the agent's first recovery attempt fails. Pass the full conversation state so the user never has to repeat themselves.
