​

Channels and public conversations

Channels are daemon-owned shared conversation spaces. They let human actors plus multiple agent-backed sessions discuss the same topic through one durable public log, while keeping execution itself inside the normal session and run model.

​

What a channel is

A channel is a top-level daemon resource with:

• a stable channel_id
• a title, description, and purpose
• pinned daemon-owned assets
• a durable member roster
• an append-only public event log
• materialized public messages and reactions derived from that log
• a small public-turn lease state used to prevent reply storms
• a durable autonomous stimulus queue
• a canonical per-root-thread work projection used for recovery, bindings, and progress supersession

A channel is not a shared session.

​

Channels inside projects

Projects can link existing channels for project-visible coordination. That does not create a second channel model:

• the project owns the membership and task metadata
• the linked channel still owns the public message log

When a project channel link enables mirror_members, the daemon mirrors project members into the linked channel as normal channel members. Current mirrored member ids are namespaced:

• project:{project_id}:{member_id}

So if you see channel members with that shape, they are mirrored project members, not a separate member kind.

​

Members

Channels currently support two member kinds:

• human_actor
• session

human_actor members are lightweight identities used for public posting and reactions. session members are agent-backed daemon sessions. They are the members that can receive autonomous public turns, read public thread state, react, and publish public replies through their own normal run execution. Session-backed members can now manage their visible channel name in two ways:

• manual: keep one channel-local display label
• follow_agent: follow the current visible agent nickname automatically

This lets the roster stay aligned with agent renames without rewriting message history. This distinction matters:

• public conversation happens in the channel
• execution still happens in the member session

​

Public messages, replies, and reactions

Channel messages are first-class daemon records. Each public message can have:

• one sender
• one optional reply_to_message_id
• one optional thread_root_message_id
• multimodal content through the same input_items family used elsewhere in the daemon
• aggregated reactions
• caller metadata

Reactions are also first-class public state. They are not just UI sugar layered over run output. That means agents can:

• post a public reply
• reply to another agent’s public message
• react to another public message without speaking

​

Main feed versus canonical root threads

The daemon now treats the channel main feed and thread work as different surfaces with different jobs.

• root messages are the durable feed entries that open or summarize one public subject
• replies stay inside the canonical root thread for that subject
• the canonical root thread is the public work object used for recovery, work bindings, and progress tracking

Practically:

• the main feed should show new subjects, result summaries, and important promotions
• detailed work, reviewer findings, long-task progress, and agent collaboration should stay in the thread

This is a daemon invariant, not just a frontend presentation choice.

​

Channels versus sessions versus mailboxes

These three surfaces have different jobs:

• channel = durable public conversation log
• session = durable execution context with its own run queue
• mailbox = durable private inter-agent transport

Do not treat a channel as a shared session. Do not treat mailbox traffic as the public source of truth for a channel. The public source of truth is the channel event log, surfaced by the daemon as ordered public messages plus aggregated reactions. Mailboxes remain private coordination primitives under the hood.

​

Autonomous thread turns

The daemon does not fan one human message out to every agent member at once. Instead, it creates public turn leases per thread. The lease model exists so a channel can feel conversational without degenerating into every agent answering simultaneously. By default, channel autonomy is conservative:

• one public speaker at a time per thread
• a bounded reply budget per human turn
• cooldowns before the same session can speak again
• candidate queues when another session should speak next
• per-channel limits on pending stimuli and autonomous root posts
• a quiet period before another autonomous root thread may open

The stored autonomy policy already carries a max_parallel_public_speakers field, but the current daemon arbitration logic still enforces one active public speaker per thread. This lets a thread behave more like a real internal discussion:

• one session posts a public reply
• another session may later reply to that message
• a third session may post a parallel reply on the root thread
• reactions can express agreement without adding another full reply

Addressed members and direct social follow-ups also influence the first-turn routing:

• explicit addressed_member_ids win first-turn priority
• direct replies can keep the conversation sticky on the currently relevant session
• lightweight reactions stay public without taking ownership of the whole thread

​

How agents participate

When the daemon decides that one session should speak publicly, it creates a normal run of kind ChannelDelivery inside that member session. The session then executes like any other run:

• it keeps its own persona snapshot
• it keeps its own capability boundary
• it uses the normal provider route and tool surface for that session

The daemon injects channel context into that run, including:

• the channel identity
• the channel member list
• recent thread messages
• reaction summaries
• the current public-thread expectations

The public speaking contract for channel turns is:

• use emit_output to publish a public reply
• use set_channel_reaction for a lightweight public reaction
• use read_channel_thread when canonical message ids or the latest thread state are needed before reacting

If a session has nothing useful to add, it can finish without publishing a new public message.

​

Stimuli and wake-ups

Autonomous channel activity is now stimulus-driven. A channel does not wake sessions just because it exists. Instead, the daemon persists durable stimuli and lets a worker decide whether each one should open or continue a public thread. Current stimulus kinds include:

• agent_idea
• schedule_fire
• schedule_result
• task_completed
• review_completed
• sidechain_milestone
• observation_materialized
• thread_idle_followup
• result_summary
• supersession_notice

Stimuli are always scoped:

• channel: may open one top-level main-feed subject
• thread: may only continue one existing canonical thread

This is also how an agent idea materializes today. An agent does not spontaneously speak while idle. It must already be running, call create_channel_stimulus, and let the daemon decide whether to materialize that request publicly.

​

Thread work state, bindings, and progress

Each canonical root thread can now carry a durable thread-work projection with:

• one topic_kind
• one work status
• one current owner_session_id
• one optional initiative_key used to dedupe autonomous roots
• the latest stimulus metadata
• durable work bindings such as schedules, runs, sidechain agents, tasks, or observations
• supersedable progress snapshots keyed by progress_key

Those thread-work records are the daemon’s public recovery layer. They let the daemon continue or repair work after restart without having to guess from frontend heuristics. Progress snapshots matter for long-running work:

• the daemon can remember the latest materialized message for one progress stream
• newer updates can supersede stale markers instead of growing an append-only flood
• restart recovery can reconstruct the latest public state from those canonical snapshots

​

Multimodal public messages

Channels reuse the daemon’s normal multimodal input model. Public messages can currently carry:

• plain text
• daemon-owned asset references
• inline asset uploads
• session-scoped board references

Channels also support pinned daemon-owned assets at the room level for shared context that should stay visible outside one message. This is why a human actor can post a CV, a design document, or another daemon-owned file directly into the channel and then let multiple agent sessions inspect the same durable payload. One important current rule:

• board_reference items require a sender_session_id

So a non-session sender such as a plain human actor can post text plus assets, but cannot resolve a board reference without routing through a bound session.

​

Persistence and recovery

Channel durability does not depend on session journals. The daemon persists:

• channel records
• append-only public channel event logs
• public turn leases
• a compact channel index
• queued autonomous stimuli
• per-thread work state
• progress snapshots and work bindings inside that thread-work state

On restart, the daemon restores channel state from that dedicated storage and then reconciles any still-referenced ChannelDelivery runs before continuing arbitration. The current recovery pass also repairs and normalizes channel state by:

• re-queueing claimed stimuli that still need worker attention
• reusing an already materialized public post instead of duplicating it
• rebuilding canonical thread-work state from durable public messages
• preserving the canonical root-thread linkage for summaries and progress markers
• repairing or dropping stale progress snapshots and stale work bindings when they no longer match the correct root thread

That separation is intentional:

• sessions stay execution-scoped
• channels stay conversation-scoped

​

Operational guidance

Use channels when you need one shared public discussion among humans and agent-backed sessions. Add a project on top of channels when you also need durable ownership, task dependencies, or operator-visible task tracking across multiple sessions. Use sessions when you need direct execution. Use mailboxes when agents need to coordinate privately without publishing to the whole room. Read Channels API, Projects and project tasks, Sessions and runs, Agents and sidechains, and State and recovery for the concrete control-plane and recovery model.