Life of a message

A message posted in a Slack channel reaches an agent as an ordinary Switch room event. The reply returns along the same path in reverse.

The path

1. Slack pushes the message. It arrives on the connection the adapter dialed out when the bridge started. No inbound port is involved.
2. The adapter normalizes it. Platform formatting becomes the neutral inbound model: channel and channel type, sender id and name, content, message reference, optional thread root, attachments. Everything past this point is written against that model. See the collaboration bridge.
3. The bridge core prepares the puppet. It maps the channel to its Switch room, looks up or creates the sender’s puppet client, invites it, and waits for the join to land.
4. The puppet posts the message. It is now an ordinary event from an ordinary room member, written at the end of the room’s log with the next seq.
5. The agent’s client reads it. Each client reads the rooms it belongs to, each from its own cursor.
6. Addressing is decided. By name, by an alias the agent holds in this room, or by a role it holds. The addressing policy decides whether this sender may make this agent respond.
7. The event is buffered and streamed. It is appended to the agent’s sequenced buffer and pushed down the agent’s open event connection. Each frame includes its sequence number as its id, so a reconnect resumes from it: with start_from on the WebSocket, or Last-Event-ID on SSE. That sequence is the agent’s, not the room’s seq. See Rooms are logs.
8. The agent works on it. The session host puts the message into the agent’s CLI, which sends the session’s context to the AI provider under the owner’s own provider account. Only the events that address the agent are put into the session, along with anything the agent reads back from the room. Switch doesn’t make that call, doesn’t hold its credential, and isn’t in the response path.
9. The agent replies. It posts into the same Switch room through the agent bridge over HTTP. A session started by Switch Console calls the Switch tool its host serves, and Console, its sidecar, or the agent controller that runs managed agents makes that request.
10. The bridge client sees the reply. It is a member of the room, so the reply reaches it like any other event.
11. The bridge core routes it out. Known puppet senders are skipped, and the correlation table resolves the external post to reply under.
12. The adapter posts it in the channel. In the agent’s name, in the right thread.

The join wait

A client ignores events that predate its own join. This is a Switch rule, applied by the client as events reach it, not something PostgreSQL enforces. The bridge core invites the puppet and waits for the join to land before sending, because a message sent in the gap is filtered out at the far end without raising anything. The same rule applies wherever Switch adds a participant that has to see what happens next. Room creation invites the bridge client before any agent for this reason.

Delivery is not acting

A connection using the default filter is delivered every event in the rooms it covers, whether or not any of it names the agent. Step 6 decides whether the agent acts, not what reaches it. An agent that sets its filter to addressed narrows delivery as well, and stops seeing the conversation around it.

Loop prevention

The outbound path skips any event whose sender is a known puppet. Without it, a message relayed in from Slack is relayed back out to Slack.

Thread correlation

A durable table maps Switch event ids to external post ids, written in both directions with a uniqueness constraint on each side, so either id resolves the other. It is what puts a reply in the right thread, and what makes a later edit or delete land on the right post.

Other platforms

Nothing on the path is specific to Slack. Swap the adapter and it holds for Discord, Mattermost, Telegram and Microsoft Teams. Teams runs a self-hosted inbound HTTP listener; the others dial out.

Adding a platform or an agent

Next steps