comments (10)

  • Wowza this will be a token guzzler. Assuming Claude is parsing every message posted on multiple slack channels, compacting knowledge etc.

    Looks like Anthropic is progressing further into platform territory and conquering Agentic use cases left right and centre. If you’re building an agent platform for workforce productivity today, your best best is model agnosticism and focus on token cost control.

    holografix

  • WRT “Claude learns over time” - this is the biggest gap for me in the current system. As I scale my usage of Claude at work, I observe that it’s quite bad at distinguishing what it should “learn” (memorize) from experimental or just wrong data. It builds and builds on a foundation of sand, making sometimes hidden assumptions and turning them into actionable insight thats just not correct.

    It recently wrote an entire dissertation for an epic, assuming it was related to some other project, where it had earlier made the wrong guess about a vendor capability (from their marketing materials, no less), and it all had to be thrown away. I cleared the memory, but it appears to be still pulling from some corporate data source i cant control or locate.

    threecheese

  • I don't understand how this is gonna fly for enterprise security and compliance. Claude needs to inherit permissions from somewhere, and those permissions will never align with the members of a slack channel. And finding the lowest common denominator of access probably results in a dumbed-down, useless experience.

    The only way it works is if customers truly start treating agents as humans with the same liability as an employee.

    SAK_ATAK

  • >Today, 65% of our product team’s code is created by our internal version of Claude Tag.

    Yeah, that explains a lot.

    yodon

  • 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.

    SweetSoftPillow

  • > Today, 65% of our product team’s code is created by our internal version of Claude Tag.

    Given the reliability and general product quality of the Anthropic product team's code, this doesn't sound like a selling point.

    nozzlegear

  • Is someone here using a Claude product that's not code? I'm puzzled about the amount of products they put out. I know a lot of people using Claude but we're all using the terminal-based code. Even for non-engineering stuff it suits great (tax documents, 3D modeling with blender through MCP, academic research, etc.)

    phaser

  • What if you could do this:

    @claude collect all the internal knowledge and context. And fire folks who are not required.

    bitlad

  • I read this as "Claude integration to Slack is now billed as API usage". Is that wrong?

    ratherbefuddled

  • It's interesting to see the market movements from the big players.

    This announcement is all about Claude extending its reach beyond single-player workflows and into multi-player workflows.

    On the flip side, Slack just announced MCP support for the Slackbot AI chat capability embedded within Slack. It is, for now, exclusively single-player.

    Single-player is the "safe place" (relatively speaking). The context, permissions, and standards (MCP/MCP UI apps) all work reasonably well for it, but get super complex or break down entirely when thrown into a multi-player shared context. I suspect Slack is doing what they are doing with an eye towards multi-player, but it's hard to say how that will manifest.

    For a real life example of this challenge: I work in scheduling (for Reclaim.ai) and you can ask our chat to find time to meet with a coworker and we go find time and help explain why certain times won't work. For example, it might say: "I couldn't do 11am tomorrow because you've got a job interview scheduled on your personal calendar". This is safe and fine to do in a private context.

    But... imagine if one were to ask our service (or Claude) to find time with someone and it replied to the thread for everyone to see: "The soonest I could find is 12pm tomorrow. Reggie is available at 11am, but Lightbody has a job interview so it won't work". WHOOPS.

    I think the other comments in this thread have the right idea of it: for this to really work safely, the permissions model needs to be nailed down, and it may mean that you end up with multiple identities of "Claude Tag" (or whatever agent you engage with in a public forum), and the context it gets is only the context that particular identity is entitled to, just like any other employee. But then that gets tedious because now I've got even MORE "people" to keep track of and know who to engage with, which is half the problem getting work done in large enterprises.

    Will be interesting to see how this evolves. I'll have my popcorn out :)

    Lightbody