Channels and the chat board

Channels give support agents and the people supervising them a shared operating context. A channel can have its own members, AI grounding, and tool permissions. Use a shared channel for a support queue, customer, service, or operating function where the same people and rules should apply repeatedly. Conversations in that channel use its context and effective tool policy too. 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. The web administration console also places people inside each channel, with digital-worker Agents and their runs available when Digital workers is enabled. The conversation board and worker run board track different records.

​

Personal and shared channels

A Personal channel is provisioned automatically. Its default audience is you, but explicitly sharing a Personal conversation with Everyone makes that conversation organization-visible. Check the conversation’s sharing setting as well as its channel. 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.

​

Create a channel

​

Channel settings

The desktop channel settings surface has five sections. Channel owners and admins can edit shared-channel settings. Members can view the channel and maintain their own context where policy permits.

​

Manage people and agents in the web console

Open Administration → Channels and select a channel. Add → People adds organization members. When Digital workers is enabled, use All, People, and Agents to filter its roster; Agents → Add starts the Create agent flow. If workers are disabled, follow the enablement guidance before creating an agent. Channel Settings opens the channel’s name, shared grounding, and tool configuration. Save these changes before relying on them in a new conversation or worker run. Select an agent to open its Tasks, Workflow, Activity, Outcomes, and Setup views. See digital workers for activation and triggers.

​

Roles

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.

Workers also require a capability supported in cloud execution. Desktop, sidecar, and local-device tools do not become cloud-worker tools simply because the channel allows them. For connectors, cloud agents require an explicit list of allowed endpoints. Open Channel Settings → Allowed tools, expand the connector, and choose the endpoints the agent needs. Allow all for workers creates a list containing the current endpoints when all are appropriate. Enabling the connector alone can make it available to desktop chats while leaving workers with no callable endpoints.

​

Connector-write approvals

Connector writes require a human decision by default. When an agent proposes a write, Studio presents the exact request for an independent authorized channel owner, channel admin, or organization admin to approve. The person who started the run cannot approve that request. To give an agent responsibility for a repeatable action, an organization admin can open Channel Settings → Allowed tools, select the connector, allow the needed endpoint, and enable Workers run this without approval for that endpoint. Save the channel settings. The connector also provides Run all writes without approval and Ask before every write controls; review every affected operation before using a bulk change. New endpoints added later still require review until explicitly allowed to run without approval. This is a channel-level permission for cloud agents using that endpoint. It does not grant a credential, add a tool to a step, or change desktop Copilot’s approval posture. Organization policy and the agent’s allowed tools still apply. Channel managers can tighten the policy by removing exceptions, but only an organization admin can grant a new exception. Choose the policy separately for internal notes, public customer replies, ticket closure, and operational changes. A configured step review is another decision point: Automatic step completion does not turn on connector auto-approval.

​

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

​

Org Brain in a channel

Enable the Org Brain capability only where organization policy permits it. The organization’s owner must also have activated Org Brain and separately enabled answer synthesis for generated answers. Human members can retrieve organization-visible evidence and authorized channel evidence through Org Brain. Channel membership is enforced on the server; being an organization administrator does not automatically grant access to a channel’s evidence. A worker can search organization-visible evidence only, and only if its bound channel grants the tool. It cannot retrieve channel-only or private sources. Private memories are excluded from replies written to shared conversations. A channel does not automatically turn every private chat or Memory into a shared source. See Org Brain for supported sources and citation behavior.

​

Work with conversations

New chats start in the selected channel. Shared conversations show a channel chip in their header; Personal conversations do not. Check the channel switcher and sharing setting 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 — marked canceled for tracking; this does not cancel a worker run.
• Done — completed work.

​

Use the chat board

Choose View as board from the channel menu. The chat 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.

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.” For agent executions, use Tasks in the administration console, the agent’s Tasks view, or Work → Boards. Respond to approvals and questions in Waiting for approval, the desktop waiting on you inbox, or Work → My approvals. Changing a conversation’s chat-board status does not approve, resume, or cancel a worker run.

​

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