Wizard or conversation

Tags: agents, flows, chat

Use a conversation when you cannot know in advance what the user will ask for. Use a structured flow when you can — when the inputs are a printable list, later answers depend on earlier ones, and something irreversible happens at the end. The version worth building is usually neither: a structured flow that the agent fills in, stopping at a review step the person actually reads.

When to use a structured flow

• You could print the list of required inputs before the user arrives. If you could, print it — the user should not have to guess what the model needs.
• Later answers depend on earlier ones, so order is real rather than cosmetic.
• Something irreversible happens at the end: an email sends, money moves, a record is created.
• The job is one of the few that dominate the logs. Chat is right on day one of every product and stops being right about a month after launch, when four jobs turn out to account for most of the traffic.

When a conversation is straightforwardly better

• The input is genuinely unbounded — writing, analysis, "why is this build failing."
• The user's vocabulary for the problem is better than yours, which is normal for experts using a tool built by non-experts.
• The long tail: if a product supports two hundred rare jobs, building two hundred flows is absurd, and the text box is the only economical interface for the two hundred and first.
• The output is prose the person will edit themselves, so the conversation and the artifact are the same object.

The shape to aim for is a small number of named flows for the jobs that dominate the logs, with a conversation underneath for everything else — not one or the other everywhere.

The decision

The flow worth building

The user says what they want in their own words, once. The model proposes values into the flow's draft — every field it can infer, left visible and editable. The person works the way people actually work with a nearly-right document: scan it, fix the two things that are wrong, press the button.

This beats a pure conversation for a narrow, practical reason: re-prompting is a terrible editing instrument. If the model got one of eleven values wrong, you want to change that value — not describe the change in prose, hope the rewrite preserves the ten that were right, and re-read all eleven to check. Prose is a good way to specify something the first time and a bad way to amend it the fourth. It beats a pure form for the obvious reason: nobody filled in eleven fields.

What a flow has that a transcript cannot

• Draft, not commit. Every step writes to a draft object; the real entity is created once, at the end. Committing each step as you go leaks half-finished records into production data, which is the most common way these flows go wrong.
• A step is an address. The current step lives in the URL, so refresh, browser Back, and sending someone the link all work. There is no address for "the part of the conversation where the price got set."
• Back is lossless, and enforced. Going backwards is navigation, and navigation must not be able to destroy what you typed — so the step controller's back() never validates. That is a policy, not an omission.
• A review step. One screen listing everything about to happen, each line linking back to where it came from. This is the part an agent-filled flow needs most, and the part that disappears entirely when the interface is a transcript.

Three to six steps is the range that works. Below three, a sectioned single form is less clicking for the same result. Above six, drop-off climbs and it starts to feel like a form someone is administering to you.

Grounded in

Poppy, a voice-first assistant for teachers, is structurally a chat app — streaming responses, persisted threads, a two-panel layout. The part that made it usable is the part that isn't chat: the home screen opens on four one-tap actions, because a teacher with ninety seconds and a blank prompt does not have a conversation, they have a staring contest.

The wizard properties above come from an internal pattern library of 18 pages and roughly 13,900 words, ten of which are about a single moment — a change being committed, and what the person does if it was wrong.

Anti-patterns

• The interrogation. A known form asked one question at a time in a chat box. No overview of what is being asked, no way to change answer three, no sense of how much is left, and every reply is a parsing problem you invented for yourself. If you know all twelve questions, showing all twelve is not a worse experience for being less conversational.
• The quiet commit. A conversation that performs a real action mid-stream — sends the email, moves the money — with the confirmation arriving as a sentence in the transcript. No review surface, no single place showing what is about to happen, often no way back.
• Chat as the record. The conversation is the input method. Making it also the record, the editor, and the commit is what breaks.

The test

1. Could you print the list of required inputs before the user arrives? If you could, print it.
2. When the eleventh value is wrong, what does the person do? If the honest answer is "ask again and hope," the interface is wrong regardless of how good the model is.
3. What is the last irreversible thing that happens, and is there one screen showing everything it is about to do? If not, that screen is the next thing to build.

Related patterns

• Design the failure state first — the quiet commit is a failure state nobody designed.
• Undo over confirm — the fix for a mid-stream commit is usually a commit you can take back, not another dialog.

The full argument: Wizard or conversation: when an agent shouldn't be a chat.