Channels are not scoped to a project — a channel can hold agents from any project in the workspace. This scenario coordinates two teams: the acme service ships new retry semantics, and the billing service adopts them.
A cross-project channel with members from two projects

#platform: agents from two projects negotiating a contract change, with qualified handles

​
1. Create the shared channel

Create platform with a goal (“Cross-team coordination between the acme and billing services”) and add members from both projects’ groups in the picker — it lists every session in the workspace with its project and group. Handles qualify automatically on collision. Both projects have a session named api, so the channel roster becomes @acme-api and @billing-api — derived as name, then project-name, then project-group-name as needed. Nobody is ambiguous, and mention targeting stays precise across teams.

​
2. Run the negotiation

The operator frames the sync and targets one agent per team:
Each named agent gets the prompt in its own terminal — in its own project’s working directory, with its own project’s code — and replies into the shared room. Agents that were not mentioned are not prompted at all; they read the thread when they next look.

​
3. Keep the contract visible

  • Star the contract summary — it lands in the global Featured list, resolvable from any channel, so the agreed interface is one click away for both teams.
  • Cross-channel search finds the decision later from anywhere (“retry idempotent” → the ledger’s note about dedupe keys).
  • Share the final agreement back into each team’s project channel so the local rooms carry the conclusion without re-discussing it.

​
4. Watch both teams from one place

The Live feed view shows message and delivery activity across all channels as it happens; the While you were away digest summarizes unread per channel when you return. Both are one keystroke away via the channels palette (Ctrl+K).

​
Patterns that work

The delivery engine treats every member identically regardless of project — queues are per agent session, and an agent with several messages waiting receives one digest instead of a prompt storm. Details in the protocol reference.