What is conversation design for AI agents?
Somebody has to decide what the agent says when the refund is declined. That job is conversation design for AI agents, and it starts before any prompt.
Conversation design for AI agents is the practice of deciding what an agent will say and do before anyone builds it: example turns for every situation, the branches where things go wrong, the systems it calls at each step, when it hands off to a human, and the voice it does all of this in. The output is a document the whole project can read end to end, argue about, and approve before anyone writes a prompt or configures a platform.
Written down like that, it sounds too obvious to be a discipline. Most agent projects still skip it. They go from a slide deck that describes the agent straight to a build that interprets the deck, and every argument the deck never settled resurfaces during user acceptance testing, when changing anything costs a sprint. Conversation design is the practice of having those arguments early, on paper, while a change costs minutes.
What does conversation design actually cover?
Five things: example turns, branches, tool calls, escalation, and voice. Everything else in a design document exists to support one of these.
- Example turns. Each situation written out as real turns between customer and agent. “The agent greets the customer and offers help” is a summary; the design shows an example greeting. The examples are where tone, clarity, and legal exposure live, and they are the one thing a stakeholder can disagree with. Nobody can object to a bullet point; anybody can object to a sentence.
- Branches. The happy path is the smallest part of the job. The real decisions sit on the other paths: the API that times out, the customer who is angry, the request that is out of scope, the user probing for a way around the rules. We wrote about this separately in The happy path is not a design.
- Tool calls. An agent answers by pulling data from systems. The design records which system each turn depends on, what gets sent, what comes back, and what the agent says when the call fails. Engineering reads this part first.
- Escalation. The moment the agent stops and a human takes over. Where that moment sits, what triggers it, and what the agent says on the way out are design decisions, and they are the ones executives ask about first.
- Voice. The character that holds the rest together: how formal, how warm, what it never says, how it repairs a misunderstanding. Voice is defined once and then demonstrated in every turn, which is the only way it survives review.
Who does conversation design?
Mostly, people whose job title says nothing about conversation. Three groups do the bulk of it.
- Business analysts, product managers, and product owners inside companies putting an agent in front of their own customers. For many of them it is the first serious AI project on their desk, and they end up owning the question the steering committee always asks: what does it say when things go wrong?
- Consultants and delivery leads at the agencies those companies hire. They turn workshop notes into a design, and they need the client to approve it before the build starts, because “that’s not what we agreed” in month four is a margin problem. We cover that dynamic in Getting a client to sign off on an agent design.
- Solution architects and forward-deployed engineers at the vendors who build and run the agent. They inherit half-described requirements, and every branch nobody decided on becomes their problem two days before go-live.
There is also a dedicated job title. “Conversation designer” grew up around voice assistants and chatbots in the late 2010s, and the people who hold it are very good at this work. There are not enough of them, and most agent projects never see one. The design still has to happen; it gets done by whoever is in the room.
Why did conversation design disappear as a tool category?
Because its flagship tool was acquired and shut down, and nothing replaced it. Botmock, the leading collaborative conversation-design tool of the chatbot era, was acquired by Walmart in November 2021 and closed to the public that December. Voxable, the tool positioned as the migration path for Botmock users, pivoted away from conversational AI by late 2022.
The practitioners did not disappear; their tooling did. Teams fell back to spreadsheets of intents, Miro boards, and prose documents in Confluence or Word, none of which were built for branching dialogue. A spreadsheet cannot show a conversation. A whiteboard cannot be versioned or signed off, and a prose spec means something different to every reader who opens it. The standard stack for designing conversations became three tools that disagree with each other.
The timing was unkind. The category collapsed roughly a year before large language models turned chatbots into agents and made the design problem an order of magnitude harder. The industry met that harder problem with less dedicated design tooling than it had in 2021.
Why do AI agents raise the stakes?
Because agents act. A 2019 chatbot classified your sentence into an intent and returned a canned reply; the worst case was an unhelpful paragraph. An agent calls tools. It looks up an order, files a claim, issues a refund, changes a booking. It has side effects. A wrongly designed chatbot said the wrong thing. A wrongly designed agent does the wrong thing, in a real system, on the record.
Agents also improvise. A scripted bot could only say what someone had written; a language model will generate something in every situation, including the situations nobody designed. That changes what the design is for. It still supplies example turns; its new job is drawing the boundaries. Which lines are fixed (a compliance disclosure, for instance), where the agent may paraphrase, what it must never offer, and what happens on every failure path the team could think of. An undesigned branch still gets an answer: the model fills it with something, and nobody will have decided what.
How is it different from prompt engineering and flow building?
They answer different questions at different stages. Conversation design decides what the agent should say and do. Prompt engineering coaxes a model into doing it. Flow building wires it into a runtime. A healthy project needs all three, in that order; trouble starts when the second or third is asked to stand in for the first.
| Conversation design | Prompt engineering | Flow building | |
|---|---|---|---|
| What it decides | What the agent should say and do, including when things fail | How to make a model produce the agreed behaviour | How that behaviour runs on a platform |
| When it happens | Before the build | During the build | During the build |
| Who does it | Analysts, product managers, consultants, architects | Engineers and applied-AI specialists | Platform engineers and builders |
| What it produces | A document anyone can read and approve | System prompts and evaluation sets | A configured, running agent |
| If you skip it | Undecided behaviour surfaces during UAT | The agreed design never reliably happens | Nothing ships |
The longer comparison, including why prompt engineering keeps getting asked to do design work it cannot do, is in Conversation design vs. prompt engineering.
What does a good conversation design contain?
Six things, as a minimum.
- Real example turns, alternating between customer and agent.
- Branches labelled by what they are for: happy, edge, sad, and adversarial paths.
- A contract for every tool call: which system, what goes in, what comes back, what happens on failure.
- Explicit escalation points, with the hand-off turn written out.
- A short brief holding goal, scope, audience, and voice, so every turn can be judged against something.
- An approval trail, so “we agreed” points to a dated version.
We keep a worked breakdown of these sections in A conversation design template that survives contact with engineering, and the product page shows what each one looks like as a living document.
We built Klate because we did this work for years in tools that were never made for it, and watched good designs die in spreadsheets and slide decks. Klate holds the whole design in one versioned document: turns, branches, tool calls, escalation, and a record of who approved it and when. If this work is on your desk right now, start it in Klate. The free plan holds five designs.
