Branch vs. Handover in promptflow: Copy the Conversation, or Carry the Context

The summary of the earlier work was right there on the screen. The AI never received it.

We found this while building Handover in promptflow. After moving from Chat to Debate, the screen showed a summary of the previous discussion, so it looked as if the Debate models were reading it. They were not. The request sent to the models was built from a different path, and the constraints you had agreed on earlier were simply missing.

Two features that look alike

Prompt Flow Studio (promptflow) is a SaaS workspace where you use AI models from several providers in one place. It has four modes: Chat, Compare, Debate, and Co-Draft. This post is not about one mode. It is about two features that let you try another direction without overwriting the conversation you already have: Branch and Handover.

• Branch and Handover are different features. Branch copies a conversation up to a point you pick. Handover carries the key points of the work into another mode.
• Branching never changes the original conversation. Anything goes back to it only after you request adoption and it is approved.
• Context shown on screen is not context delivered. Handover counts only when the context is inside the request sent to the AI.
• What is left out is also decided. Summaries have length caps, and the AIs that review answers in Cross Review get none of the earlier conversation history.

Why two features

We wanted a way to explore with an AI without overwriting the conversation along the way.

Say you are working out pricing for a service with an AI. Halfway through, you want to try both a flat monthly plan and usage-based billing. If you keep writing the second idea into the same conversation, the assumptions of the two options blur together. A new conversation keeps them apart, but then you have to explain again who the customers are, what the cost limits are, and which options you already dropped.

That calls for two operations:

• Try another option from a point in the same conversation. This is Branch.
• Move to another mode and keep working on what you decided. This is Handover.

They look alike, but they work differently. Branch copies the conversation history. Handover summarizes the work and passes it to another mode. They store different data, and they fail in different ways.

If you blur that difference, you miss bugs. Because the earlier summary is on screen, you assume the next AI has it too. In our case, the description shown to the user and the request sent to the AI went through separate paths.

Branch copies the conversation up to the point you choose

Branch is for trying an alternative within the same piece of work. When you pick a message partway through a conversation, promptflow creates a new thread that holds the history up to that point.

Internally, the chosen point is a position counted from 1. If you pick the 10th message, the first 10 messages of each AI conversation are copied into the new thread. If no point is given, the whole history at that moment is carried over. The parent's message array is never modified; a new array is built.

The new thread also records:

• the thread it branched from (its direct parent)
• the top-level thread
• how deep the branch is
• the point it was split from
• its status after branching

Branches can go up to 4 levels deep. A new branch that would exceed that limit cannot be created. With unlimited depth, it gets hard to follow which option came from which.

A Branch appears in the sidebar under its parent thread. At the top of the Branch screen, "Back to parent" takes you back to the parent conversation.

When you send a request in a Branch, only that Branch's conversation is used. Messages from the parent, or from sibling Branches split off the same parent, are not mixed in. If you separated the monthly plan from the usage-based plan and one conversation leaked into the other, there would be no point in separating them.

Bringing work back to the original conversation is not automatic either. A Branch moves from active to adopt_pending, and becomes adopted when approved. Only threads in a parent-child relationship qualify; Branches that share a parent cannot be merged with each other directly. Within one top-level thread, only one Branch can be pending adoption at a time, and a pending adoption expires after 30 days.

These rules exist so that nothing the user did not explicitly approve flows back to the parent. On adoption, only the messages added in the Branch are appended to the parent conversation. The messages inherited from before the split are the same as the parent's, so they are not added twice. When Artifacts come back and the parent already has one with the same name, you choose: take the Branch version, keep the parent version, or keep both. Each Artifact also records where it was copied from.

Creating a Branch leaves the parent alone. Only adoption brings back content, and only content the user has reviewed.

Handover carries the work into another mode

Handover is for moves like going from Chat to Debate, or taking one Compare candidate into Chat for a closer look. The source is usually Chat, Compare, or Debate. As a target, you can pick any of the four modes, or Workflow. Workflow is in Beta, so we do not count it among the four modes. From Workflow results, you can also move to Debate or Chat. Handovers to and from Workflow are in Beta. What gets passed depends on the combination of source and target.

Unlike Branch, Handover does not copy the conversation as it is. It creates a new thread in the target mode and puts structured information into the first system message:

• a summary of the work so far
• background worth keeping
• questions still open
• constraints the next mode must respect
• the request that started the thread
• which mode the work came from

For example, if you compared three options in Compare and take one into Chat, the full text of every candidate is not pasted in. The chosen answer and the points the comparison surfaced are summarized, and you continue in Chat. A handover to Debate needs more than the conclusion: it also needs the unresolved points and the constraints.

We use a summary instead of a full copy so the request in the target mode does not get buried under a long history. The trade-off is that a summary can drop information. Handover is not a feature that "fully reproduces the previous conversation." Quotes and Artifacts you need are kept where you can check them separately.

Shown on screen, never sent to the AI

The problem we found during development was that what Handover showed did not match what the AI received.

You cannot tell from the screen alone.

After moving to Debate, the screen showed a summary of the previous work. The new thread's description named where the work came from. From that alone, it looked as if the Debate participants were reading the summary too.

But the code that built the request to the AI did not read that display data. Debate received a topic and roles, and started as a brand-new discussion. The constraints and open questions settled before the move were not in the AI's input.

The route into Compare had the same kind of problem. A route that only switched the screen to Compare never created a Handover thread. To the user, the screen changed. But with no new thread carrying the earlier context, nothing of it went into the history sent to each model.

This is not a display bug. The AI answers without knowing the premises, and the answers change. Suppose you decided in Chat that "no personal data leaves the company." If that constraint never reaches the Debate input, you get proposals that ignore it.

The screen and the AI input are separate paths. So Handover has to be checked on two points, separately:

1. Does the target thread hold the structured handover data?
2. Does the request actually sent to the target AI contain that data?

Checking that the thread was created does not prove the second point. Neither does checking the description on screen. You have to look at the history or prompt right before it is sent to the AI.

The fix: connect each target all the way to the AI input

The fix starts with one shared routine for creating Handover threads. It puts the source mode, summary, background, open questions, and constraints into the system message and creates a new thread set to the target mode. It also records the link to the parent thread and the handover history.

On top of that, each target got its own connection to the AI input. In Compare and Debate, the top of the screen shows the source mode along with the summary, open questions, and constraints, so you can check on screen what is being passed to the AI.

Into Chat

The summary, open questions, and constraints are combined into one user message placed at the top of the conversation history. The conversation from before the handover itself is not sent.

The history promptflow sends to the AI is capped at the last 20 messages or an estimated 12,000 tokens, whichever is smaller. The first message, though, is kept separately up to 6,000 characters, so the summary at the top stays in the input even as the conversation grows. When messages in the middle are dropped, the AI is told how many were dropped. Their content is not sent.

Into Debate

Right before a debate starts, promptflow reads the Handover system message. The summary, background, open questions, constraints, and first request go into a field called priorContext, which is sent to the Debate API. The API side accepts only strings and arrays of strings, and ignores unknown fields.

The structured handover content goes into the first round, problem_framing, where the issues are laid out. Summary and background together are capped at 4,000 characters. The thread's first request gets its own 4,000 characters, separate from the summary. Open questions and constraints are capped at 10 items each, 300 characters per item.

Every round also receives the contents of Debate's background field, the one you open from "+ Add background and assumptions (budget, deadline, etc.; optional)." If that field is empty at handover, it is filled with text built from the summary, open questions, and constraints. That way the premises set at the start do not fall away as the debate goes on. In the first framing round, to avoid sending the same content twice, only the auto-filled text the user has not edited is left out.

Caps can lose information. Still, compared with passing everything, you can see what was passed, and the topic after the move stays readable. Long material is referenced as an Artifact, and the Handover carries the points the next discussion needs.

Into Compare

Before sending the same question to each model, Compare looks for the Handover system message. It assembles the summary, open questions, and constraints into a handover context block and adds it as user input at the top of the conversation history.

The conditions stay identical across models. If each candidate got different handover content, you could not compare the models. Every candidate gets the same context, followed by the same question.

Into Co-Draft

The carried-over conclusions, open questions, and constraints are laid out under headings and put into Co-Draft's first request. The AI that starts the revision receives the conclusions and constraints decided in the earlier mode as its material.

Cross Review deliberately gets no history

The opposite of handing over is also a feature. Cross Review is not a mode. It is a review action you call on answers produced in Compare, Debate, or Workflow. Other AIs that took no part in the conversation review the answers independently. If they saw the earlier discussion, their review could bend toward the conclusions already reached. So the reviewing AIs receive only the answers under review, not the earlier conversation history.

After the review, you can pick the model with the better answer and continue the conversation. Not passing history at review time and being able to continue afterward are separate things.

Not carrying context over is part of the spec. We keep it apart from "someone forgot to implement it" and check it with tests.

Tests check storage and delivery separately

Confirming that Handover data was saved somewhere does not tell you whether it reached the AI. So the regression tests are split at each processing boundary.

First, when a new Handover thread is created, the tests confirm that the source, summary, open questions, and constraints are in the system message. Next, a debate is started and the tests confirm that the payload sent to the API contains priorContext. They also confirm that the structured handover content lands in the first framing round, and that the auto-filled background text is not added twice in that round. Passing an overly long summary and too many items checks that the caps hold in both the API and the prompt builder.

For Compare, the tests confirm that the same history built from the Handover thread goes to every candidate. They also cover the route where the target thread is created, not just the screen switch. For Cross Review, the tests check the opposite: that no earlier history gets in.

Branch has its own checks. With a chosen point, the new array holds messages up to that count; with no point, all of them; with an empty conversation, it stays empty. The tests also confirm the parent conversation is not modified. For adoption, the parent-child requirement, the number of concurrent requests, the expiry, and the handling of same-name Artifacts are each tested.

Split this way, no one can call it done after checking only the screen, only storage, or only the AI input. Both what the user saw in the handover and what the AI received get checked.

Choose by what you want to keep

Whether to use Branch or Handover depends not on the model, but on the history you want to keep.

An example:

To try "shorten the explanation" and "keep the implementation details" from the same point, use Branch. You can take the two histories forward separately. If you then want objections raised against the stronger candidate, hand it over to Debate. To line up revisions from several models under the same conditions, hand it over with Compare as the target. If, after the handover, you want critique from AIs that know nothing of the conversation so far, run Cross Review on the answers. The reviewing AIs get none of the earlier conversation history.

In that order, the options you tried, the reason you switched modes, and the independent critique are kept apart. Compared with piling everything into one long conversation, it is easier to check later which premises a conclusion came from.

Adoption does not mix parent and Branch automatically either

Even when a Branch produces a good option, it needs review before it goes back to the parent. The Branch may not include changes made in the parent in the meantime. There may also be a different version of an Artifact with the same name.

So the pre-adoption review shows the summary, conclusions, decisions taken, next steps, references, and the number of Artifacts. It does not proceed if the threads are not parent and child, if another adoption is already pending, or if the Branch is in a status that does not allow it.

When an Artifact with the same name exists, the user chooses what happens:

• replace it with the Branch version
• keep the parent version
• keep both under different names

Artifacts already copied from the same Branch are not added again. The source thread and source Artifact are recorded.

When a conversation is adopted, only the messages added in the Branch are appended to the parent, and the result is re-sorted by time. Messages shared from before the split are not duplicated. Conversations that started only inside the Branch are added to the parent as a whole. The parent conversation changes only through the explicit act of adoption.

Limits

This design has limits.

• A Handover summary is not the full text. A poorly made summary can drop a condition that mattered in the earlier work.
• More Branches mean more housekeeping. Even within 4 levels of depth, vague names and unclear reasons for adoption make them hard to tell apart.
• Adoption does not resolve contradictions for you. If the parent and the Branch reached different conclusions, the user decides which to keep.
• What you get depends on your plan. Which plans include Branch management and each Handover route is listed on the pricing page and the Handover feature page.

The short version

Keeping a conversation and passing on its context are not the same thing. Branch copies the history. Handover delivers the key points all the way into the request sent to the AI. Choose between them by the history you want to keep.

Terms

• Thread: one conversation in promptflow, grouped as one piece of work. Creating a Branch makes a thread separate from the parent thread.
• Artifact: an output from your work with the AI, such as a document, table, or code. It is saved separately from the conversation.
• System message: a slot in the conversation, separate from what the user and the AI say, used to state premises. Handover puts the handover data here.
• priorContext: the name of the field, sent to the Debate API, that bundles the handover data.
• problem_framing: the name of Debate's first round, where the issues on the topic are laid out.
• Adoption: bringing work done in a Branch back to the parent thread, after a request and approval.

This series shares practical knowledge from building and operating our flagship SaaS, Prompt Flow Studio, and other AI products. If you are interested, please like and follow.

Prompt Flow Studio is a multi-AI workspace where you use, compare, and debate multiple AIs on one screen. Learn more at https://prompt-flow.studio
Our other products are listed at https://www.eln.ne.jp/products

EarthLink Network builds its own products to run the whole company on AI — each one born from a need along the way. See the full index of what we build:

→ The 18 products EarthLink Network builds in-house

For more about the company and each product, visit www.eln.ne.jp.