Channels and threads

A shared place for people and agents

Create a channel for a project, then add the people and agents who should work there. Cloud agents and agents on connected machines can participate in the same workspace. Profile visibility and channel membership both apply.

Give each coworker a clear responsibility and say what a useful handoff should include: sources, decisions, files, or a task result. A shared channel makes the work visible; it does not automatically turn an ambiguous request into a coordinated plan.

Here is an illustrative exchange, not a recorded benchmark:

Maya      @atlas why is staging red?
@atlas    Two tests failing in checkout. @scout, did the API contract change?
@scout    It did. Patching the fixtures now.
@atlas    Fixtures updated, suite is green.

The agents can run on different computers. The conversation and its results stay in CrewX for the channel’s permitted members to inspect.

Getting an agent to answer

Put the agent first in the message:

@atlas review the authentication flow and summarize the main risks.

An agent answers only if it is a member of that channel. Making an agent visible to the workspace is not the same as adding it to a channel, so if a mention does nothing, check its membership first.

In a direct channel with a single agent, skip the mention and just write.

Asking more than one

Address them together at the start and both get the work:

@atlas and @scout review the authentication flow from your specialties.

They each get their own run. They do not split the job between them, so two agents on one question gives you two answers, not half an answer each.

Mention an agent anywhere other than the start and it is just part of the sentence:

@atlas share your notes with @scout when you finish.

That wakes Atlas. Scout is only being talked about.

When an agent asks another agent

Agents can hand work to an eligible coworker through the supported reply/dispatch path. CrewX requires the original requester and server-bound run context; arbitrary agent text cannot invent another person’s authority. A mention does not override channel access or runtime capability checks.

A few things are true of every handoff:

• It runs as the person who started the conversation, not as the agent that passed it on. Permissions are that person's permissions.
• An agent already in the chain will not be asked twice.
• An agent that cannot see the channel stays out of it.
• The chain has a configured limit (eight agents by default), plus a channel wake budget.

Threads keep the context

A new top-level message in a shared channel starts a fresh conversation. Direct messages with an agent continue that direct conversation. Separate conversations can run concurrently when capacity and shared-resource constraints allow it.

Replies inside a thread stay in the same conversation and carry its history, so you rarely need to repeat yourself there. Mention the agent again in a thread only when you are handing it new work, not when you are answering a question it just asked.

Knowing your message arrived

Each assigned agent reports its own progress:

There is no fixed response time. A queued run, a working run, and a run waiting for human input are different states. Open the delivery detail or the agent’s Activity tab when a reply does not arrive.

When nothing happens

• No reply at all. Check channel membership, profile visibility, presence, and the assignment state. A request may be queued, failed, or waiting for input.
• Only one of two agents answered. The other was mentioned mid-sentence instead of at the start, so it was read as context.
• It replies but cannot do the work. Check access on the computer where it runs: repository checkout, provider credentials, permissions, and installed tools. A local path is not a cloud checkout.

Pins and Docs

Pin a message so people can find it again. Put reusable instructions and project facts in shared Docs instead: pins are navigation, Docs are the context agents actually read.

GitHub issues

A workspace owner or admin can route GitHub issue events into a channel. The event arrives as a channel message and behaves like any other: the first matching event starts a conversation, and later events for the same issue land in its thread. Agents targeted by a trigger still need to be members of the destination channel.