Which OpenTag This Article Covers
Search "OpenTag" and you'll find two unrelated projects. This article is about CopilotKit/OpenTag — an open-source Slack agent starter built on CopilotKit's bot SDK. It is not amplifthq/opentag, a different project that dispatches Slack, GitHub, or Lark requests to a locally-run Codex or Claude Code instance and posts the result back as a pull request. The two share a name and a Slack connection and nothing else — different architecture, different purpose, different maintainers. If you found this looking for the dispatcher-style tool, this isn't it; everything below is CopilotKit's.
What CopilotKit OpenTag Is
CopilotKit OpenTag is an open-source starter for running an AI agent inside Slack — one that reads a thread, responds, calls tools, and renders results as rich UI rather than plain text. It's built on @copilotkit/bot, an open SDK from CopilotKit (the company behind the AG-UI protocol) for building agents into chat platforms. The project ships inside the CopilotKit monorepo as a first-class example (examples/slack), which is currently the dependable way to run it while the standalone bot packages finish publishing to npm.
The pitch is architectural: rather than a closed product you configure, OpenTag is code you own and run — a working Slack agent you can read, modify, and extend, built on a platform-agnostic engine that isn't actually Slack-specific underneath.
Why Developers Compare It with Claude Tag
Developers reach for this comparison because OpenTag addresses the same surface-level need — an AI agent that participates in Slack conversations — but from the opposite direction: open-source and self-hosted instead of a closed, hosted product. With OpenTag, you bring your own model (OpenAI or Anthropic), run the runtime yourself, and own the code end to end, in exchange for doing the operational work a hosted product would otherwise handle. It's worth being precise about what this comparison is and isn't: it's a comparison of approach, not a claim that OpenTag is an official or equivalent replacement for any specific commercial product. Nothing here establishes that relationship — the two occupy the same category by function, not by pedigree.
Core Architecture
Slack app and manifest
A Slack agent starts as a Slack app: a manifest that defines the bot's identity and the scopes it needs to read messages, post replies, and render rich content in a channel or thread. This is standard Slack app infrastructure, not something OpenTag invents — the project's role is providing the agent logic that sits behind that app once it's registered, not replacing the Slack app setup itself.
Bot and app tokens
Slack apps authenticate with tokens, and OpenTag's runtime needs them configured as secrets to connect. The project's own framing is candid about this part: standing up hosting and secrets for a chat agent is real operational work, not a trivial config step — one of the reasons a managed alternative exists for teams that want to skip it. Architecturally, the bot process is what holds this platform connection; the token setup is what lets it authenticate to Slack specifically (the same bot logic connects to other platforms via their own credentials, covered below).
Agent runtime and backend
OpenTag runs as two processes: the agent, which is the LLM backend — a single CopilotKit BuiltInAgent (an LLM plus optional MCP tools, with no Python and no LangGraph in the path), served over the AG-UI protocol — and the bot, which is the platform connection that relays messages between Slack and the agent. This split matters architecturally: the agent backend doesn't know or care that it's talking to Slack specifically, and the bot doesn't contain any model logic — it's a thin, platform-specific adapter in front of a platform-agnostic engine. The agent's actual behavior is steered by a single system prompt in the runtime code; changing that prompt is how you change what the agent does, without touching the platform-connection layer at all.
BYO OpenAI or Anthropic model
The agent backend is a wrapper around a model you supply — bring your own OpenAI or Anthropic API key, and that's the model doing the reasoning. There's no bundled or proprietary model here: OpenTag is the runtime and orchestration around a model call you control, which means your model costs, your rate limits, and your provider relationship apply directly, unmediated by the starter. This is the same "bring your own everything" posture as the rest of the architecture — the project supplies the scaffolding, you supply the credentials that make it live.
Where It Fits Developer Workflows
OpenTag fits teams that want a Slack agent they fully own and can freely modify — internal tool teams building something specific to how their organization works, developers prototyping an agent-in-chat pattern before committing to a platform, or anyone who wants to see exactly how a generative-UI, human-in-the-loop Slack agent is built rather than configuring one as a black box. Because the underlying bot engine is platform-agnostic, it also fits teams anticipating they'll want the same agent on Discord, Telegram, or WhatsApp later — the platform-specific piece is a thin adapter, not a rewrite.
It fits less well as a zero-ops path to a production Slack agent today: self-hosting means you're responsible for the runtime, the secrets, and the operational reliability yourself, and the standalone package isn't yet on npm outside the monorepo example. Teams that want the same underlying capability without owning the operations are the intended audience for CopilotKit's managed alternative, discussed below — OpenTag is deliberately the "you own it" path, not the path of least operational resistance.
Limits, Risks, and Maintenance Questions
OpenTag is under active development, which cuts both ways: the architecture and feature set (generative UI, the human-in-the-loop gate, multi-platform support) are real and demonstrated, but the standalone SDK packages are still finishing their path to npm, and the fastest-moving parts of any actively developed open-source project are the ones most likely to change between when this is written and when you read it. Treat specifics — package publishing status, exact configuration, feature completeness — as things to verify against the current repository rather than assume.
The bigger ongoing question for any team adopting it is maintenance: self-hosting an agent runtime means you own its uptime, its updates, and its operational health, not a vendor. CopilotKit's own framing acknowledges this directly — hosting and scaling a chat agent's runtime, persistence, and inspection tooling is real work, which is precisely the gap their managed offering (part of an Enterprise Intelligence platform, available as cloud-hosted or self-hosted, and stated as coming soon at the time of writing) is built to close. If you adopt OpenTag for anything beyond a prototype, plan for that ongoing operational ownership as a real cost, not an afterthought — and check the current status of the managed path if reducing that ownership is part of your calculus.
FAQ
Is CopilotKit OpenTag an official Claude Tag replacement?
No, and the project doesn't claim that relationship. OpenTag is an open-source, self-hosted way to build a Slack agent with a bring-your-own-model architecture — it addresses a similar need to hosted Slack-agent products through a different approach (open code, your infrastructure, your model), but that's a comparison of category and approach, not an official or equivalent replacement relationship with any specific commercial product. If you're evaluating OpenTag against a hosted alternative, compare them on their actual architecture and operational trade-offs — ownership and control versus operational simplicity — rather than assuming one is a drop-in substitute for the other.
How is CopilotKit OpenTag different from amplifthq/opentag?
They're unrelated projects that happen to share a name. CopilotKit/OpenTag is a Slack-first agent starter built on @copilotkit/bot, where the agent itself (an LLM plus tools) handles the conversation, renders generative UI, and pauses at human-approval gates before taking action — the intelligence lives in the agent runtime. amplifthq/opentag is a dispatcher: it routes requests arriving from Slack, GitHub, or Lark to a locally-running coding agent (Codex or Claude Code), which does the actual work and reports back as a pull request — the intelligence lives in the coding agent it dispatches to, not in OpenTag's own logic. Different architecture, different job, different maintainers. If you're looking for one and found information about the other, they don't substitute for each other.
What parts of CopilotKit OpenTag must a team host?
In the self-hosted, open-source path — the default and only currently-available option — you host both processes: the agent backend (the LLM wrapper and runtime) and the bot (the platform connection), plus the secrets and infrastructure that keep both running reliably. That includes the operational concerns CopilotKit's own materials flag as real work: standing up hosting, managing persistence for conversation continuity, and building inspection tooling for visibility into the agent. A managed alternative handling this layer is described as coming soon at the time of writing — confirm its current availability in CopilotKit's official materials if reducing your hosting responsibility matters to you.
What should developers verify before using it at work?
Before adopting OpenTag for real work, verify the things that are specific to an actively developed open-source project and can change: the current state of the standalone npm packages versus the monorepo example, the license terms in the current repository, and the exact scopes and data access the Slack app manifest requests (since a chat agent with tool access can touch real workspace data and take real actions). Also verify what model provider terms apply to whatever OpenAI or Anthropic key you connect, since that's a separate relationship from the OpenTag project itself. None of these are unusual questions for adopting any open-source infrastructure — they're the standard checks worth doing before an actively developed project touches your team's real Slack workspace, and the answers are best confirmed against the current repository and documentation rather than assumed from a snapshot in time.
Conclusion
CopilotKit OpenTag is an open-source starter for building a Slack agent on @copilotkit/bot — a platform-agnostic engine (the same code can run on Discord, Telegram, or WhatsApp) wrapped in a Slack-first example, with generative UI, a human-in-the-loop approval gate, and a bring-your-own-model architecture for OpenAI or Anthropic. Its value is architectural: you get real, working code you own and can modify, not a black-box product — at the cost of hosting the runtime, the secrets, and the operational reliability yourself. It is not, and doesn't claim to be, an official replacement for any specific commercial Slack-agent product, and it's a distinct project from amplifthq/opentag despite the shared name. If you want to understand or build on this pattern directly, OpenTag is a real, inspectable starting point; if you want the same capability without the operational ownership, CopilotKit's managed path is the alternative to watch, with its current availability worth confirming before you decide between them.
Related Reading
