Anthropic’s help documentation says Claude in Slack switched to Claude Tag on August 3, 2026. The beta is available on Team and Enterprise plans. In a channel, Claude works with an organization-managed identity and tools; the exchange is visible to the channel, and other participants can steer the work.
That is a different design problem from a private chat. A private assistant has an obvious conversational owner. A shared agent sits among several people, priorities and permission boundaries. My view is that the useful innovation is not merely invoking AI with a mention: it is making delegated work understandable to everyone affected by it.
Name the task owner before the agent starts
Imagine a product channel asks for a launch-readiness summary. One person wants a short update, another wants a release decision and a third adds a new deadline. Without explicit ownership, a helpful conversation can quietly become an ambiguous assignment.
For a shared-agent product, I would show a compact task summary: requested outcome, accountable person, relevant sources and the next expected checkpoint. That summary should be easy to amend, with changes visible in the conversation. It gives the team something stable to review even as the thread grows.
Channel access is not the same as personal access
Anthropic distinguishes channel work, which uses organization-configured access, from direct messages and the assistant panel, which use capabilities enabled in the individual account. Setup is restricted to a Primary Owner or Owner. Teams should check the current setup documentation before enabling channels or repositories.
The interface should make the active identity visible at the moment of delegation. Avoid making users infer permissions from where a message happens to appear. When a task cannot access a source, say which source is missing and offer an authorized next step; do not imply that the agent searched material it could not read.
Design a handoff, not a stream of confident messages
- Requested: show the outcome and the human responsible for accepting it.
- Working: identify meaningful progress without flooding the channel.
- Needs input: ask one precise question and identify who can answer.
- Ready for review: link the output and list unresolved assumptions.
- Completed: distinguish a draft from an action actually carried out.
These are proposed design states, not a claim that Claude Tag implements this exact interface. They are useful acceptance criteria when a team evaluates any shared AI workflow. A message saying a task is done should lead to inspectable evidence: a document, a change, a source-backed answer or a confirmed system result.
Treat interruptions and cost limits as normal states
The official guide describes organization and per-channel spending limits, with work declined if it would exceed a limit. That behavior deserves a clear recovery path. A team should know whether to reduce scope, ask an owner for capacity or finish the task manually.
A useful pilot is deliberately narrow. Choose one channel and one recurring task, record how often people need to correct the output, and compare the review effort with the previous process. Do not equate a large message count with value. Track accepted outputs and avoidable rework instead.
Start with work that can be reviewed
An internal weekly summary is easier to evaluate than an agent empowered to change customer records. Begin with bounded, reversible work and introduce broader capabilities only after the team can explain who approves them. Permissions should follow the task, not the excitement around the model.
This extends the broader question of designing for agents that keep working over time. Read the long-running agent workflow perspective ↗
For teams building their own internal software, the same principles apply: ownership, visible state and human review belong in the product model from the start. Explore custom software design and development ↗
