One-Shot vs Multi-Turn Workflows: Why a Turn in CrossChat Is Not Just One Message

CrossChat is not a standard chat UI with a different skin. That is why we had to revisit a deceptively simple question: what does one conversational turn actually mean here?

In a classic chat, the answer is straightforward. The user asks a question, the model replies, and that turn is over. In CrossChat, one "turn" may contain three model answers, a comparison layer, a judge step, visible intermediate outputs, and only then a final synthesis.

That is why we concluded that follow-up in CrossChat should not attach to the "last message." It should attach to the workflow-run artifact.

Claims Framework

What this article claims: In a workflow-first application, follow-up should operate on the workflow-run artifact, not on the last message. One-shot and multi-turn workflows require different context modes and UI behavior.

What it is based on: Internal CrossChat product and UX analysis against the real workflow engine architecture. No external academic sources; the article is transparently a product design document.

Where it simplifies: The one-shot vs multi-turn categorization is presented as a clear-cut distinction. In practice, users may want to follow up even on workflows classified as one-shot, and the boundary between modes may not always be obvious.

How we arrived at this decision

This was not a theoretical exercise in the abstract. The proposal came out of an internal product and UX review of CrossChat against the real implementation:

the structure of the workflow engine,
the chat UI and step streaming model,
the difference between single-model chat and the workflow route,
and the product promise implied by presenting CrossChat as a workflow-first tool.

In other words, we did not start from a blank page. We started from the actual architecture and tried to align the product language with the technical reality.

Why "last message" is not enough in CrossChat

In a normal chat, talking about the last message makes sense. In a workflow-first application, much less so.

In workflows like Cross-check or CoVe, the last visible output is not the only important thing produced during the run. What often matters includes:

intermediate respondent answers,
disagreement between models,
verification questions,
peer-review comments,
judge output,
or a convergence signal.

If we reduced follow-up to the last text paragraph, we would throw away a meaningful part of the value the workflow created.

At the same time, we do not want to blindly stuff the full raw transcript into every follow-up. That would increase cost, latency, and prompt noise.

That is why we defined three context levels.

Three context levels for follow-up

| Mode | What it means | When it makes sense | | --- | --- | --- | | Final artifact | Only the final output of the last workflow run | When the user mainly wants to continue from the result | | Workflow bundle | A structured summary of the entire previous workflow turn | When the process, disagreements, and intermediate steps still matter | | Full thread | Multiple previous workflow bundles chained together | When the user is building a longer research or decision thread |

The key point is in the second row. A workflow bundle is not a raw transcript. It is a compact representation of the full turn that preserves what matters:

the original prompt,
roles and models,
major steps,
agreements and disagreements,
open uncertainties,
and the final artifact.

That is exactly where CrossChat diverges from normal chat UX. We are not operating on the "last sentence." We are operating on the result of a process.

Which serious workflows should be one-shot and which should be multi-turn

Not every workflow should have the same product mode. Some are fundamentally single-run workflows. Others make sense as an ongoing thread that builds on the previous run.

| Workflow | Mode | Final artifact | Typical intermediate steps | Recommended default follow-up | | --- | --- | --- | --- | --- | | Cross-check | One-shot | final cross-check synthesis + judge conclusion | respondent answers, judge, synthesis | Final artifact | | CoVe | One-shot | corrected final answer after verification | baseline, verification questions, verification, corrected final | Final artifact | | Self-Consistency | One-shot | majority answer / final majority synthesis | multiple samples, majority decision | Final artifact | | ICE | One-shot | convergence synthesis | initial answers, internal iterations, convergence signal | Final artifact | | Council | Multi-turn | expert synthesis with review trail | expert opinions, peer review, chair synthesis | Workflow bundle | | Debate | Multi-turn | adversarial synthesis / judgment | opening statements, rebuttals, revised positions, judgment | Workflow bundle | | Think Tank | Multi-turn | recommendation / action plan | brainstorm, evaluation, synthesis | Workflow bundle |

The most important borderline case is ICE. Internally it is iterative, but from the user's perspective it is still a one-shot workflow. The user does not intervene between internal rounds. They receive a finished output at the end. That is why it should not behave like an open-ended multi-turn chat after completion.

What about the fun workflows

For the fun workflows, we reached a much harder conclusion: all of them should remain one-shot.

| Workflow | Mode | Final artifact | Typical intermediate steps | | --- | --- | --- | --- | | Kim Jong-un Cabinet | One-shot | decree / bulletin / loyalty framing | decree, rewrite, validation, applause | | Trump Chaos | One-shot | cabinet decision + chaos framing | opening, advisors, fake-news event, arbiter | | EU Bureaucracy | One-shot | compromise draft / vote result | positions, amendments, compromise, votes | | Athenian Democracy | One-shot | assembly decree | speeches, voting, decree | | Pirate Republic | One-shot | captain's log / agreed route | captain plan, crew feedback, mutiny vote, final log | | Russian Oligarchy | One-shot | backroom deal + public statement | proposals, bargain, announcement | | UN Security Council | One-shot | final communique | statements, draft resolution, votes, communique | | Survivor | One-shot | winner + final answer | confessions, elimination votes, finale | | Feudal System | One-shot | royal synthesis / delegated plan | decree, duke interpretations, delegated plans | | Populist Rally | One-shot | rally speech + reality check | polling, speech, fact-check |

The reason is not that these workflows have too few steps. Some have quite a lot. The reason is product intent: they are designed as closed simulations or performative runs, not as long-lived expert threads.

What this means for the interface

Once we accept that workflows have different modes, the UI needs to reflect that.

| Workflow type | State after completion | What the composer should do | Primary next action | | --- | --- | --- | --- | | One-shot | the run is complete | hide the composer and switch to a completion state | New question | | One-shot with optional continuation | the run is complete, but continuation is possible | reopen the composer only after Continue from result | Continue from result | | Multi-turn | the run can naturally continue | keep the composer visible | Continue with workflow bundle |

That distinction matters. For one-shot workflows, we do not want to imply that the user is still inside a normal endless chat. We want to make the state explicit: this run is done, and now you have three valid next moves:

ask a new question,
continue from the result,
or rerun the workflow.

For multi-turn workflows, we want to acknowledge that the next question can genuinely belong to the same working thread.

What should be included in follow-up context

This is where we had to be disciplined. Automatically sending the whole thread into every follow-up is not a good default. It is expensive and often unnecessary.

That is why we recommend these defaults:

for one-shot workflows, continue by default through Final artifact,
for Council, Debate, and Think Tank, continue by default through Workflow bundle,
keep Full thread as an advanced option with explicit warning that more context means higher cost and longer latency.

That is a compromise between two bad extremes:

losing context that actually matters,
and blindly resending everything that ever happened in the thread.

Why we ultimately chose this design

The decision rests on four practical reasons.

1. Product honesty

We do not want to pretend CrossChat is an ordinary chat when its value comes from workflow orchestration. The UI should acknowledge that difference, not hide it.

2. The right unit of work

In CrossChat, the core unit is not just a text reply. It is a workflow run with structure, roles, and intermediate steps.

3. Cost and latency

The full thread is not free. Richer context can be useful, but it should be an explicit choice, not a silent default.

4. Better continuation for expert workflows

In Council, Debate, and Think Tank, the path to the answer is often as important as the answer itself. That is why continuation should build on the bundle, not only on the last paragraph.

Conclusion

The important change here is not cosmetic. This is not only about whether the input box stays open after a response.

It is about what we consider one unit of work in CrossChat. In ordinary chat, that unit is a few messages. In a workflow-first product, it is a run that may include multiple steps, multiple models, and its own internal structure.

That is why we ended up with a simple rule:

one-shot workflows should end when the run ends,
multi-turn workflows should support continuation,
and follow-up should rely on the workflow-run artifact, not on the illusion that everything is just ordinary chat history.

That is technically more accurate, product-wise more honest, and easier for users to understand.

Sources

No external sources. This article is based on internal CrossChat product and UX analysis.

Editorial History

Concept: internal CrossChat product and UX review + Codex Version 1: Codex + GPT-5.4 Quality audit (2026-03-23, Claude Code + Claude Opus 4.6): added Claims Framework, verified sources, language polish.