[FEATURE] Shared channel for agent teams — persistent, ordered group communication

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Agent teams currently have two communication primitives: directed messages (SendMessage to one agent) and broadcast (SendMessage to all agents). Both are push-based and ephemeral — they land in individual context windows and leave no shared, persistent record.

This creates three problems that worsen with team size:

1. No shared ground truth. Each agent has a different view of the conversation. The lead sees lossy DM summaries. Agents can't read each other's DMs. When Agent A tells Agent B something, Agent C doesn't know unless someone explicitly relays it — and the relay is lossy. There is no single place where every team member (and the human) can see the same coordination history.

2. Broadcast doesn't scale. With 3 agents, broadcast is manageable. With 8, it's chaos. Every agent broadcasting asynchronously means N agents × M messages = N×M context window injections, all arriving out of order in different agents' contexts. There's no canonical ordering — each agent reconstructs a different timeline from the messages it received. Broadcast is a firehose with no shared memory.

3. Late joiners and context loss. When an agent goes idle and wakes up, or when context compression discards earlier messages, the coordination history is gone. The agent has no way to catch up on what happened. In long-running tasks, this means agents progressively lose alignment with each other.

These are the same problems that every team communication tool solved decades ago. Email (point-to-point) and mailing lists (broadcast) are insufficient — teams need channels: a shared, ordered, persistent log that all participants can read and write to.

Proposed Solution

Add a shared channel as a first-class team primitive alongside the existing task list.

When a team is created via TeamCreate, a channel is created automatically. Every team member (and the human lead) can:

• Append a message to the channel
• Read the full channel history

The channel provides:

• Total ordering — messages appear in a single canonical sequence. Every agent reading the channel sees the same history in the same order.
• Persistence — the channel survives context compression, agent idle/wake cycles, and session boundaries. It's the durable record of coordination.
• Concurrent-write safety — multiple agents writing simultaneously is handled by the runtime. Agents don't need to worry about race conditions, just like humans don't worry about race conditions in Slack. They write; it appears in order.

That's it. Append and read, with ordering guarantees and concurrent-write safety. The simplicity is the point.

What this enables

Group coordination without relay. Instead of A→B then B→C, agents write to the channel and everyone sees it. No telephone game, no lossy summaries.

Catch-up after idle/wake. An agent waking from idle reads the channel and has the full coordination trajectory. No lost context.

Human participation. If the channel is readable/writable by the human, they can follow along, interject, or redirect — without any special tooling. The human becomes a channel participant, not an external observer getting filtered summaries.

Shared reference for decisions. "As discussed in the channel" becomes a real reference. Agents can point to specific prior messages when disagreeing or building on earlier points.

Why not just use the filesystem?

You can. We've been running multi-agent teams with a shared channel.md file that agents append to via the Edit tool. It works — agents read the file, append entries, and broadcast a ping ("channel updated — go read") to wake teammates.

But it has friction:

• Concurrent writes can clobber. The Edit tool uses string matching. Two agents appending simultaneously can collide. We instruct agents to read-before-write and use Edit (not Write) to reduce collisions, but it's a workaround, not a guarantee.
• Agents must be taught the protocol. Every agent prompt must explain: use Edit not Write, read before appending, broadcast a ping after writing. This is coordination overhead that the runtime could eliminate.
• No native integration. The channel is invisible to the team infrastructure. TaskList is a first-class primitive with built-in tools; the channel should be too.

A runtime-native channel would make concurrent writes safe by construction — the same way Slack makes concurrent messages safe. Agents just send; the runtime handles ordering and persistence.

Alternative Solutions

• Broadcast SendMessage (current): Push-based, ephemeral, no persistence, no ordering guarantees across agents, doesn't scale beyond small teams.
• File-based channel (current workaround): Works but requires per-agent protocol instructions and has no concurrent-write safety.
• MCP-based relay (#20921): Proposed WebSocket relay for real-time messaging. Solves delivery but not persistence or shared history. Was blocked by CC's synchronous input loop.
• Shared state / whiteboard (#4993): Proposed as "Level 2" in a closed feature request. Similar concept but framed as key-value state rather than an ordered log.

Priority

Medium - Would be very helpful

Feature Category

Multi-agent coordination

Use Case Example

A team of 3 agents is synthesizing a research paper summary. Phase 1: each agent reads independently and produces a draft. Phase 2: they coordinate to produce a final output.

Without a channel (current):

• Agent A finishes first, broadcasts "I'm done." This wakes B and C — but they were already working. The broadcast is noise.
• B finishes, sends a DM to A: "I disagree with your framing of section 3." A sees this. C doesn't.
• C finishes, broadcasts "Let's compare drafts." A and B have already been discussing. C has no idea what they said.
• A relays B's point to C via another DM. C gets a lossy summary. The full reasoning is lost.
• They converge on a final output, but the coordination was a game of telephone.

With a channel:

• Each agent posts to the channel when they finish their draft: "Draft complete — key claim is X."
• All three see each other's positions simultaneously. The disagreement map is visible to everyone at once.
• B writes: "I disagree with A on section 3 — the paper supports Y, not X. See page 4." Everyone reads this.
• C writes: "I agree with B. My draft also found Y. But A's framing of section 2 is stronger than both of ours."
• The negotiation happens in shared space. No relay, no lossy summaries, no telephone game.
• The channel is also the audit trail — the human can read it afterward to see how the team coordinated.

Additional Context

Related issues that identify aspects of this problem:

• #28075 — Idle nudges expire before peer messages arrive. A channel with native notification on append would address cold-start delivery.
• #24256 — Coordination degradation in multi-agent workflows. A persistent shared record helps agents maintain alignment over extended sessions.
• #1770 — Parent-child agent communication. The channel gives the parent (and peers) shared visibility without requiring event streaming infrastructure.
• #4993 — Agent-to-agent communication (closed by stale bot). Proposed a "whiteboard" concept at Level 2 that is conceptually adjacent.
• #28300 — Multi-agent across machines. Uses the word "channel" explicitly for shared collaboration space.