bots-garden/sidekickspublic Fork
⑂ feature/m4-agents-workspace
Commits
⬇ Clone ▾
git clone https://git.rickub.com/bots-garden/sidekicks.git
git clone ssh://git@rickub.com/bots-garden/sidekicks.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

Download ZIP
🛟 Updated. 1d19377 · on feature/m4-agents-workspace · k33g · 3d ago
channels-and-context.md · 35 lines · 4.6 KBmarkdown
Blame HistoryOpen raw

Channels and what each agent knows

What is this about?

A channel is a conversation the user has with several agents at once: ask Alice, then ask Bob for an opinion on Alice's answer. The Agent Client Protocol does not know this situation. It links one client to one agent, in sessions where only the two of them talk. Everything that makes a channel — who answers, who knows what was said — is decided by Sidekicks. This page explains those choices; the exact rules are in the reference, the decisions in ADR 0006.

One session per agent and per channel

Each agent of a channel has its own ACP session for that channel. Alice in #general and Alice in #translations are two sessions of the same process: what Alice hears in one channel never leaks into the other.

A session only contains what was said in it. When Bob is asked something after Alice answered, Bob's session knows nothing of that answer. So before Bob's turn, Sidekicks adds to Bob's prompt what Bob has not seen: the user's messages to others and the other agents' answers, since Bob's last turn. The agent reads a short transcript, then the user's message. It keeps its own session — and its own memory of its own answers — while following the channel.

The alternative, one shared session that every agent reads, does not exist in ACP: a session belongs to one agent. Re-sending the whole channel at every turn would fill the small context windows of local models within a few exchanges. Sending only what is new is the cheapest way to stay up to date; the transcript is limited to the last 20 messages, each shortened, so that a long channel does not crowd out the question.

Who answers, and why one at a time

A message goes to the agents it mentions, in order; without a mention, to the last agent who spoke. That is how people talk in a group: you name someone, or you carry on with the person you were talking to. Nobody answers a message that names nobody in a channel where several agents have not spoken yet — guessing would surprise the user more than asking them to choose.

Agents answer one after the other, never at the same time. On a laptop, two local models generating together are each slower than one after the other, and memory is the real limit (two small models on the reference machine). Answering in turn also lets the second agent read the first one's answer: "@alice @bob compare" gives Bob Alice's answer to compare with. For the same reason an agent answers one channel at a time: a second channel waits, and shows whose turn it is.

Commands are sent alone

/idioms Il pleut des cordes asks Garfield to run a skill. The agent recognises a command by its first character. If the transcript of the channel came before it, the command would no longer be a command. So a message starting with / is sent as it is, without context, and /garfield:idioms … picks the agent when several are in the channel. An agent announces its commands as soon as a session opens, before any question — and mm does so without loading its model. So the first / typed in a conversation starts the members that never announced theirs and opens their session (the one their first answer will use); the list fills in a fraction of a second. Sidekicks then keeps the commands, and offers them at once the next times.

After a restart

The history is in a database next to the configuration (one per configuration file), so the channels are there again after a restart. The agents, though, are new processes: their sessions are gone. ACP lets an agent resume a session (session/load); Sidekicks uses it when the agent offers it. mm does not, so Sidekicks opens a new session and gives the agent, in its first prompt, the last messages of the channel — its own included this time, since the new session has none of them. The user sees no difference: Alice still knows their name.

The same mechanism covers an agent stopped to make room for another (two agents at most): its next turn starts a new session that is told what it missed. In milestone M2, the conversation said "Alice restarted and no longer remembers the beginning"; that message is gone.

How it relates to the rest

  • Permissions and trust: permission cards work the same way in a channel; the card names the agent that asks.
  • Memory and local models: why two agents at most, and why answers are given in turn.
  • Architecture: internal/channels decides, internal/store remembers, internal/agents lends the processes.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Channels and what each agent knows

## What is this about?

A channel is a conversation the user has with several agents at once: ask Alice, then ask Bob for an opinion on Alice's answer. The Agent Client Protocol does not know this situation. It links one client to one agent, in sessions where only the two of them talk. Everything that makes a channel — who answers, who knows what was said — is decided by Sidekicks. This page explains those choices; the exact rules are in the [reference](../reference/agents-and-events.md#channels-milestones-m2-and-m3), the decisions in [ADR 0006](../../adr/0006-channels.md).

## One session per agent and per channel

Each agent of a channel has its own ACP session for that channel. Alice in #general and Alice in #translations are two sessions of the same process: what Alice hears in one channel never leaks into the other.

A session only contains what was said in it. When Bob is asked something after Alice answered, Bob's session knows nothing of that answer. So before Bob's turn, Sidekicks adds to Bob's prompt what Bob has not seen: the user's messages to others and the other agents' answers, since Bob's last turn. The agent reads a short transcript, then the user's message. It keeps its own session — and its own memory of its own answers — while following the channel.

The alternative, one shared session that every agent reads, does not exist in ACP: a session belongs to one agent. Re-sending the whole channel at every turn would fill the small context windows of local models within a few exchanges. Sending only what is new is the cheapest way to stay up to date; the transcript is limited to the last 20 messages, each shortened, so that a long channel does not crowd out the question.

## Who answers, and why one at a time

A message goes to the agents it mentions, in order; without a mention, to the last agent who spoke. That is how people talk in a group: you name someone, or you carry on with the person you were talking to. Nobody answers a message that names nobody in a channel where several agents have not spoken yet — guessing would surprise the user more than asking them to choose.

Agents answer one after the other, never at the same time. On a laptop, two local models generating together are each slower than one after the other, and memory is the real limit (two small models on the reference machine). Answering in turn also lets the second agent read the first one's answer: "@alice @bob compare" gives Bob Alice's answer to compare with. For the same reason an agent answers one channel at a time: a second channel waits, and shows whose turn it is.

## Commands are sent alone

`/idioms Il pleut des cordes` asks Garfield to run a skill. The agent recognises a command by its first character. If the transcript of the channel came before it, the command would no longer be a command. So a message starting with `/` is sent as it is, without context, and `/garfield:idioms …` picks the agent when several are in the channel. An agent announces its commands as soon as a session opens, before any question — and mm does so without loading its model. So the first `/` typed in a conversation starts the members that never announced theirs and opens their session (the one their first answer will use); the list fills in a fraction of a second. Sidekicks then keeps the commands, and offers them at once the next times.

## After a restart

The history is in a database next to the configuration (one per configuration file), so the channels are there again after a restart. The agents, though, are new processes: their sessions are gone. ACP lets an agent resume a session (`session/load`); Sidekicks uses it when the agent offers it. mm does not, so Sidekicks opens a new session and gives the agent, in its first prompt, the last messages of the channel — its own included this time, since the new session has none of them. The user sees no difference: Alice still knows their name.

The same mechanism covers an agent stopped to make room for another (two agents at most): its next turn starts a new session that is told what it missed. In milestone M2, the conversation said "Alice restarted and no longer remembers the beginning"; that message is gone.

## How it relates to the rest

- [Permissions and trust](permissions.md): permission cards work the same way in a channel; the card names the agent that asks.
- [Memory and local models](memory-and-local-models.md): why two agents at most, and why answers are given in turn.
- [Architecture](architecture.md): `internal/channels` decides, `internal/store` remembers, `internal/agents` lends the processes.