Browse docs
Docs

Forks & follow-ups

One thread ships one pull request — forks and detached agents are how work continues after that.

One thread ships one pull request. That's the rule the whole model hangs off, and it's why threads stay reviewable.

The life of a thread

A thread iterates against its preview, publishes by opening a PR, shepherds that PR to merge, and is done. The PR is a publish action, not a save point — your work is already safe on the thread's own branch, committed turn by turn (git & commits).

Once the PR merges, the thread is finished. New scope raised afterwards isn't that thread's job — it belongs to a fork or a new thread.

Forks: shared history, new lane

A fork is a fresh thread that inherits the whole conversation — the full transcript — on its own branch, with its own PR lane. Everything the original thread learned comes with it, so you don't re-explain the problem.

What a fork does not inherit is plan ownership. A fork starts with no anchored plan, which means it can propose a new plan or attach an existing one even when the original thread already shipped one.

Reach for a fork when:

  • The thread already shipped and you want a code change on top of it.
  • You want a different plan than the one the thread owns.

Detached agents: no shared history

A detached agent is a full independent agent with its own chat thread and its own sandbox, freshly branched off the project's default branch. It can't see the spawning thread's branch or its uncommitted work — that's the point. It's for work that legitimately starts from the default branch, not from what you're mid-way through. A detached agent can be set to open its own PR when it finishes with changes.

Choosing between them

InheritsBranches fromShips
ForkThe full transcript, not the planThe thread's branchIts own PR
Detached agentNothingThe default branchIts own PR, if you ask for one
Sub-agentA short briefNothing — it shares the lead's sandboxNothing; it reports back

Fork means shared history in a new lane. Detached means no shared history and a fully parallel effort. A sub-agent isn't either — it's help inside one thread.

Follow-ups as handoffs

Not every next step needs you to start it. An agent can file a follow-up plan: a plan document handed to a new idle thread that owns it, waiting for someone to press Build. The insight that produced it is captured while it's fresh, and the work stays out of the current thread's scope.

That's the pattern to keep in mind — a thread that has shipped doesn't grow. It hands off. Scope moves to a fork, a detached agent, or a filed follow-up, each with its own branch and its own review.