> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Channels and the chat board
> Organize Studio conversations by channel, control channel context and tools, and track work on the built-in chat board.
Channels give a group of conversations one operating context. A channel can be personal or shared, can have its own members and AI grounding, and can limit which tool families Copilot may use. Use channels for a customer, service, incident stream, or operating function where the same people and guardrails should apply repeatedly.
The chat board turns conversations in the active channel into a lightweight work queue. It is useful when a conversation represents work to track, not just a question to answer.
## Personal and shared channels
| Channel kind | Best for | Who can see it |
| ------------ | --------------------------------------------------------------------------- | ---------------- |
| Personal | Scratch investigations, private notes, and work that is not ready to share. | You. |
| Shared | Team operations, customer work, incident coordination, and durable queues. | Channel members. |
The channel switcher sits above the chat list. Switching channels changes the conversations, suggested context, members, and effective tool policy available to new work. It does not change the active Altostrat organization.
Always check both the organization and channel before approving an external or state-changing action. A correct host in the wrong customer channel can still use the wrong context or policy.
## Create a channel
Select the current channel above the conversation list, then choose the create action.
Pick a personal channel for private work or a shared channel for a defined group of organization members.
Use a name people will recognize in search and the switcher. Add an icon and concise purpose when several channels have similar names.
Open channel settings before operational use. For a shared channel, add only the members who need its context and resources.
## Channel settings
Channel settings are divided into five sections.
| Section | What it controls |
| ------------ | ----------------------------------------------------------------------------------- |
| General | Channel name, icon, and descriptive fields. |
| Members | Channel membership and the channel role for each member. |
| Tools | Capability families and individual tools available to conversations in the channel. |
| Your context | Personal grounding that applies to you inside this channel. |
| Advanced | Administrative actions, including archiving the channel. |
Channel owners and admins can edit shared-channel settings. Members can view the channel and maintain their own context where policy permits.
### Roles
| Role | Typical responsibility |
| ------ | --------------------------------------------------------------------------------- |
| Owner | Owns the channel boundary and can manage all settings and membership. |
| Admin | Maintains members, tool availability, and channel configuration. |
| Member | Participates in conversations and uses the tools allowed by the effective policy. |
An organization role and a channel role are separate. An organization admin is not automatically the owner of every channel, and channel membership does not grant organization-administration access.
### Tool policy
The **Tools** section enables capability families such as host operations, connectors, procedures, planning, and Studio management. Channel policy is a ceiling: it can narrow organization policy, but it cannot re-enable a tool the organization has disabled.
Effective access is layered:
1. The organization makes a built-in domain, connector, MCP server, or individual tool available.
2. Member policy can preload or further restrict tools for a person.
3. The active channel can narrow the set again.
4. A digital worker stage can narrow its own grants below the channel ceiling.
Changing policy affects which tools are offered and which calls the runtime will dispatch. It does not place missing personal credentials into a member's Key Chain.
### Context
Channel context is grounding, not a secret store. Use it for the customer's operating rules, naming conventions, escalation path, environment boundaries, and definitions that should shape every conversation in that channel.
Good channel context is specific and stable:
* "Production changes require a linked change record and a peer approval."
* "Use the `customer-a-prod` connector for this channel; do not query the lab tenant."
* "All times in incident summaries must be UTC."
Do not paste passwords, tokens, private keys, or recovery codes. Use [Key Chain and managed credentials](./connectors-and-mcp) instead.
## Work with conversations
New chats start in the selected channel. The composer shows the current channel so you can catch an incorrect scope before sending. From the chat list you can rename, pin, archive, or set the conversation status.
The supported statuses are:
* **No status** — ordinary conversation or untriaged work.
* **Processing** — Studio or a teammate is actively processing it.
* **In progress** — accepted work that is not finished.
* **Cancelled** — intentionally stopped.
* **Done** — completed work.
## Use the chat board
Open **Chat board** from the channel menu. The board groups conversations by status. Drag a card to another column to update its status, or open the card to continue the conversation.
Use the board for queues where the conversation is the work record:
* Incident investigations awaiting evidence.
* Customer requests moving from triage to action.
* Maintenance tasks that need approval or follow-up.
* Digital-worker items that pause for human judgment.
Keep status meaning consistent within a channel. If **Processing** means "automation is running" for one team, do not also use it for "waiting for customer."
## Archive a channel
Archive a channel when the operating stream is no longer active. Archiving removes it from normal switching without rewriting its history. Review active conversations, scheduled work, integrations, and worker bindings before archiving.
## Related
Manage organization-wide members, context, integrations, and tool availability.
Run staged, trigger-driven pipelines under a shared channel's policy.