Fork the agent, not just the code: branching AI coding sessions

Coding agents are at their best when you let them explore. Try an approach, look at the diff, and if it’s wrong, try another one. The problem is that the usual ways to explore quietly destroy the thing that made the agent useful in the first place, which is everything it has already figured out about your codebase.

You hit this the moment you want to try a second approach. You have two bad options. Start a fresh chat, and you lose all the context the agent built up: the files it read, the constraints it discovered, the dead end it already ruled out. Or keep going in the same session, and now the abandoned attempt is sitting in the history, biasing every future turn and burning tokens on reasoning you decided against. Neither is exploration. One is amnesia, the other is hoarding.

Branching should be a first-class move, the way git branch is. And once you treat it that way, you notice it has two independent dimensions that people constantly conflate: the code you start from, and the context the agent carries. Pick them separately and most of the pain goes away.

Two axes, not one

Code is the working tree the new agent inherits. Sometimes you want a clean slate: a fresh checkout from the base branch, no changes, as if you’d spawned a brand-new agent. That’s what you want when you’re trying a genuinely different implementation and the current code would only get in the way. Other times you want to carry the current working tree forward, uncommitted work included, because the agent has already built something worth keeping and you want the next attempt to start from there rather than from zero.

Context is what the agent knows going in. A fresh chat gives it nothing, which is exactly right when the old conversation would bias the new attempt more than it would help. Full history gives it continuity, so a long-running investigation doesn’t have to be re-explained. And history up to a specific message lets you rewind: carry everything the agent learned up to turn 11, and drop everything from turn 12 onward where it went down the wrong path.

The reason to keep these separate is that they answer different questions. Code is about what exists on disk. Context is about what the agent remembers. A wrong turn in the conversation doesn’t mean the code is bad, and good code doesn’t mean the conversation is worth continuing. When the two are welded together, you’re forced to throw away both or keep both. Splitting them gives you four honest combinations instead of two blunt ones.

Three playbooks

Abstract axes are easy to nod along to and hard to use. Here is what the combinations look like in practice.

The agent went sideways at message 12. It was on track, then it misread a requirement and spent four turns building the wrong abstraction. You don’t want to argue it back on course, because the bad turns are still in the history dragging on every reply. Fork the context up to message 11, take a clean-ish starting point, and retry from just before the mistake. The agent keeps everything it correctly understood and none of the wrong turn. This is the closest thing to an undo that a conversation has.

The code is good but you want a second opinion on the API. The agent has built something you mostly like, but you’re unsure about the interface it landed on, and the chat is long enough that it’s anchored to its own choices. Carry the current code, uncommitted work and all, into a fresh chat. The new agent sees the code with no memory of why it was written that way, so it evaluates the API on its merits instead of defending the path that produced it. A clean pair of eyes on the same diff.

Explore an alternative architecture. You have two plausible designs and no strong reason to prefer one on paper. Fork with a clean base branch and a fresh chat, then describe the alternative. Now you have two agents working the same task from scratch down different paths. Let both run, then read the two finished diffs side by side. A discarded attempt costs almost nothing, and comparing two real implementations is faster and more honest than debating which prompt would have been better.

Carried context has to actually land

There’s a subtlety in “carry the context” that’s easy to get wrong, and it’s the difference between a feature that works and one that only looks like it works.

Copying the old transcript into the new chat so you can scroll through it is not the same as the new agent knowing it. Those are two different audiences. The transcript in the UI is for you, the human, to read. But the agent doesn’t wake up having read its own chat window. If the prior conversation isn’t part of what the model actually receives as input, the new agent is starting cold no matter how much history is displayed above the composer. Carried context that the agent can’t see is just decoration.

The way to make it real, and to make it work across different agent CLIs, is a plain-text digest. Take the prior conversation, messages, reasoning, tool calls and their results, and render it as text. Copy that into the new chat so you can read it, and also fold it into the new agent’s standing instructions so the model reads it too. Because it’s plain text rather than one provider’s session format, it travels: you can carry a Claude Code thread into a Codex agent and the knowledge comes with it. Provider-specific session files don’t survive that trip; a text digest does.

How Fletch does it

Fletch builds forking on exactly these two axes. Every fork picks one option for code and one for context, and the two choices are independent.

There are two places to fork from. Under any finished turn there’s a Fork from here button, which branches the conversation up to that point. That’s the tool for “rewind to just before the wrong turn” and for sending two continuations down different paths from a decision point. In the workspace header, a fork menu offers the whole-workspace variants that carry full history. Between them you get the combinations from the playbooks above: clean worktree or current code, fresh chat or full history or history up to a chosen turn.

Carried context uses the plain-text digest described above. Fletch copies the prior transcript into the new chat so you can read it, and appends a digest of that same history to the new agent’s standing instructions so the agent knows it, which is why context survives a fork even when you fork into a different provider’s CLI.

A fork is otherwise an ordinary agent in its own isolated workspace. It gets the same sandbox, the same model, and the same skills and tools as its parent, and the parent keeps running untouched. So forking costs about what spawning any agent costs, which is to say almost nothing, and that’s the point. When branching is cheap and precise, you stop rationing your exploration and start doing it.