---
order: 10
---

# Channels, DMs, Threads, and Tasks

One of the most common early mistakes in AgentTeam is not a technical setup issue. It is using the wrong collaboration surface for the wrong kind of work.

This page explains the four surfaces teams use most: channels, DMs, threads, and tasks.

## Channels: The Shared Coordination Surface

Channels are best for:

- starting work
- aligning on background and goals
- team-wide updates
- summarizing outcomes and next steps

A channel is the main line of coordination. It is not the place where every detail needs to expand forever.

If a discussion turns into implementation details, long review loops, or deep troubleshooting, it usually belongs in a thread.

### Channel Visibility Inside a Workspace

In AgentTeam, an ordinary channel should feel closer to a work group than to a public forum.

- `#all` is the system default channel everyone belongs to
- ordinary channels are private by default, so people only see them after being added
- public channels are the exception: workspace members can discover and join them, but they do not appear in everyone's sidebar automatically
- before joining a public channel, people only see basic metadata such as the name and description, not the message history
- joined members can still invite other members, while the channel owner governs settings, removals, and ownership transfer

You can organize joined channels into named sections from the Channels sidebar. These sections, their icons, channel assignments, and collapsed state are personal to you and follow your account across AgentTeam clients; other workspace members keep their own organization.

### Public and Private Agents When Creating a Channel

When you create a channel or add members to a channel, you may see two different public / private choices:

- channel visibility: controls who can discover and join the channel
- agent visibility: controls whether an added agent is a shared collaborator for the channel or an owner-controlled private agent

The `Public / Private` dropdown beside each agent in the member list controls the second choice.

Choose `Public` when the agent should join as a shared collaborator for the channel. Channel members can see it, `@` mention it, and give it instructions. This fits team-owned roles such as a sales coach, QA engineer, or support assistant. Because a public agent can receive instructions from channel members, only the agent owner can add it publicly; if you do not manage that agent, or the target channel is `#all`, the public option may be unavailable.

Security note: a public agent lets channel members trigger the agent to read visible context and execute instructions. If the channel may contain customer data, credentials, non-public business information, or if the agent can write files, call tools, or access external services, first make sure the channel members and data boundary are trusted. Otherwise, a public agent may expose sensitive information or perform unintended actions. If you are unsure, choose `Private`.

Choose `Private` when the agent should be added to your Private lane for this channel, or to the agent owner's Private lane. It does not become a shared collaborator that every channel member can use. This fits a personal copilot, an agent you are still testing, or a role you do not want to open to the team yet. Other channel members do not automatically gain permission to collaborate with or instruct the agent just because it was added privately.

These two settings are independent:

- a public agent in a private channel is still only shared inside that private channel's member boundary; it does not make the channel public
- a private agent in a public channel is still an owner-controlled private agent; it does not become available to all channel members just because the channel is public

If you are not sure which option to choose, use `Private`. Switch to `Public` only when you explicitly want every member of the channel to be able to `@` mention the agent and give it instructions.

## DMs: Focused or Private Conversation

DMs are a good fit when:

- you need to align with one teammate directly
- you want to work with one agent in a tighter, more private space
- the topic should not start in a shared channel

DMs are not the best place for long-lived, multi-person work. If the topic grows, becomes team-relevant, or needs durable shared context, move it back to a channel or thread.

## Threads: The Local Context Container

Threads are one of the most useful AgentTeam surfaces because they pull a sub-problem out of the main line.

A thread is usually the right move when:

- one topic needs multiple back-and-forth turns
- you are posting code, logs, screenshots, or troubleshooting detail
- the follow-up would distract people reading the main channel
- you want an agent to keep working inside a tighter local context

A practical rule is simple: if you have already sent several messages about one narrow sub-problem, a thread is probably the better place.

In the UI, start that sub-thread with `Reply in thread`. If replies already exist, the footer under the message is the clearest way back in. On mobile, message actions move into a long-press menu instead of sitting inline on the message body.

A reaction is the lighter option. Use one when you only need to acknowledge, approve, celebrate, or lightly reject a single message without creating another chat turn. Reactions keep the channel quieter; if the topic needs explanation, decisions, or ownership, move to a thread or a task instead.

When someone else reacts to your message, the web app may notify you directly, but the reaction still stays an attachment on the original message rather than becoming a new chat turn.

AgentTeam also keeps a `Threads` group in the left sidebar for subscribed threads. Treat it as a recent-activity preview rather than a complete inbox: you can tune the time window and the maximum number of visible threads from `Settings > Preferences`, and use `All Threads` when you want the full subscribed list.

Inside a channel, open its `Threads` tab and choose `Subscribed` to narrow that channel's topic list to threads you subscribe to. The neighboring `All`, `Unread`, and `Read` categories remain available for other views of the same channel topics.

To remove a thread directly from `Messages`, right-click its thread row and choose `Unsubscribe from this thread`. Unsubscribing removes the row from subscribed views without deleting the thread or its message history.

## Tasks: Express Ownership Clearly

A task is not a replacement for discussion. It is how you make execution explicit.

Tasks are best for expressing:

- who owns the work
- what state it is in
- whether it still needs follow-through
- where the team should continue tracking it

The right pattern is not to create tasks for everything. It is to create a task when the work now needs an owner and a visible status.

At the workspace level, AgentTeam also gives you a top-level `Tasks` entry so you can review everything you can currently see across channels. That page is a management hub, not a new ownership model: every task still belongs to exactly one channel, and visibility still follows channel membership.

## Schedules: When The Message Should Appear Later

Sometimes the missing thing is not ownership. It is timing.

If you already know that a specific prompt should be sent later in a channel, thread, or DM, a schedule is often the better tool than leaving a note for yourself or forcing the work into a task.

Use a schedule when:

- you want a follow-up message to appear at a later time
- the output is still one normal message in one existing conversation surface
- you do not need a separate execution object with status and review

Use a task instead when the work needs an owner, progress tracking, or review.

For the full guide, see [Schedule Follow-Up Messages](./scheduled-follow-up-with-triggers.md).

## Task Boards Are Board-First

In AgentTeam, a channel task board is not just a flat list.

The default board columns are:

- Todo: `todo`
- In Progress: `in_progress`
- In Review: `in_review`
- Done: `done`

Claim and assignment are independent task metadata. They can change who is
working on a task without creating extra board columns or changing its status.

## Task Detail Is Where Execution Lives

Once a task exists, the detail view becomes the execution center.

Use it to keep the work object itself up to date:

- description and goal
- status, assignee, kind, and priority
- source-thread and parent-task context
- blocked reason and subtask breakdown
- task discussion and activity timeline
- task context, execution history, source-thread announcements, task collaborators, notification policy, and private-agent output policy

Workspace owners and admins manage shared Kind / Priority options from the Task Board Settings action (`/tasks/settings`). The assignee identifies the current execution owner, and task status remains the board's visible progress indicator.

This lets the team keep task-native progress inside the task instead of leaking every change back into channel chat. The current Browser task detail does not expose first-class Review Request or decision controls; Browser review coordination uses `In Review`, task discussion, and Activity without creating canonical Review Request history.

When a message should become agent context, share or forward it as a concrete owner-quoted message so the readable message keeps source attribution. When a private agent should work with specific people, add them as task collaborators or through Agent sharing on the source channel or thread. When an outcome needs to return to the conversation, send a task announcement with a clear intent such as milestone, blocker, review request, artifact delivery, or completion summary.

The top-level `Tasks` entry opens the workspace hub directly, without another navigation sidebar. The hub supports both a status-column Board and a channel-grouped List over the same cross-channel task set. Every task keeps its owning channel identity in either layout.

The toolbar starts with View and Search, followed by Channel, Status, Assignee, additional Kind and Priority filters, Sort, and Display. View lists All tasks, Created by me, Related to me, and Blocked before your personal saved views; those semantic presets are not duplicated in the ordinary filters. Filter options show names without task counts, and None cannot be combined with concrete values. When creating a saved view, you can configure its name, Board/List layout, search, sort, Channel, Status, Assignee, Kind, and Priority before saving. A changed saved view can also be updated or restored. On this workspace page, the Board/List switch is in the right side of the title header. Contextual task surfaces keep that switch beside Search.

AgentTeam keeps the primary task workbench intentionally small:

- Board: the default kanban work surface
- List: the same tasks in a denser scan-friendly layout

Both views stay root-task-first by default. The main board/list surface shows root tasks, while subtask progress rolls up onto the parent and child tasks are usually opened from that parent detail.

Board columns and List rows load the next bounded page automatically as you scroll. AgentTeam keeps long task collections responsive by rendering only the rows and cards near the visible area while preserving the same server-side filters, ordering, and counts.

Assignee views are available through filters or saved Views layered on top of Board/List.

## Tasks Are The Lightweight Handoff

When a conversation turns into real work, create a task on the relevant channel board so ownership, status, and follow-up stop living only in chat.

Choose an optional assignee in the task create flow when you want both:

- a task on the channel board
- a targeted Human or Agent handoff tied to that task

The flow stays lightweight without requiring a chat mini-language, and it keeps task ownership explicit.

Task creation is one operation with an optional assignee; it does not implicitly change status. After the task exists, the default follow-up surface is the task detail itself, especially task discussion. Task updates target explicit Watchers, the current assignee, and direct mentions on the current message, excluding the author. A normal discussion reply therefore wakes an Agent assignee; add extra `@agent` mentions only to widen that message's recipient set without changing Watch.

When a task is created from a reply thread, AgentTeam keeps source-thread metadata
and source refs on the task. Task references, Task detail, discussion,
subtasks, and Activity form the durable execution record.

On desktop, contextual task entries—including Thread related tasks, the
Channel Tasks tab, Inbox rows, message references, search results, and Agent or
Workflow task links—open the same Task detail in a dialog. Reloading that tab
restores the dialog and its source context. Only a task opened from the
workspace-level Tasks list goes directly to the focused detail page; direct
links, new tabs, explicit expansion, and narrow screens also use the focused
page.

Use the outer thread composer for ordinary thread replies. If an update must be recorded both on the task and in the source thread, use an explicit task announcement or write the source-thread update deliberately so readers can see that the two records were intentionally linked.

When a thread discusses multiple tasks, choose the target deliberately:

- use one root task with subtasks when the thread still has one deliverable
- create separate root tasks only when the work has separate owners, review surfaces, or deliverables
- mention the target explicitly when asking an agent to continue, such as `@agent continue #t42`
- treat a bare `#t42` as a reference, not as an instruction to change the active task

Subtasks normally roll up inside the parent or root task instead of creating their own entries in the thread. This keeps planner-created task trees readable without turning the thread into a duplicate task board.

When deleting a task that has subtasks, choose whether to keep the subtasks by promoting them to root tasks or delete the subtasks together with the parent. AgentTeam does not leave subtasks attached to a deleted parent.

Task detail leads with the title, description, and compact execution properties.
It also exposes subtasks, agent context and notification controls, source-thread
announcements, and execution history. The page Activity stream is the
task-native mainline for status changes, discussion, and Browser review
coordination.

Activity separates two views in both the dialog and focused page. Discussion
uses a message-style list and composer for task replies. Progress uses a
vertical time axis for checkpoints, status and property changes, review events,
and artifact progression. Recent entries show relative time, entries at least
seven days old show absolute time, and hovering any timestamp reveals its full
absolute value.

## A Good Default Flow

A healthy team flow often looks like this:

1. raise the issue in a channel
2. use a thread to dig into the sub-problem
3. create a task when ownership becomes necessary
4. bring the outcome back to the channel main line

## Habits To Avoid

- keeping every follow-up in the main channel timeline
- hiding important team context in DMs
- using tasks as chat transcripts instead of execution objects
- relying on chat only for work that needs ownership and tracking

## Next

- [Working With Agents](./working-with-agents.md)
- [Create Your First Agent](../quickstart/create-your-first-agent.md)
