> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizing work

> How work is organized in ReasonOS: the branch is the unit of work, and everything about that work — tasks, plans, chats, agent memory — is committed with it and travels through git.

ReasonOS organizes work around one idea: **the branch is the unit of work**.
Every active branch gets its own branch node — a live, shared development
environment — and everything *about* the work on that branch (its task board,
the plans the agent drew up, the conversations that shaped the change, what the
agent learned along the way) is stored in the **committed `.reasonos/` tree**,
so it moves through git with the branch itself.

This page is the map: what the work record contains, where each surface lives
in the ReasonOS editor, and how humans and agents share them. The deep dives
are the [task board](/workflow/task-board), [collaboration](/editor/collaboration),
and [coding agent](/agents/overview) pages.

## A branch is the unit of work

When you open a branch in the ReasonOS editor, you connect to that branch's
node. There is no separate "join a session" step — everyone who opens the
branch lands in the same live environment, and switching branches means
connecting to a different node, never checking out over anyone's working tree.
Pick a branch from the top bar and the editor navigates there.

That model splits the state of your work in two:

* **Live state stays on the node** — the working tree, running builds and dev
  servers, agent sessions in flight, presence, chat rooms, meetings. Nodes are
  ephemeral: one can be stopped, rebuilt, or replaced without losing anything
  that matters.
* **The durable record is committed** — everything worth keeping lands in the
  `.reasonos/` tree at the workspace root and travels with the branch through
  git, not with any server or laptop.

## What travels with the branch

The committed `.reasonos/` tree is the branch's work record:

| Path                     | What it holds                                                                                                       |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| `.reasonos/tasks/`       | Task cards — the branch's kanban board, one folder of JSON cards per branch plus a shared backlog                   |
| `.reasonos/tasks.rbs`    | Optional board configuration: columns, WIP limits, the prompt an agent gets when it picks up a card                 |
| `.reasonos/ai/chats/`    | Agent chat sessions — JSON plus a readable Markdown mirror of each conversation                                     |
| `.reasonos/plans/`       | Plan files — Markdown checklists produced by planning work                                                          |
| `.reasonos/memories/`    | Agent memory notes                                                                                                  |
| `.reasonos/ai/`          | The agent's learned memory: lessons about this codebase, style ("taste") preferences, and Atlas work-memory records |
| `.reasonos/infra/state/` | Infrastructure state for the workspace                                                                              |

Because the record is committed:

* **Push the branch** and a teammate — or a freshly provisioned node — gets the
  full history: the board, the conversations, the plans, what the agent
  learned.
* **Merge the branch** and the record merges with it, landing in trunk as a
  durable account of how the work happened.
* **Nodes stay disposable.** Per-server ephemera — build outputs, toolchains,
  checkpoints, notifications — live in the gitignored `.rbs/` directory and
  never leave the node.

<Note>
  [Checkpoints](/workflow/checkpoints) are the deliberate exception: they are
  per-node safety snapshots for undoing agent changes, not part of the branch's
  committed record.
</Note>

## Tasks: the board on the branch

The **Tasks** view (top bar, next to Code) is a kanban board of the work being
done on this branch — deliberately not a company-wide project tracker. By
default it shows cards for the current branch plus the unassigned backlog, with
an all-branches filter when you need the wider view.

Cards carry a description, an ordered step checklist, a comment thread, and
links to the plans, memories, and chats that produced them — so a card's
**Linked** section can reopen the exact conversation or plan behind the work.
Drag cards between columns as work progresses; card lifecycle reconciles
against git automatically, so cards for merged or abandoned branches close
themselves.

Two agent-facing actions live on the card itself: **Run with agent** hands the
card to an agent session, and writing `@agent` in a comment gets the agent to
respond — or do the work — in that comment thread. The
[task board guide](/workflow/task-board) covers the board, its `.rbs`
configuration, and the agent workflow in depth.

<Note>
  Don't confuse the board with the **Tasks** checklist that appears inside an
  agent conversation. That in-chat list is the agent's own working checklist for
  the current run — ephemeral and session-scoped. Work that should outlive the
  session belongs on the board.
</Note>

## Plans and plan mode

Plan mode separates *deciding what to do* from *doing it*. The agent chat
header has a toggle that switches the session between **Agent** and **Plan**;
in plan mode the agent can read code, search, and reason, but editing files and
running commands are refused outright — investigation only.

While planning:

* **Plans appear as cards in the conversation**, marked read-only: the goal, a
  checklist of steps with statuses, and priorities. Updates stream in as the
  plan evolves.
* **The agent asks structured questions** when it needs a decision from you —
  option pickers or free-form answers, right in the transcript. The agent
  waits for your answer before continuing.
* **Finishing is an explicit gate.** When the plan is concrete enough to act
  on, the agent presents it and asks to start work. You can approve, approve
  while letting file edits proceed without further prompts, or send it back to
  keep planning — with your feedback.

Plan files live under the committed `.reasonos/plans/` tree and can be linked
to task cards, so the design travels with the branch alongside the code it led
to.

## Chats: the conversation record

Agent conversations happen in the editor's AI pane — multiple tabbed chats,
streaming responses, and a **Previous conversations** history you can reopen
and resume. Sessions run on the branch node, not in your browser, which makes
them shared by construction: anyone on the branch can browse the history and
pick up a conversation the agent had with someone else.

Saved sessions persist to `.reasonos/ai/chats/` as JSON with a readable
Markdown mirror, so the reasoning behind a change is reviewable in the repo —
in a diff, in a code review, or from a future session on the same branch.

The node also hosts **team chat rooms** for the humans on the branch — text,
code snippets, and file sharing with typing indicators. Room history lives on
the node for the life of the session; the durable, committed record of the
work is the agent chats, plans, and task comments.

## Meetings and presence

Presence is ambient in the editor: the top bar shows who is connected to the
branch node, the file explorer marks which files each person has open (click to
open the file and join them), and with collaborative editing enabled you see
each other's live cursors and selections. The node also hosts **meetings** —
video calls with screen sharing between people on the branch, in a windowed,
fullscreen, or collapsed layout. See [Collaboration](/editor/collaboration)
for the full picture of what's shared on a node and what stays yours.

## How agents take part

Agents are participants in the same record, not a separate system:

* **They work the same board.** Agent sessions carry task tools that read and
  write the very board the editor renders — checking off steps, moving cards,
  commenting, and filing follow-up cards for work they found but didn't do.
* **You can hand them work two ways**: **Run with agent** on a card seeds a
  session from the card and keeps the session linked to it, and `@agent` in a
  card comment gets an answer — or the work itself — in the thread.
* **They ask instead of guessing.** Questions the agent posts on a card, and
  agent run outcomes, arrive in the editor's notification center and deep-link
  back to the card or the chat session.
* **They remember for the branch.** Lessons and taste the agent records are
  committed under `.reasonos/ai/`, so every future session on the branch — no
  matter who starts it or which node runs it — begins knowing what earlier
  sessions learned.

See the [coding agent overview](/agents/overview) for engines, tools, and
memory in depth.

## Above the branch

The branch board tracks "work on this branch" by design. Cross-project work
management — per-project boards and cycles, organization-wide initiatives, and
a personal review inbox of change requests waiting on you — lives in the
managed ReasonOS platform's Work suite, which links down to branch-level work
rather than replacing it.

<Note>
  ReasonOS is pre-release. The platform Work suite ships with the managed
  platform and is not served by the branch node itself; the branch-level surfaces
  on this page are what you get from any node, managed or self-run.
</Note>

## Learn more

<CardGroup cols={3}>
  <Card title="Task board" icon="kanban" href="/workflow/task-board">
    The branch board in depth: cards, lifecycle, configuration, and running tasks with the agent.
  </Card>

  <Card title="Collaboration" icon="users" href="/editor/collaboration">
    Presence, co-editing, chat and meetings, and the shared-vs-personal split on a branch node.
  </Card>

  <Card title="Coding agent" icon="bot" href="/agents/overview">
    The agent that shares your branch: engines, graph-first tools, sessions, and memory.
  </Card>
</CardGroup>
