Channel protocol v3: bounded recursive worker-tree topology #19

New issue

Closed

opened 2026-05-28 06:37:21 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-05-28 06:37:21 +00:00

Owner

Problem

v2 channels are flat. A single channel holds a flat set of concepts and a flat agent roster (channels-protocol-events.md: orchestrator | worker | peer | observer). This models a fixed roster coordinating over one concept set well.

It does not model a tree. When an orchestrator decomposes a goal into sub-goals, and a sub-worker may itself decompose further, v2 has no way to:

link a parent concept to the child channel that fulfills it (spawn-lineage),
bound the recursion so the tree cannot fork-bomb,
roll a child channel's terminal result back up to the parent concept,
propagate liveness across the tree (a presumed-dead sub-orchestrator orphans its subtree).

Proposed v3 surface

Spawn-lineage. A concept may carry expanded_into: <child-channel-id>. The child's spec carries parent: {channel, concept}. The tree is reconstructable from the lineage links alone.
Depth budget. The spec carries a hard max_depth. A channel at depth N refuses to spawn children past the budget. Default conservative, capped.
Result rollup. When a child channel's root concept reaches a terminal state (done / abandoned), its result propagates to the parent concept. The parent reaches terminal only when all children are terminal.
Tree liveness. The existing 5 x STATUS_CADENCE_SECONDS presumed-dead rule extends to subtrees: a dead sub-orchestrator marks its owned subtree reclaimable.

Builds on existing substrate

agent-channel-requests.md already carries o2r_session_id and intended_role, and the relay gates trust once at ingress then inherits it downstream inside a session. v3 should confirm spawned child channels inherit that session trust rather than re-verifying per node.

Non-goals

Stays consumer-agnostic. Does not name or assume any particular orchestrator or client. This is a pure protocol capability.

Sequencing (per repo AGENTS)

Protocol doc and harness updated together, re-run against a real Phoenix (both the GraphQL spans query and the Sessions query), then code. Version bump v2 to v3.

Open question

One-channel-per-node (a tree of channels linked by lineage) vs one channel with nested concepts. The draft above assumes the former. Worth deciding before writing the doc.

## Problem v2 channels are flat. A single channel holds a flat set of concepts and a flat agent roster (`channels-protocol-events.md`: `orchestrator | worker | peer | observer`). This models a fixed roster coordinating over one concept set well. It does not model a **tree**. When an orchestrator decomposes a goal into sub-goals, and a sub-worker may itself decompose further, v2 has no way to: - link a parent concept to the child channel that fulfills it (spawn-lineage), - bound the recursion so the tree cannot fork-bomb, - roll a child channel's terminal `result` back up to the parent concept, - propagate liveness across the tree (a presumed-dead sub-orchestrator orphans its subtree). ## Proposed v3 surface 1. **Spawn-lineage.** A concept may carry `expanded_into: <child-channel-id>`. The child's `spec` carries `parent: {channel, concept}`. The tree is reconstructable from the lineage links alone. 2. **Depth budget.** The `spec` carries a hard `max_depth`. A channel at depth N refuses to spawn children past the budget. Default conservative, capped. 3. **Result rollup.** When a child channel's root concept reaches a terminal state (`done` / `abandoned`), its `result` propagates to the parent concept. The parent reaches terminal only when all children are terminal. 4. **Tree liveness.** The existing `5 x STATUS_CADENCE_SECONDS` presumed-dead rule extends to subtrees: a dead sub-orchestrator marks its owned subtree reclaimable. ## Builds on existing substrate `agent-channel-requests.md` already carries `o2r_session_id` and `intended_role`, and the relay gates trust once at ingress then inherits it downstream inside a session. v3 should confirm spawned child channels inherit that session trust rather than re-verifying per node. ## Non-goals Stays consumer-agnostic. Does not name or assume any particular orchestrator or client. This is a pure protocol capability. ## Sequencing (per repo AGENTS) Protocol doc and harness updated together, re-run against a real Phoenix (both the GraphQL spans query and the Sessions query), then code. Version bump v2 to v3. ## Open question One-channel-per-node (a tree of channels linked by lineage) vs one channel with nested concepts. The draft above assumes the former. Worth deciding before writing the doc.

coilysiren commented

2026-05-30 05:44:01 +00:00

Author

Owner

Iceboxed in the 2026-05-29 backlog burn-down: Speculative channel protocol v3 tree topology, no current dependency. Reopen anytime if it becomes real.

coilysiren

2026-05-30 05:44:02 +00:00