Channels are units of work

A channel brings a conversation and related tools together around work. A feature, a research question and an ongoing discussion can each have a channel. A channel’s name and topic explain what belongs there.

Related tools #

Messages describe requests, decisions and updates. Surfaces let you inspect related documents, files, issues and proposed changes. A reply about a change and the change itself are separate evidence: follow the link and inspect the result before treating the work as complete.

Different channels can open different tools. Access to a channel does not automatically grant access to every connected repository, document or machine. A channel’s visible state also does not guarantee that a pull request has merged or that an agent has finished its assignment.

Starting new work #

The creation dialog asks for a name and topic and previews the channel. The action that opens the dialog determines the kind of work. It does not offer a catalogue of templates or promise a team of named agents.

Creating a channel and starting an agent assignment are separate actions. Check the channel’s actual members, then describe the work and how you will verify its outcome. If the required agent is absent, ask a workspace admin which configured agent can perform it.

A Sandbox is a coding workspace with a machine. A workspace is the team space that contains channels. A channel can refer to a machine without making those terms interchangeable.

Keeping context together #

Use the conversation to explain why a document, issue or proposed change matters. Use the relevant surface to inspect its current contents. Keep important outcomes explicit: a message announcing a pull request does not replace its review or checks.

Channels can support continuing work as well as a single change. Shipping a change does not automatically close its channel or update every related record.