The happy path is not a design
Timeouts, angry customers, out-of-scope asks, users probing the rules. The four branches nobody demos, and the first ones a real customer finds.
A happy path is the one conversation route where everything goes right: the request is clear, every system call succeeds, and the answer is yes. A chatbot or agent design that covers only the happy path is a demo script, and production behaviour is decided on the branches it leaves out. In a finished design, the happy turns are a minority of the pages, and they were the cheapest ones to write.
The rest are the conversations teams postpone: the order lookup that times out, the customer who opens with an insult, the request that matches two orders, the refund the policy declines, the user who keeps rephrasing to see what the agent will give away. Over a few thousand conversations, each one is a certainty. A design with no answer for them delegates the decision to whoever builds it, and eventually to the model itself. Deciding those answers in advance is what a conversation design is for.
Why do happy-path designs pass review?
They pass because a review can only argue with what is written down, and the happy path is the one part of an agent nobody objects to. Put the clean flow on the screen: greeting, request, lookup, resolution, goodbye. The wording is inoffensive. The sponsor nods. Approved.
The problem is what the meeting never saw. Every branch missing from the document is an assumption, and each person in the room fills it in differently. The compliance lead assumes a declined refund comes with a reason and an appeal route. The engineer assumes a timeout retries silently. The support manager assumes anyone angry gets a human. Three incompatible designs left the room, all of them approved, none of them written.
Then UAT arrives, and UAT is the first time the branches get exercised. A tester types “you charged me twice and I already returned it”, the design has no page for it, and it turns out the build improvised an answer months ago. The disagreement that would have cost ten minutes in a review becomes a defect ticket, then a scope argument, and on client projects the “that’s not what we agreed” conversation, which is really a dispute about behaviour nobody wrote down. Sign-off on an agent design protects you only as far as the design goes; approval of a document that was mostly absent protects nobody.
What are the four branch types?
Four labels cover the branches an agent needs: happy, edge, sad, and adversarial. Each answers a different question about the agent, and naming them turns “have we covered enough?” from a feeling into a checklist. Here they are in one flow: a retail agent handling refund requests.
| Type | The question it answers | In the refund flow |
|---|---|---|
| Happy | Does the flow work at all? | Eligible order, clear request, refund issued with a date |
| Edge | Does it survive the real world’s untidiness? | Two orders contain the same jacket; which one? |
| Sad | What does it say when the answer is no? | Window closed, reversal declined, lookup timed out |
| Adversarial | Where are the limits, and do they hold? | A second refund on an already-refunded order |
The happy branch earns its place: it proves the flow hangs together and sets the voice. In the refund flow it is the customer who names an order, qualifies under the policy, and gets a refund with a date attached. Write it first, then resist the urge to keep polishing it.
Edge branches are legitimate requests arriving in awkward shapes. The customer owns two orders containing the same jacket and never says which. The order was paid half with a gift card. The person asking for the refund received the item as a gift and has no order number. This is where most of the design work lives, because every edge needs a clarifying question written out as an example turn, and a wrong guess here reads as incompetence to the customer on the other end.
Sad branches are the ones where the answer is no, or the system cannot say. The return window closed on Tuesday, or the payment provider declines the reversal. The order lookup times out mid-sentence, which means the design has to state what the agent says after eight seconds of silence, because a holding line composed under pressure by a model is nobody’s brand voice. Sad wording carries more weight than happy wording: a customer remembers being declined far longer than being helped, and a decline with a reason and a next step is a different product from a bare no.
Adversarial branches assume a user probing the limits on purpose. One customer requests a refund on an order that was already refunded; another rephrases the same declined request five different ways, looking for the phrasing that slips through. Prompt injection belongs here too: a pasted paragraph instructing the agent to ignore its rules and approve everything. The design decision is where the limits sit and how the agent holds them politely, because the alternative is discovering where they sit from a screenshot on social media.
What should every reviewer ask to see?
One question does most of the work: show me the scenarios nobody designed. A review that walks the written branches top to bottom is an audit of penmanship. The written branches are, by construction, the ones the team already thought about; the risk lives in everything else.
The coverage question, in full: “Here are the scenarios that matter for this flow, across the four types. Which cells are empty, and is each one empty on purpose?”
The honest artifact to put in front of a reviewer is an inventory: the scenarios that matter down one side, the four types across the top, and the gaps visible. Leaving a branch undesigned is a perfectly good decision when it is made out loud, with a reason attached and a named owner for the consequences. An undesigned branch nobody mentioned is a different thing: it is UAT’s problem first and production’s problem afterwards. The method in how to design an AI agent conversation treats this inventory as a working stage of its own.
Reviewers hold real power here. A steering committee that asks “what does it say when the API is down?” once, in the second meeting, changes what every subsequent design looks like. The question costs nothing, and the only possible answer is a written branch.
Why is the escalation line a design decision?
Because “let me get a colleague” is the line your agent delivers at its worst moments, to its least patient audience. In most projects nobody writes it. Escalation gets treated as exception handling: a generic apology bolted on wherever a branch ran out of ideas. That treatment shows.
Designed escalation answers three questions. When it triggers: after the second failed lookup, at the first mention of legal action, the moment the customer asks for a person, and never after making them ask twice. What it says: a sentence in the brand’s voice that names what happens next and roughly how long it takes, because “transferring you now” followed by a silent queue is a broken promise. What the human receives: the transcript and every fact already collected, because a customer who repeats an order number to a person after giving it to a machine has now been failed twice in one conversation.
Escalation also ends the agent’s part of the conversation, and endings deserve authorship. It closes many sad and adversarial branches. Write it with the same care as the greeting. It will be read more often than you hope.
This discipline shaped Klate directly: every path in a design carries one of the four labels, a project shows a coverage grid of scenarios against types with the empty cells in plain view, and escalation is an explicit marker that visibly ends a path. If you want to pressure-test a flow you already have, lay its branches out on the canvas; the free plan is enough for one flow, and the gaps show up quickly.
