[SweetSoftPillow]

The most important difference from other products:

> @Claude is multiplayer. Within a given Slack channel, there’s one Claude that interacts with everyone. This means that anyone can see what it’s working on, and can pick up the conversation from where the last person left off. This makes tagging Claude very different from working within a single chat or for a single task—it’s much more like interacting collaboratively with a teammate.

[atonse]

We have the opposite problem. We've tried this slack integration (first with NanoClaw, then Hermes, but now just building our own), and we actually want the OPPOSITE.

In private context, I want to have a per-person conversation with durable context for that person's private chats. I also want that person's permissions to extend. Like contractors in our slack should only be able to ask and get back information about clients that they've been attached to, not our entire knowledgeable.

And we've implemented ALL that, but just with a lot of custom code. We've put in interceptors that put in per-user keys into the MCP connection so only certain tools are even exposed, etc.

[ceroxylon]

Hopefully there is some sort of version history implemented or planned like they have in Cowork[0]... this sounds great until a co-worker hijacks your Claude session with a worse idea and derails it from what you were intending.

[0] "Editing this message will create a new conversation branch. You can switch between branches using the arrow navigation buttons."

[mhegazy2]

this is discussed in https://claude.com/blog/agent-identity-access-model

[tekacs]

I don't think that that's quite what the parent commenter had in mind.

From reading that and materials on it, it seems unclear if – let's say you do what's done in the demos on the site and 'dispatch work' from a thread in a shared channel (e.g. from some discussion) – that if any one of your coworkers replies below you and says, "Actually, could you fold in <blah> as well?" that Claude wouldn't listen to them and thus derail the work.

[stevenpetryk]

Yeah, there is a level of organizational trust that is required to use this tool (as with any system that allows distributing access via service accounts).

We do signal to Claude that there's a difference between a conversation's initiator versus incoming participants and we've found that in situations where people disagree on an approach, Claude patiently waits for a resolution while correcting any misunderstandings.

It's also worth mentioning that since Claude has its own identity, a coworker cannot enter a thread and commandeer _your_ identity; you collectively steer how Claude acts with its _own_ identity (it opens PRs as itself, browses Datadog as itself, etc).

[theshrike79]

If a coworker "hijacks" your session, you go "Yo, dude, fuck off" or walk over to their desk and slap them on the back of the head.

Anyway, if that happens, you've got organisational issues. Claude can't fix that.

[basch]

The killer feature here is an auto assembling todo list, punchlist, project management.

Discussing what needs to be done next, and having it automatically sort it into what subtask it is, if it applies or is blocking to multiple other tasks. Recording specifications, measurements, dimensions. Being able to ask other people facts and have them correctly documented into the right task.

Company Brain / Knowledgebase is imho more rear facing, whereas todo is future facing.

[kentm]

Thats a double-edged sword in some scenarios. If you're trying to keep info private then feeding it into a shared agent basically means that you can't guarantee that privacy. I'd imagine the approach here would be to have separate agents for private data and then restrict Slack access, but I could imagine tons of accidents from managers that habitually @Claude without understanding the implications.

[MaxLeiter]

Every channel has its own Claude, and Claude's access is configurable per-channel and per-workspace. Private channels don't leak information to other channels