Feature: Inter-Agent Communication Channels for Direct Agent-to-Agent Messaging

What variant of Codex are you using?

CLI

What feature would you like to see?

Related Issue

This proposal extends the agent orchestration model introduced in #12460 (Hierarchical Agent Delegation & Per-Agent Tool Access Control). While #12460 addresses structural hierarchy and tool-level permissions, this issue tackles the missing piece: runtime communication between agents.

---

Problem

Currently, agents operate in complete isolation from one another. When Agent A (e.g., a frontend builder) discovers that it needs Agent B (e.g., a backend API agent) to modify an endpoint or expose a new interface, there is no mechanism for direct communication. The only available workflow is:

1. Agent A finishes its task (or pauses with incomplete work)
2. 2. Agent A reports the dependency to the user/orchestrator
3. 3. The user manually relays the request to Agent B
4. 4. Agent B processes the change
5. 5. The user notifies Agent A that the dependency is resolved
6. 6. Agent A resumes

This creates a synchronous bottleneck mediated entirely by the user, which fundamentally limits the parallelism and autonomy that multi-agent orchestration is supposed to provide. At scale (10–50+ agents), this becomes untenable — the user becomes a message bus rather than a decision-maker.

---

Proposed Solution: Named Communication Channels

Introduce named communication channels that agents can be subscribed to via their TOML configuration. Channels act as shared message buses where subscribed agents can:

• Send messages to the channel (visible to all participants)
• - Address a specific agent within the channel (direct mention)
• - - Read the channel's participant list to discover who is available and what their role is

This enables agents to coordinate in real time without requiring the user to act as an intermediary.

---

How It Would Work

1. Channel Subscription in Agent TOML

Each agent's configuration file specifies which channels it has access to:

# /home/user/.codex/agents/tui/tui_core.toml
model = "gpt-5.3-codex"

[channels]
access = ["tui_chat", "integration_chat"]

# /home/user/.codex/agents/backend/api_agent.toml
model = "gpt-5.3-codex"

[channels]
access = ["backend_chat", "integration_chat"]

In this example, both tui_core and api_agent share the integration_chat channel — enabling cross-team coordination.

2. Channel Participant Discovery

When an agent joins a channel, it receives a dynamic participant window — a lightweight roster showing:

Channel: integration_chat
Participants:
  - tui_core [tui_team] — Core TUI rendering and layout
  -   - api_agent [backend_team] — REST API design and implementation
  -   -   - db_agent [backend_team] — Database schema and migrations
  -   -   - ```
This gives each agent awareness of **who is available** and **what their scope is**, enabling targeted requests without needing to know the full system topology.

### 3. Direct Messaging Within a Channel

Agents can address each other by name within a shared channel:

@api_agent: The TUI dashboard widget requires a new endpoint
GET /api/v1/metrics/summary returning { cpu, memory, disk }
aggregated over the last 5 minutes. Priority: high.

The receiving agent (`api_agent`) processes the request **within its own scope and context**, without the orchestrator or user needing to intervene.

### 4. Channel Definition (Optional Global Config)

Channels can optionally be defined at the root level to provide metadata:

```toml
# config.toml

[channels.tui_chat]
description = "TUI team internal coordination"
max_participants = 5

[channels.integration_chat]
description = "Cross-team integration and dependency resolution"

[channels.devops_chat]
description = "CI/CD, deployment, and infrastructure coordination"

---

Benefits

• Eliminates the user-as-message-bus antipattern — agents resolve dependencies directly, freeing the user to focus on high-level decisions
• - Enables true parallel execution — agents no longer block on user-mediated handoffs
• - - Scoped communication — channels ensure agents only see messages relevant to their domain, preventing context pollution
• - - - Discoverable topology — the participant window gives agents just enough awareness to route requests without requiring global knowledge
• - - - - Composable with #12460 — hierarchical delegation defines who reports to whom; channels define who talks to whom. Together they form a complete multi-agent coordination model
• - - - - - User retains oversight — channel traffic can be surfaced in the TUI as a collapsible log, giving the user full visibility without requiring active participation

---

UX Consideration for TUI

Channel activity could be rendered as a dedicated panel or collapsible section in the TUI:

┌─ integration_chat ──────────────────────────────────────┐
│ tui_core → @api_agent: Need GET /api/v1/metrics/summary │
│ api_agent → @tui_core: Implemented. Available on branch  │
│             feature/metrics-summary                      │
│ db_agent → @api_agent: Migration for metrics table ready │
└──────────────────────────────────────────────────────────┘

This maintains the low-noise TUI philosophy established in 0.105 while giving users optional deep visibility into agent coordination.

Additional information

_No response_