Multiplayer sessions in Slack
An OAP agent session in Slack is a thread, and a thread can hold more than one human. When several people are in a thread with an agent, they share one session — one transcript, one set of participants, one authorization boundary. Two owner gates keep that shared session safe: one decides who may take part, the other decides which actions run.
A new participant is a decision
Anyone can open a thread, but a new voice acting in a session is a permission decision, not a free-for-all.
In the clip, Jordan starts the rollout and Alex asks to help drive it. Instead of acting on Alex's message,
srebot pauses and asks an owner to approve Alex's participation first.
Sensitive actions need the same sign-off
With Alex in, srebot works toward the deploy — and hits a step too consequential to run unattended:
shipping hotfix-1.4.2 to production. It posts an approval card and pauses, setting its status to
waiting for an owner to approve. Because owners are easy to miss in a busy thread, OAP also DMs the card
to the owners, so any of them can approve without opening the channel.
The card is a first-class interaction, not free-form text — the buttons, the audit trail, and the "who may click this" rules are all built in rather than improvised per message.
Approval resolves everywhere at once
Because an approval is one interaction with one outcome, resolving it in the DM resolves it in the thread
too. The card's buttons are replaced in place with a green Approved by Jordan line, srebot posts that it
received the approval, and the rollout runs to completion — all visible to everyone still watching the thread.
That is the multiplayer property end to end: many humans, one shared session, gated at both the door and the dangerous step, resolving consistently for everyone at once.