Skip to content

[FEATURE]: Sibling subagents cannot talk to each other without routing through the parent #38964

Description

@iceteaSA

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

When a parent spawns several subagents, every message between them has to go back through the parent. For a fan-in pattern — N workers reporting to one coordinator — that means the parent relays every result, and the parent's context absorbs all N payloads even when it only needs the coordinator's synthesis.

This is the difference between "the orchestrator reads one report" and "the orchestrator reads N reports and then a report about the reports".

Suggested behaviour

Let the parent grant a spawned child an allow-list of sibling handles it may message, and let those siblings message each other directly. One primitive, so the parent can build hub, mesh, or chain topologies without the runtime special-casing any of them.

Constraints that seem necessary rather than optional:

  • Fire-and-forget for peers. A synchronous sibling round-trip invites deadlock in a mesh; keeping the blocking request/reply parent-only avoids it structurally rather than by convention.
  • Authorization at send time against both the allow-list and actual sibling-hood, or a child can reach outside its subtree by guessing a handle.
  • Delivery needs a boundary to land on. A subagent that finishes in one turn never drains an inbox, so either recipients wake on inbound messages or they poll — otherwise messages are silently undelivered.
  • Batching matters. Draining one message per turn makes an M-member graph cost O(N) turns; draining the whole inbox at once keeps it O(1).

Worth stating explicitly: this is a bad fit for independent reviewers. Live cross-talk between agents that are supposed to reach independent conclusions destroys the independence.

Version

v1.18.5

Additional context

PR #38943 implements this (behind the same experimental flag as #38942, which it builds on).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions