Skip to main content
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, collaboration, and coding agent 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: 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.
Checkpoints are the deliberate exception: they are per-node safety snapshots for undoing agent changes, not part of the branch’s committed record.

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 covers the board, its .rbs configuration, and the agent workflow in depth.
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.

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 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 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.
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.

Learn more

Task board

The branch board in depth: cards, lifecycle, configuration, and running tasks with the agent.

Collaboration

Presence, co-editing, chat and meetings, and the shared-vs-personal split on a branch node.

Coding agent

The agent that shares your branch: engines, graph-first tools, sessions, and memory.