## 1\. Understand the fork

### One conversation branches\; one workspace remains shared

A tan is a **separate\, contextual agent conversation** created from Main’s persisted conversation history\. It receives a new work request and can run concurrently with Main\.

It is tool\-capable—not merely a second text answer\. Depending on the tools available when it is constructed\, it can read files\, edit them\, execute work\, and use other enabled capabilities\.

The useful mental picture is\:

> **Two conversations\, potentially two active workers\, one shared working directory\.**

The conversation fork does **not** create an isolated checkout\, Git branch\, or worktree\. There is no automatic tan merge operation\. If a tan edits a file in the shared directory\, that edit is already in the directory Main uses\.

### What a tan is not

| Nearby concept | How it differs |
| --- | --- |
| A quick side question | `/btw` uses an ephemeral side\-request path\. Its tool calls are discarded rather than executed\. A tan has a real session and can perform tool work\. |
| An ordinary task subagent | Ordinary task execution starts from a delegated assignment and an agent definition\, with its own model\, lifecycle\, isolation\, and result conventions\. Do not assume those conventions all apply to `/tan`\. |
| Another terminal session | Opening another terminal does not automatically fork Main’s conversation\. Tan registry identities and background\-job rows are process\-local controls\, not universal handles across terminal processes\. |
| A supervised process | A server\, watcher\, debugger\, or REPL managed through the Hub’s process operations is addressed by a project\-scoped **process name**\. It is not a conversational Tan agent\. |
| A safe sandbox | Shared directory access and tool permissions still matter\. “Do not edit” is a task instruction\, not filesystem isolation\. |
| A permanent worker | Completion can dispose the live session and leave a parked record\. Revival depends on retained files and available runtime support\. |

### The fork has a task boundary

The initial tan is told that the earlier conversation belongs to its parent and that its own responsibility is the new tangent\.

The controller also clears the **clone’s inherited todo list**\, including a persisted empty todo edit\. It does **not** clear Main’s todo list\.

This reduces a common failure\: a fork sees Main’s unfinished checklist and tries to finish Main’s work instead of its own assignment\.

**Operating recommendation\:** make the boundary concrete anyway\. State\:

1. The desired outcome\.
2. The files it may read\.
3. The files it may change—or that it must not change any\.
4. Work owned by Main or another tan\.
5. What evidence its report must contain\.

---