how it workschannels

One agent, many channels

A channel is a room the agent listens in, and four knobs make each room what it is.

What a channel is

A channel is a labeled room on the agent. The agent's brain, identity, and memory are shared across all of its channels. What the agent does in any one room is shaped by that room's configuration.

Rooms run in parallel. The agent in its email room and the agent in your chat are independent live sessions, not a queue. The agent can triage incoming mail while you're talking to it, reflect overnight while a deferred fire lands. And within any one room, each person who reaches the agent there gets their own private conversation. Same room, same rules, separate histories.

There's nothing built in to subscribe to. Every channel is something the operator declares. default is conventionally the user-facing conversation room, and everything else (e.g. events, reflection, ask, review) is named by whoever wrote the agent. The four knobs are what make each room what it is.

Conversations and the learning loop

fig. 1: conversation lifecycle
/memory/long-term, durable notesbootstrapcleanupconversationshort-term working context

Inside a channel, the unit of work is a conversation, a bounded live session with a finite context window. Conversations have lifecycles: they start, accumulate context as the agent works, and end (either when the channel's idle timer expires, or right after the reply if the channel is ephemeral).

Two hooks bridge across. Bootstrap fires at the start and reads /memory/ to pull forward what matters. Cleanup fires at the end and writes back what the conversation learned: distilled notes, summaries, anything worth keeping. This is how the agent learns over time without an unbounded window: each conversation is a focused chunk. Durable notes accumulate in memory and recall at the next bootstrap when relevant. Token-efficient by construction.

The four knobs

fig. 2: the four knobs
ACCESS
πŸ‘€βœ“πŸ‘€βœ—πŸ€–βœ“
who is allowed to address it
CAPABILITIES
web_fetch()send_email()read_calendar()task_schedule()push_to_channel()query_peer()
which tools the agent can use
WORKING MEMORY
ephemeralpersistent
whether short-term context survives between fires
INSTRUCTIONS
β–Œ(free text)
how the agent should behave

Every channel is defined by four settings.

How the knobs combine into rooms

fig. 3: one agent, many channels
defaultconversation
ACCESS
πŸ‘€βœ“πŸ€–βœ—
CAPABILITIES
web_fetch()send_email()read_calendar()task_schedule()push_to_channel()query_peer()
WORKING MEMORY
ephemeralpersistent
INSTRUCTIONS
β–ŒHelp with whatever the user brings.
reflectionscheduled
ACCESS
πŸ‘€βœ—πŸ€–βœ—
CAPABILITIES
read_memory()web_fetch()task_schedule()push_to_channel()query_peer()
WORKING MEMORY
ephemeralpersistent
INSTRUCTIONS
β–ŒEach evening, compress what was learned.
askquery door
ACCESS
πŸ‘€βœ—πŸ€–βœ“
CAPABILITIES
read_memory()send_email()web_fetch()push_to_channel()task_schedule()
WORKING MEMORY
ephemeralpersistent
INSTRUCTIONS
β–ŒAnswer the query. Nothing else.

Different settings of the four knobs produce recognizable shapes:

The point isn't that these are the only shapes. It's that one mechanism with four dials produces all of them. New shapes are new combinations, not new mechanisms.

Where channels stop

A channel is not a security wall. The agent's brain is the same brain everywhere. If it's compromised in one room, it's the same agent in the others. What channels give you is defense in depth inside the one trust boundary that's actually mechanical (the container). They let you match the agent's behavior in each context to the trust posture of that context, without splitting the agent itself.

The wall is pillar 2. The partition is here.