CopilotKit Channels SDK 0.5.0 is an MIT-licensed library that lets existing AG-UI agents run inside Slack and Microsoft Teams without per-platform rewrites.
Most AI agents remain trapped in demo environments. They answer questions in a web chat widget, but they do not show up in the channels where teams actually coordinate work. CopilotKit’s newly open sourced Channels SDK aims to change that. The MIT licensed library, published as @copilotkit/channels 0.5.0 on npm on July 8, 2026, lets developers connect any AG-UI agent to Slack and Microsoft Teams without building a separate bot for each platform.
The initial early access surfaces are Slack and Microsoft Teams, and the SDK is built around AG-UI. Existing agents that already speak AG-UI — including LangGraph, CrewAI, Mastra, Pydantic AI, Google ADK, or a plain HTTP agent — can be connected without a per-platform rewrite. The companion package @copilotkit/channels-core 0.5.0 and runtime package @copilotkit/runtime 1.64.2 are released in the same cycle, giving developers a complete toolkit for moving agentic workflows from prototype to production.
For teams that have invested in an agent framework, the value proposition is simple: keep your agent logic, swap the delivery layer, and meet users where they already work.
AG-UI is not a new framework. It is a protocol for agent-to-UI communication. It defines how an agent sends structured messages, tool calls, and rendering instructions to a client. By standardizing that contract, AG-UI lets a single agent drive multiple front ends.
Without this layer, every platform integration becomes a custom project. You build a Slack bot, then reimplement the same logic for Teams, then do it again for Discord. The Channels SDK flips that model: the agent stays in one place, and the channel becomes a pluggable transport and rendering target.
That is why the SDK can support so many agent frameworks at launch. LangGraph, CrewAI, Mastra, Pydantic AI, Google ADK, and even a plain HTTP agent all speak AG-UI. Each one can connect to CopilotRuntime and, through it, to Slack and Teams.
One of the most important mental shifts in the new SDK is understanding what a channel actually represents. MarkTechPost put it succinctly: “The distinction that matters is what a channel is not. It is not a second agent. It is a transport along with a rendering target.”
This distinction shapes the developer experience. You do not build a separate Slack agent and a separate Teams agent. Instead, you author messages once as JSX and let the SDK lower them to native platform UI — such as Slack Block Kit and Microsoft Teams Adaptive Cards. The agent remains the single source of truth; the channel only handles delivery and presentation.
The separation also makes maintenance easier. When you update your agent’s prompts, tools, or workflow logic, every connected channel picks up the change immediately. There is no duplicated bot logic to synchronize across platforms.
The runtime lifecycle is owned by CopilotRuntime. Developers create a channel, start a listener, and await channels.ready() to detect misconfiguration early and fail fast. Notably, there is no channel.start() method. The startup pattern is simple:
channels.ready().The startup timeout defaults to 30,000 ms, giving developers enough time to connect external services before the runtime reports readiness. If the configuration is wrong, the failure is explicit rather than surfacing later as a mysterious connection drop.
Deployment requires Node.js 22 or later, an ESM project, and a long-running process or container. Serverless functions will not hold the channel connection open, so teams should plan for persistent workers or managed container environments.
Every channel requires a CopilotKit Intelligence API key, whether using a managed or direct adapter. The managed provider union in the shipped types is only "slack" | "teams", while Discord, Telegram, and WhatsApp ship as direct adapters.
The 0.5.0 type definitions include just two managed channel providers: Slack and Teams. However, the package surfaces five adapter entry points as subpath exports: Slack, Teams, Discord, Telegram, and WhatsApp.
This split matters. Managed providers handle more of the operational burden, while direct adapters give you lower-level control. In either case, the API key requirement remains, and all adapters work with the same AG-UI agent core. The result is a consistent authoring model across a rapidly expanding set of surfaces.
The SDK is designed for workflow-oriented interactions, not just chatbots. It supports:
Imagine an agent that monitors a support channel, responds to /triage commands, and posts a Teams Adaptive Card with a proposed action. A user can approve or reject that action inline without leaving the chat window. The same agent can later run in Slack without a redesign because the core logic was never coupled to a specific platform.
The workflows you can build go beyond simple chat. Here are three patterns that show the power of a platform-agnostic channel layer.
A customer support team might use Slack internally and Microsoft Teams with partners. A single AG-UI agent can monitor both environments, apply the same triage policy, and escalate to a human when confidence is low. Because the agent is not bound to either chat platform, updates to the triage workflow propagate everywhere.
An agent connected to a ticketing system can propose assigning an issue, create a Linear ticket, and post an Adaptive Card asking for approval. The human-in-the-loop pattern ensures nothing is mutated without consent. This is especially valuable for tools like Notion or Jira, where accidental writes are costly.
Cross-platform transcripts and persistence features give organizations a unified audit trail of agent actions. When users interact from different collaboration tools, the same conversation history can be stored and searched in one place.
A concrete example of the human-approval pattern comes from OpenTag. It demonstrates how to intercept every Linear and Notion mutation before the Model Context Protocol (MCP) request runs, requiring confirm_write before proceeding.
This kind of guardrail is essential for production agentic systems. When an AI agent can create issues, update tickets, or modify knowledge bases, a simple approval step can prevent costly mistakes. The Channels SDK makes this pattern reusable across collaboration platforms instead of building a bespoke integration for each one.
The decision to release the SDK under an MIT license is significant. It lowers the barrier for enterprise adoption, allows teams to inspect and modify the code, and signals confidence in the long-term direction of the project.
Open-source, MIT-licensed AI agent infrastructure is a rising trend in the current release cycle. Protocol-driven interoperability via AG-UI is also gaining momentum. By pairing these two trends, CopilotKit is positioning the Channels SDK as a foundational piece of the agent ecosystem rather than a closed, one-off tool.
Slack and Teams are no longer just chat windows; they are becoming control planes for AI work. Human-in-the-loop approvals are rising alongside that adoption, because autonomy without oversight is not viable in most enterprise workflows.
To start using the Channels SDK, keep these requirements in mind:
@copilotkit/channels and configure CopilotRuntime.channels.ready().Finally, deploy the application as a long-running process or container. Serverless functions will close the channel connection, so plan for a persistent runtime.
The CopilotKit Channels SDK 0.5.0 is a meaningful step toward write-once, run-anywhere AI agents. By treating a channel as a transport and rendering target — not as a second agent — it lets teams connect existing AG-UI agents to Slack and Microsoft Teams with minimal friction.
Key takeaways:
If you are building agentic applications for the workplace, the Channels SDK is worth evaluating now. The era of one-off platform integrations is ending; AG-UI and open-source channel SDKs are pointing the way forward.
CopilotKit Channels SDK is an MIT-licensed library, published as @copilotkit/channels, that lets existing AG-UI agents run inside Slack and Microsoft Teams without building a separate bot for each platform. It treats the channel as a transport and rendering target, not a second agent, so you reuse your existing agent logic and simply connect it to messaging platforms.
AG-UI is a protocol that standardizes how an agent sends structured messages, tool calls, and rendering instructions to a client. With the Channels SDK, your existing AG-UI agent stays in one place, and the channel (Slack or Teams) becomes a pluggable transport and rendering target, allowing a single agent to drive multiple front ends without custom integrations.
The SDK supports any agent that already speaks AG-UI, including LangGraph, CrewAI, Mastra, Pydantic AI, Google ADK, and even a plain HTTP agent. Because these frameworks all use the AG-UI protocol, they can connect to CopilotRuntime and then to Slack and Teams without per-platform rewrites.
No. A channel is not a second agent; it is a transport along with a rendering target. This distinction means you avoid reimplementing the same logic for each platform. The agent remains the single source of truth, and the channel only handles how messages and tool calls are delivered and displayed in a specific messaging app.
You start by installing the @copilotkit/channels package (version 0.5.0) and, if needed, @copilotkit/channels-core. Then you connect your AG-UI agent to CopilotRuntime, and use the Channels SDK to expose that runtime to Slack or Microsoft Teams. You keep your existing agent logic and only change the delivery layer, so there is no need to rewrite the agent for each platform.
