A session with an agent rarely runs in a straight line. You try a direction, it turns out to be a dead end; you want to compare two approaches to one task; and then a successful session has to be shown to a colleague. In essence it is a branching exploration, and treating it as a linear feed means fighting its nature. The tool acknowledges this: it has separate actions for rollback, branching and sharing, and they are worth using for their purpose.
The naive move is to run everything in one continuous conversation: rewind the failures by hand, try the alternative right there, and to share, copy the session text and send it. While there is one hypothesis, this is tolerable. But the moment you want to compare two branches or show the history outward, the linear model starts to get in the way.
It breaks in three places at once. Two hypotheses poured into one history become unreadable: you cannot see where one approach ended and the other began. A manual rollback in the middle of a working agent is unreliable - it is unclear what exactly was undone. And a raw transcript sent to a colleague carries outward what you did not mean to show: paths, secrets, machine-side content.
The first mechanism against this is revert. It returns the session to a chosen turn, and in version 3.7.16 it is made reliable mid-turn: the revert buttons appear as soon as a prompt is sent, and reverting while the agent is working first cancels the current turn and then rewinds. This removes the main unreliability of a manual undo - you do not guess whether the agent managed to do something between your decision to revert and the revert itself. This turns a rollback from a risky gesture into a predictable operation: you always know which turn you returned to and what was cancelled in the process.
The second mechanism is duplicate. Duplicate session, like send as fork, opens a branch of the conversation in a new tab, keeping the original open. This is a direct answer to mixed hypotheses: instead of trying an alternative on top of the current history and then separating them, you fork it into a separate tab and run it in parallel. Two branches live side by side, each with its own clean history. A fork is handy as a way to preserve a good point, too: from it you branch off a risky experiment without risking the main branch of the conversation.
The third mechanism is Share Conversation. In 3.7.16 it uploads a sanitised transcript: system prompts and tool definitions are dropped, secrets redacted, paths normalized, and the link is visible to the team. Sanitisation strips the machine part of the conversation - what the system and the tools inserted - and that is the right hygiene for something shared inside a team. A link rather than a file also means access is defined by the team's audience, and that too is worth being aware of before publishing.
But it is exactly here that you must understand the boundary of the cleanup, or it will deceive you. Sanitisation strips machine content but does not touch what people wrote: your own messages and the attached context remain as they are. If you pasted into the prompt a fragment with an internal address, a key or a sensitive wording, redaction will not catch it - it is in the human part the mechanism does not rewrite. Redaction works on machine fields and known secret patterns, while free human text does not always fall under those patterns.
These actions also have a cost worth remembering. A fork multiplies the sessions you must track: having spawned branches, it is easy to lose which one is the main one. A revert mid-turn cancels work in flight - it is a deliberate step, not a free "back" button: you agree to lose what the agent managed to do in the cancelled turn. So both a fork and a revert are decisions, not reflexes: each has its own cost in the form of extra branches or a lost turn.
You must verify before, not after. Before sharing, re-read the human messages and the attached context with your own eyes - it is precisely those that the cleanup does not touch. Before forking, confirm you are branching from the intended turn, not a random one. And keep in mind which branch is authoritative, so as not to later assemble the truth from half a dozen nearly identical tabs. One habit closes most of the risk: before sending a link, re-read not the machine part but exactly your own part of the dialogue.
The typical failures follow from here. The first is sending a sanitised link in the belief that redaction covered everything, and carrying outward what you yourself wrote into the prompt. The second is reverting and losing work you actually wanted to keep, because you did not notice the revert cancelled the current turn. The third is making so many forks that no branch counts as the main one. The sign of all three is the same: the mechanism was used, but the very part it does not check for you was not checked by hand.