# Conversation branching: exploring other paths without losing the original > Branching lets you go back to a point in an AI chat and continue another way without losing the original. How it is modeled, how it is shown and when it helps. *Tags: ai, ux, interfaces, conversation* --- > [!info] Quick Definition > **Conversation branching** is the ability to go back to a point in an AI chat and continue along another path, creating a branch, without deleting the original version. The conversation stops being a list and becomes a tree, where only one branch is active at a time. ## Why is a conversation a tree? A conversation looks like a list, but when someone corrects, rephrases or explores, forks appear. They want to see what happens if they ask from another angle, or if they change a constraint halfway through. An article on the tianpan.co blog (April 2026) frames the problem like this: in a linear thread, someone who wants to try a "what if?" must choose between overwriting the message and losing the original, or starting over and losing the context. What people do in practice is copy and paste the old conversation into a new chat. The article proposes borrowing the model of version control: forking is a normal operation that keeps history and allows parallel exploration. That is why branching is not a technical luxury. It is the natural model of a conversation that involves decisions. ## How is it modeled? There are two common ways to store a branched conversation: - **With parent pointers.** Each message is a node with a reference to its parent. Editing or regenerating creates a sibling, and the active path is built by walking from the root to the chosen leaf. - **With copies per branch.** Each branch stores its full history. It is simpler, but it duplicates data. The Trigger.dev documentation, for its branching chat pattern, describes the conversation as a tree of nodes with a parent pointer: messages are immutable, so editing creates a sibling, and the active branch is found by walking from a leaf up to the root. Switching branches means picking a different leaf. (That page is marked as part of a release-candidate SDK version, so its API may change.) A design consequence follows: store explicitly which leaf is active for each chat. If you infer it as "the most recent message", a person who goes back to an earlier branch loses it as soon as they type or reload. One implementation detail affects the experience: when branching, the system should copy or reference only the prefix up to the chosen point and create the branch in a single operation. If the operation fails halfway, the person sees a conversation that does not match what the model receives. ## How is it shown? The most common approach is a small control next to the message that has branches: arrows and a counter ("2 of 3"). It appears only when there is more than one branch. Assistant-ui, in its branching guide, offers that component: it can be set to hide itself when a message has a single branch (the `hideWhenSingleBranch` option), and the previous and next buttons are disabled at the ends and while a response is in progress, unless the runtime supports switching branches during a run. For a few branches, that view works well. With many, a tree in the sidebar scales better, but risks going unused. A reasonable recipe is to show the inline indicator by default, offer a tree view for people with many branches, and allow turning a branch into a new chat, something ChatGPT already offers as "Branch in new chat". That last option matters: a branch that has become the main work should be separable. That way the [[conversation-history|conversation history]] does not fill up with paths the person no longer uses. ## Relation to regenerating and editing Two actions already use branching without calling it that way. [[regenerate-response|Regenerating a response]] creates a sibling branch of the same message, and [[editing-the-prompt|editing a sent prompt]] creates a branch from that point. The difference is what changes: the answer in the first case, the question in the second. ## When should you NOT branch? - **When the conversation is linear by nature.** A data lookup or a translation does not need branches. A branch control there only adds noise. - **When branches have external effects.** If a branch already sent an email or created a record, branching does not undo anything. The interface must warn that the branch does not reverse the action. - **When people want to merge branches.** Merging two paths is much harder than forking, because you must decide which messages survive and in what order. A simpler alternative is to carry a summary or the quoted parts of one branch into the other. It is better to start without merging and watch what people copy between branches. ## Example Illustrative example: a designer discusses the structure of a pricing page with an assistant. At message four, they decide to try a three-tier model instead of two. Without branches, they would have to write the change and lose the two-tier version. With branches, they edit message four and "1 of 2" appears. The original branch is still there. After exploring the new one for twenty messages, they decide to keep it and use "convert to new chat" so the pricing conversation does not mix with other topics. The discarded branch stays available in the history. ## How to test it with real people Before building the full tree, check whether people need it. Give them a task that requires comparing two paths, for example choosing between two drafts, and watch what they do. If they open tabs, copy and paste or rewrite the prompt from scratch, the branch answers a real need. If almost nobody notices the branch control, a simple "go back to the previous version" option may be enough. ## Common mistakes - Showing each branch as a separate chat in the history. - Inferring the active branch from the most recently created one. - Branching without warning that external actions are not reversed. - Offering a complex tree when most people have one or two branches. - Not allowing a branch to be separated into its own chat. ## Sources - [Conversation branching is a first-class primitive (tianpan.co)](https://tianpan.co/blog/2026/04/23/conversation-branching-first-class-primitive) - [Branching conversations (Trigger.dev)](https://trigger.dev/docs/ai-chat/patterns/branching-conversations) - [Message Branching (assistant-ui)](https://www.assistant-ui.com/docs/guides/branching.md) --- Source: https://www.fernandoux.com/en/wiki/ai/conversation-branching/