How to Build an Advanced Claude Tag with Multiple Slack Agents

The idea behind Claude Tag is simple and good: tag an agent into a Slack conversation and it does real work using the context around it. The catch is that it's an Anthropic feature limited to Team and Enterprise plans, tied to Anthropic's own models.

This tutorial gives you the same capability - and a more advanced version of it - on ChatBotKit, available to anyone, on any plan. Instead of one general assistant, you'll stand up a set of independent specialized agents, each its own Slack bot you tag in its own channel, each with a different goal, a different toolset, and its own access boundary. And because ChatBotKit is model-agnostic, you can run each agent on whatever model you want - a frontier model for one, a fast cheap model for another, or a local, self-hosted model behind your own firewall for the sensitive ones.

Each agent is assembled as a ChatBotKit blueprint, so it's a versionable, cloneable package. The blueprint previews below are live - copy any of them straight into the Blueprint Designer.

What You'll Build

Three independent Slack agents - no shared workspace, no central coordinator. Each is its own Slack app, so people tag the right specialist in the right channel:

The point of the diversification: a coding agent needs an executable sandbox and no long-term storage; a research agent needs persistent storage for its reports but no shell; a support agent needs neither and should be reachable by anyone. Three jobs, three different shapes, three different access rules.

These are three separate blueprints with nothing connecting them. Build each on its own, or drop all three onto one canvas - either way they operate independently.

Prerequisites

• A ChatBotKit account (any plan)
• A Slack workspace where you can install apps
• One Slack app per agent - each needs its own Bot User OAuth Token (xoxb-…) and Signing Secret. See the Slack integration guide for creating them from a generated manifest.
• The channel IDs and user IDs you want to scope each agent to
• About 30-45 minutes

Tip: A Slack channel ID looks like C01ABCDE234; a user ID looks like U01ABCDE234. Copy a channel's ID from Channel details → About, or a user's from their profile's ⋮ → Copy member ID.

Step 1: The Coding Agent (@dev) - a Real Shell Sandbox

A coding agent is only useful if it can actually run things. @dev gets three shell abilities that execute in an isolated, ephemeral sandbox - note there is no Space here; the sandbox is created per run and thrown away, which is exactly what you want for compiling, testing, and scratch work.

• bash (shell/exec) - run commands and scripts
• rw (shell/rw) - read and write files in the sandbox (with optional line ranges)
• import (shell/import) - pull a file from a URL into the sandbox

Access is locked to your engineering channel plus the engineering lead. And to make the "any model" point concrete, this agent runs on a code-specialized model - swap it for whatever you prefer.

Replace C07ENGCHAN1 and U07ENGLEAD1 with your real engineering channel and lead user IDs. Leave botToken and signingSecret empty in the YAML and fill them in through the Designer after importing - they're secrets and shouldn't live in shared blueprint code. Invite the bot to #engineering with /invite @dev, and you can tag it with a stack trace to get a reproduced, tested fix back.

Step 2: The Research Agent (@research) - Its Own Report Library

The researcher has a different shape. It reads the web and writes durable reports it can reuse later - so it gets web tools plus its own Space (a persistent file store, not shared with anyone). The space/storage/* abilities are bound to that Space.

• Search Web (search/web) and Fetch Web Page (fetch/text/get) - gather sources
• List / Read / Write Report (space/storage/*) - maintain the research library in its own Space

Scope it to #research (C07RSCHCHN1). Now @research analyse the top three vector databases on price and latency will search, fetch sources, write a report into its library, and post a sourced summary - and next time, it can read the saved report instead of redoing the work.

Step 3: The Support Agent (@support) - Lean and Open

The support agent is the opposite of the coder: no sandbox, no Space, just web lookup and a friendly answer. Because it serves the whole team, its allowFrom is * (everyone), and references + ratings are on so answers carry sources and collect 👍/👎 feedback. contactCollection is on to log who's asking.

allowFrom: '*' lets anyone use it. If you'd rather keep it to one public channel, replace * with that channel's ID.

Step 4 (Optional): Make the Researcher Proactive

A great Claude Tag also shows up on its own. Add a trigger that wakes @research every Monday to summarise what's new in its library and post a digest - and a Post to Slack ability so it can deliver the message to the research channel.

This version of the research blueprint adds two nodes (a slack/conversation/start[by-id] ability and a triggerIntegration) on top of Step 2:

The trigger fires 0 9 * * 1 (09:00 every Monday, Europe/London) and posts through the Post to Slack ability. The same pattern works for any agent - give it a send ability and a schedule.

Access Control, Per Agent

Because each agent is its own integration, you tune access independently with allowFrom - and it's enforced before the model runs, so a blocked sender's message never reaches the agent. No prompt-injection trick gets past it.

Rules of thumb:

• Use IDs, not @username/#channel-name, for anything security-sensitive - names can be renamed or transferred, IDs are stable.
• An empty allowFrom denies everyone; * allows everyone. There's no "default open" by accident.
• Give the most powerful agent (the one with the shell) the tightest boundary.

Choose Your Models (Including Local)

ChatBotKit is model-agnostic, so each agent's model is an independent choice. In this tutorial @dev runs on a code-specialized model while @research and @support run on a general one - but you can mix freely:

• A frontier model for hard reasoning (architecture, research synthesis)
• A fast, cheap model for high-volume support
• A local, self-hosted model for agents that touch sensitive code or data - point the bot at your own model endpoint and nothing leaves your network

Change a bot's model field, or set it in the Designer, and the same blueprint runs on entirely different infrastructure. Nothing else in the agent has to change.

Going Further

• More agents - add a @data analyst (SQL + chart abilities), a @notes second-brain (its own Space), or a @releases bot on a triggered schedule. Each is another small, independent blueprint.
• Datasets - attach a Dataset to @support for retrieval-augmented answers grounded in your own docs.
• MCP - connect external tools (CRM, ticketing, data warehouse) via an MCP server resource and expose them as abilities to just the agent that needs them.
• Versioning - clone a blueprint to experiment, and download the YAML for source control. See Blueprints for the full resource reference.

You now have an advanced Claude Tag without the Claude Tag plan requirement: independent specialized agents, each scoped to the right people, each running on the model you choose - including local ones - all built from blueprints anyone can use.