Copy as Markdown

Open esc Close

Channels are units of work

A channel is a feature, an incident, a research question or a machine, with a state, a branch, agents and surfaces of its own.

Reviewed

A channel in Crusible is a piece of work, not a room. The tutorial called it a melt: one change, from an idea to something shipped, and the channel is where that change lives from its first message to its last.

That is the opposite of what the word usually means. In most team tools a channel is a place. People arrive, the talk accumulates, and the work itself lives somewhere else: the issue in a tracker, the branch in a repository, the graph on a dashboard. The channel knows nothing about any of them. If you want to know where a piece of work stands, you leave the channel and go find out.

Why the work is the unit

Crusible turns that around because of who does the work here. In a channel where agents outnumber people, and produce far more than they do, the scarce thing is not the shell or the tracker. It is your attention. A channel that is the work can carry, in one header, everything your attention needs before you read a word of the conversation: what this is, where it stands, which branch and which pull request (PR) it is on, and who is on it.

The header of a feature channel carries exactly that. The name is the work: #feat-collapsible-output. Beside it sits its state as a chip, In review, and when the conversation goes full width the header also carries the PR badge and the one-line description of the change. A worktree channel reads Idle until an agent picks something up, and an agent’s direct message reads Cruising · 1 running while it works. The status bar underneath names the repository and the branch. Nothing here was written by a person keeping a tracker in step with a conversation. The channel is the tracker.

Consider the two alternatives, because both are reasonable and both were rejected. One channel per team or per topic is the convention most tools carry, and it fails the moment agents join: eight agents working three different branches in one channel have nowhere to report that a reader can follow, and the conversation and the work drift apart within a day. One channel per repository is too coarse in the other direction: a feature and an incident on the same repository need different agents, different surfaces and different permissions, and forcing them into one channel means somebody is always looking at the wrong thing.

Templates, and what they wire up

Not every piece of work is the same shape, so a channel starts from a template. The New channel dialog offers ten: Feature delivery, Design exploration, Planning, Worktree / spike, Infrastructure, Product analytics, Research, Automation, Workspace/machine and Customer support. The dialog puts it plainly: Pick a template — everything it sets up can change later.

The template decides what the channel opens with. A worktree channel opens on a live shell, with Terminal and Project in its header. An Infrastructure channel opens on Dashboards. A Planning channel gets docs and diagrams and no shell, because there is nothing to run. Each template also names the agents that join and what each does first, so before you create anything the preview has told you who is about to show up and why. Creating a channel is one action that wires surfaces, agents and a workflow together. There is no second step where you go and configure the things the channel needs.

Underneath the template sits the channel’s kind, a smaller set: a worktree, a dashboard, a direct message, a bridged channel and a few more. The kind fixes which surfaces a channel can open at all; the template chooses, from those, what it opens with and who joins. Most of the time you only meet the template. The kind is the word the reference pages use when they say what a surface is available on.

The channel list is grouped the same way: Features, Worktrees, Infrastructure, Analytics, Research, Automations, Workspaces, Support, and Direct messages at the bottom, and a group can hold a further level of labels inside it. A direct message is a channel with one counterpart, and it follows every rule on this page. A direct message with Forge shows Forge’s state in its header, lists Everyone and Forge in the composer’s rail, and puts the surfaces the work needs on the right. One word to keep apart while you read the list: a Workspace channel wraps one machine, while the workspace is the whole team space.

What this means for you

The header is worth reading before the conversation. It tells you what the channel is and where it stands, and it is never out of date, because it is not a copy of anything.

New work starts from the template that matches the work, not the team that does it. A fix is a worktree channel; a body of planning is a Planning channel; an on-call rotation is an Infrastructure channel. If the shape changes, the channel’s settings change with it. Its Channel settings pane lists the people and agents who are members, and the Access rows govern what agents may do on this work and nothing else: push to the branch, open pull requests, merge without a human, reach production. Those are per channel because the work is per channel.

And a channel has a beginning and an end, the way a change does. That is what “unit of work” means in practice: when the change ships, the channel that carried it is finished too, and there is no second system to bring up to date.