@Claude in Your Slack: What Claude Tag Actually Changes

Anthropic just shipped Claude Tag, which puts an agent into a Slack channel that anyone can tag with @Claude. I think the model under the hood (Opus 4.8) is the least interesting part of this. The interesting part is where they put it: in the channel where the work already happens, as something that stays.

I have spent a lot of time wiring agents into apps. The hard problem is almost never "can the model do the task." It is "how does a person hand the task off, and how does the agent know enough to do it without a paragraph of setup every time." Claude Tag is a bet on solving the handoff, not the model. That is the right bet.

What it actually is#

You add Claude to selected Slack channels, connect it to the tools and data you choose (including codebases), and then anyone in the channel can tag @Claude with a request. It breaks the task into stages, works through them with the tools it has, and replies in a thread with what it did. If you have used Claude Code or Cowork, the loop is familiar.

It is in beta for Enterprise and Team customers, on Slack first, and it replaces the older Claude in Slack app. Anthropic says 65% of their product team's code now comes from their internal version of this. Take that number with the usual grain of salt for a vendor talking about its own tool, but the direction is clear enough.

Four things make it different from pasting into a chat window.

It is multiplayer#

There is one Claude per channel, and everyone shares it. So I can tag it, step away, and you can pick up the same thread and keep going. That sounds small. It is not. Most agent tools today are single-player: you get your chat, I get mine, and neither of us can see the other's context. A shared agent in a shared channel matches how teams actually work, which is messily and in public.

It remembers#

As Claude follows a channel, it builds context, so you stop re-explaining the project from scratch. With permission it can pull from other channels and data sources too. Anthropic notes it does not report from private channels, which is the kind of detail you want them to have thought about up front.

This is the part I would watch most closely. Memory is leverage and liability at the same time. An agent that remembers your architecture decisions is great. An agent that remembers a half-finished idea from three weeks ago and treats it as current is a problem. We do not get to see how it decides what is still true, and that decision is most of the game.

It takes initiative#

Turn on "ambient" behavior and Claude will proactively flag things it thinks you need to know, and follow up on threads that went quiet. This is the line between a tool and a teammate. It is also the setting I would turn on last and tune hardest, because an agent that talks when nobody asked is either very useful or very annoying, with not much room in between.

It works async#

Set a task and go do something else. It can schedule work for itself and run a project over hours or days. The framing Anthropic uses is that you spend more of your time delegating to many Claudes in parallel. If you have read my piece on the supervisor pattern, this is that idea, except the supervisor is you and the channel, and the workers are agents you tagged in.

Why "in Slack" is the actual product#

The model has been capable of this kind of work for a while. What was missing was a place to put it that did not require everyone to change their habits. People do not want to open a new tab to delegate. They want to type @Claude can you find why the signup metric dropped in the channel they are already complaining about it in.

That is the whole insight. The surface matters more than another point of benchmark. Putting the agent where the conversation lives removes the single biggest tax on using one, which is context transfer. You do not brief it. It was already there.

The part nobody enjoys but everyone needs: access#

Here is where I get less excited and more careful. The thing that makes Claude Tag useful (memory, tool access, codebase access, initiative) is exactly the thing that makes it a security surface. Anthropic clearly knows this, because most of the getting-started flow is about scoping.

Admins specify which tools and data the agent gets, per channel. Memories stay scoped to their channels, so a sales-configured Claude will not leak memory or data into an engineering one. You can cap token spend per org and per channel, and there is a log of everything @Claude did and who asked for it.

If you are the person who has to sign off on this, here is roughly how I would think about rollout:

1. Start in one private channel with read-only or low-risk tools.
2. Confirm the audit log shows task + requester clearly.
3. Set a hard monthly spend cap before you widen access.
4. Add codebase or production tools only to channels that already
   have those humans in them. The agent should never have more
   reach than the channel's members do.
5. Turn on ambient behavior last, in one channel, and see if the
   proactive messages are signal or noise before spreading it.

The principle I keep coming back to: the agent should never have more access than the people in the channel. If that holds, Claude Tag is mostly a faster version of work your team is already trusted to do. If it does not hold, you have built a confused-deputy problem with a friendly name. I wrote more about this failure mode in guardrails and safety for agents in production.

What I would use it for first#

Not code, at least not on day one. The lowest-risk, highest-value uses are the boring ones:

• Chasing down a metric or a number across connected data, so the answer lands in the thread where people asked.
• Triaging support tickets and summarizing the messy ones.
• Following up on stale threads, which is the thing humans are worst at and an ambient agent is naturally good at.

Code generation is the headline, and 65% is a striking number, but it is also the use with the most blast radius if memory or access is wrong. Earn trust on read-heavy tasks first.

The honest tradeoff#

A shared, persistent, proactive agent is genuinely a different thing from a chat window, and I think it is the right shape for team work. The cost is that you are now running an actor in your most sensitive communication channel, with memory and tools, that can act without a human in the loop unless you put one there. That is a real tradeoff, not a marketing footnote. Whether it nets out positive depends almost entirely on how disciplined you are about scope, and how good the agent is at knowing what it does not know.

I am optimistic about the design and cautious about the rollout. If you get beta access, start small, watch the logs, and add reach slowly. The model will be fine. Your access policy is the thing that decides how this goes.

If you want the deeper version of the "agent that lives in your workflow" idea, my notes on context engineering for agents cover why the memory question is the one that actually matters.