Superset in Slack: a teammate in the channel, not a bot you summon
Reads every message, speaks only when it should. Turns a thread into a working session on a real workspace and agent. Acts as the person who asked, with their Linear and GitHub. Remembers per channel.
v13 · 2026-09-08 · branch lace-scene · author: Claude for Avi
Changed from v1
Participation follows Claude Tag's rules: no per-message classifier, four outcomes, back-off, engagement memory.
A thread is a working session on a Superset workspace plus agent, with mid-task follow-ups queued.
Tool safety is tiered with an Approve button, not a flat allowlist.
Bug fixes from the code review are unchanged and still Phase 0.
00The model
It joins the conversation
Replies in threads it's in, answers when it's talked about, stays quiet otherwise.
It uses your integrations
Linear, GitHub and the rest come from the asker's own plugin connections.
It remembers
Per-thread transcript and entity log; per-channel memory anyone can edit.
01Where it stands
Today: @-mention only, stateless per message, Superset tools only.
Fix these first. The plan multiplies message volume and blast radius.
bug Thread context reads the oldest 20 replies. run-agent.ts:68
bug Iteration cap, max_tokens, refusal unhandled; half-answers get posted. run-agent.ts:710
bug Slack retries aren't deduped; duplicate replies and side effects. events/route.ts
bug Image cap 120 MB where the API allows 5 MB per image. No maxDuration on job routes.
quality Sonnet 4.6 without thinking, no caching, markdown into a mrkdwn field, every MCP tool exposed including deletes.
shape Two 300-line duplicate handlers, dead v1 code, no tests under the route.
02When it speaks
Mentions and joined threads always get a reply. Everything else goes through the four-outcome decision.
saw the superset launch thread on HN, marketing did a nice job
S
Satya
yeah the superset invoice for Sept also came through, forwarded to finance
Superset says nothing. The word appeared; nobody was talking to it.
outcome 1 · name is not a trigger
# platform-engaddressed by name, no @
S
Satya
superset, did #7331 make it into 1.26?
Su
SupersetAPP
Yes. #7331 (read-only worktree delete) is in the 1.26.0 release notes, shipped Sept 5.
H
Harshith
can we have superset file the coupon bug as a task too
Su
SupersetAPP
Filed SUP-412 "Safari login 500 with coupon in cart", linked to the open thread.
addressed · treated like a mention
# platform-enga concrete need
S
Satya
checkout p95 is back at 900ms since this morning, no idea which deploy did it
Su
SupersetAPP
I can bisect this against today's deploys on web and post what changed. Want me to?
One offer, in a thread. If nobody answers, that's it.
outcome 1 · the one exception
# platform-engit already knows
H
Harshith
what's our branch naming again? feat/ or feature/?
Su
SupersetAPP
feat/<ticket>-short-slug. From channel memory, saved by Satya on Aug 14.
outcome 2 · short reply, no tools
# platform-engthe channel asked for it
S
Satya
@Superset remember for this channel: pick up bug reports without waiting to be tagged
Su
SupersetAPP
Saved. I'll start a thread on bug reports here.
H
Harshith
login page 500s on Safari 18 when the session cookie is expired
👀 1
Su
SupersetAPP
On it, on Harshith's mbp in a new workspace.
☑ Reproduced with an expired cookie ☑ Found the redirect in auth/session.ts ☐ Fix + test ☐ Open PR
Superset [fixing Safari login 500] is thinking…
outcome 3 · working session in the thread
# platform-engadds to work in progress
S
Satya
oh and the safari thing only happens when the cart has a coupon applied
Nothing posted here. The message lands in the login thread:
Su
SupersetAPP
Satya says it only reproduces with a coupon in the cart. Adding that to the repro.
outcome 4 · hand-off
# platform-engin a thread it's already in
H
Harshith
@Superset where are we on the launch checklist?
✅ 1
Su
SupersetAPP
8 of 11 done. Waiting on legal for the venue contract, since the 2nd.
S
Satya
fold in the vendor quotes from last week too
Su
SupersetAPP
Added, three quotes, all under budget. Updated the checklist above.
joined thread · no mention needed
# platform-engtoo chatty, told to stop
S
Satya
@Superset only respond in this thread when I mention you
Su
SupersetAPP
Got it. I'll stay out of this thread unless tagged.
Channel-wide: "@Superset only respond here when mentioned" flips the channel setting.
quieted · thread or channel
Respond automatically is per channel, default on. Change it by asking in the channel, in App Home, or as an admin.
Quiet a thread by replying "only respond when I mention you".
Back-off: after ~100 channel messages with no reply from the agent, it stops reading until the next mention.
Engagement memory: whether people act on unprompted replies is recorded; ignored channels get fewer.
Its name is not a trigger; being addressed is. "superset, did #7331 ship?" and "have superset file that" are addressed to it and get a reply without an @. "the superset invoice came through" is not, and gets nothing. The channel session reads intent from the whole message, not a keyword. When respond-automatically is off, only an @ gets through.
Bots are context, never a trigger. "@Superset triage this" under an alert is how to act on one.
03A thread is a working session
One thread over a day. Read left to right; each lane is a different question: what did people see, what was running, what was remembered.
Two shapes. Tools but no code: the existing loop with the transcript replayed. Code: workspaces_create with agents, and the thread becomes that agent's conversation.
Where it runs. Cloud sandbox by default for channel threads, the author's host for DMs and on request, a pinned runner host per channel for teams that want one. The reasoning is below. Decision 1.
Follow-ups arrive without a mention. Mid-turn they're queued; on resume the thread is back-read since last context.
On a host, delivery reuses page-watch. Page comments already reach a running agent this way: host-service keeps a watch keyed by workspace, terminal and agent, polls for new items, holds them while the agent is mid-turn, and pastes a prompt into the PTY. A Slack thread gets the same watch, assigned by the API when it spawns the agent instead of by the CLI on publish. If the terminal is gone, the API relaunches the agent in the same workspace with resume and reassigns. Replies flow back the way this page's comments do: the agent calls the CLI, or the API posts on the agent's turn-end event.
Progress is a checklist edited in place, streamed. Typing status under the message, no "Thinking..." placeholder.
Completion callback: an agent spawned from Slack reports back into the thread. Today nothing does.
!restart archives the session and starts fresh from the thread.
How Claude Tag does it, and how everyone else does
Every implementation answers the same three questions differently: where the agent's compute lives, what survives between turns, and whose machine or account the work belongs to.
System
Compute
Between turns
Belongs to
The bet
Claude Tag
Ephemeral cloud sandbox per thread, the same engine as Claude Code on the web. Two threads, two sandboxes.
Sandbox released minutes after a turn and rebuilt on the next reply. Transcript durable on Anthropic's side. Files only in the sandbox are lost; pushed branches and posted artifacts survive.
The channel. Service accounts an admin attaches per channel; DMs use your own connectors.
Team work must not depend on anyone's laptop. Anyone in the thread can steer.
Open-Inspect
Modal sandbox per session, OpenCode inside, a Durable Object per session holding state.
Snapshot on idle, restore on the next prompt. Heartbeats and inactivity timeouts.
One shared GitHub App for the whole org. Single-tenant by design.
Fire and forget: kick it off, close the laptop, read the PR later.
Cyrus
A machine you control runs the edge worker; a git worktree per issue on that disk. Cloud only for webhooks and OAuth. A hosted option exists too.
The worktree stays on disk. Follow-ups queue while a turn runs.
The machine's owner. Bring your own keys and subscriptions.
Your environment, your tokens, your box. Cheapest to run.
Local Claude Code bots
The developer's own laptop, Claude Agent SDK, one process.
A session file on disk. Dies when the laptop sleeps.
One person.
Personal convenience, not a team surface.
Superset today
Workspaces on a user's host. Cloud sandboxes exist on Blaxel, gated to internal users.
Host worktrees persist until archived. A cloud sandbox wakes on the first inbound connection; there is no idle stop, TTL, or quota yet.
The host's owner; cloud rows belong to the org with a creator.
Both, which is the opportunity.
The best of each, and the pattern to move toward
Four sources, one experience. This is the bar each phase is measured against.
This is the pattern to move toward. Claude Tag's conversational contract is the baseline, because it is the only one of the five that feels like a teammate rather than a tool. Superset adds the two things it structurally can't: the result lands in a workspace you can open in the desktop, and irreversible actions wait for a button. The other borrowings (streamed replies, queued follow-ups, dropdown clarification, signed completion callbacks) are how the baseline gets built without re-learning what the others already learned.
Three ways Superset could answer it
My pick: C. Cloud is the channel default, not the fallback.
Shared thread, shared compute. A channel thread can't die when one laptop closes.
Channel text is untrusted. Don't run it on a personal machine with full credentials.
Keep the Superset edge. The cloud workspace shows in the sidebar; open it on your machine.
DMs stay personal. Your host, your connections, your worktrees.
Runner host for teams that want one. Pin a channel to an always-on box. The Cyrus case, one setting.
Files survive, unlike Claude Tag. Needs an idle policy so it doesn't cost forever.
Cloud has to clear these first (open items in the Sandboxes project, a Phase 3 dependency):
idle stop, TTL, or per-org quota
delete wired to cloudWorkspace.delete
per-org model credentials instead of ours
GitHub token out of .git/config
host-service version handshake so old sandboxes fail clearly
Until then, Phase 1 runs mentions and DMs on the author's host, which works today. Channel working sessions wait rather than ship on a fallback.
04Identity and integrations
Every action runs as the person who asked. No per-channel service accounts, which is the part of Claude Tag security reviews criticised.
Surface
Acts as
Unlinked author
DM
The person, their connections
Connect prompt
Thread, mentioned or addressed
The author of the triggering message
Connect prompt in thread
Channel, unprompted
Short replies need nobody. Working sessions need a linked author.
Silence, or an offer naming the missing link
Routine
The automation's owner
n/a
MCP or CLI? Both, by where the code runs. The channel session and chat-shaped working sessions run inside the API, so they use the in-memory MCP client that exists today: in-process, no subprocess, auth context injected, no binary in the serverless bundle. A code-shaped working session is a Claude Code agent in a workspace, and it uses the superset CLI and installed plugins like any other agent on a host or sandbox. Both paths call the same tRPC router, so a tool added once shows up in both.
Linear and GitHub plugins already point at hosted MCP servers through the proxy. Bridging them is plumbing, not new tools. Inside a workspace the agent reaches the same servers through superset mcp call-tool.
Org-level integration_connections are inbound webhooks for triggers. They stay that way.
Notion and Sentry become plugins with an mcp block. Google has no hosted server. Decision 6.
Curate a Slack subset per plugin first; tool search with defer_loading if the count still hurts.
Not connected yet → one line plus a Connect button.
05Tool policy
06Memory
Scope is the channel. Public-channel memory is readable org-wide; private channels keep their own store; DMs keep per-person notes.
Written three ways: "@Superset remember for this channel: …", the agent's own curation turn after a session, and past thread transcripts on request.
Steers participation: "answer deploy questions without being tagged" and "only respond when mentioned" are both memory entries.
Editable by anyone in the channel. "@Superset what do you remember about this channel?" lists it.
Store notes and ids, not Slack content. Pull messages live when needed.
07Mechanics
Dedup: ack retries by header, QStash deduplicationId: event_id, dedupe mention plus message on channel and ts.
Outbox: every reply recorded with an idempotency key before sending. No double posts, no lost replies.
Where working sessions run. Recommended: cloud sandbox for channel threads, author's host for DMs, optional pinned runner host per channel. Alternatives: host-first with cloud fallback, or cloud-only. Section 03 has the comparison.
Respond-automatically default. On like Claude Tag, or off until a channel opts in?
Identity in channels. Per-user as proposed, or add channel service connections later?
Approval quorum. Any linked member, or only the author?
Gating. All Pro, or presence free and working sessions plus plugin tools paid?