Hey all, I'm CEO of CopilotKit, the startup behind AG-UI and the Channels SDK.
Thanks for the support!
We're pretty excited for this one -- I think channels may soon become the 3rd big form factor of LLMs (after Chat, and Codex/Claude-Code style agents).
We've worked really hard to to shrink the onboarding setup to a single prompt:
It's literally that easy. Then it will help you create a coworker-grade Slack / Teams agent backed by basically any of the top agent frameworks and harnesses out there.
Would love to get feedback, especially if you hit any snags
I think this is likely a very good idea. I've thought about the idea of channels a lot building https://wingman.actor and I've gone back in forth on if channel primitives are a good idea at a low level or if existing chat clients are just an already well defined utility you shouldn't rewrite.
I think your approach of a unified SDK/data structure around a chat that adapts to different clients is a really strong solution that probably just gives you the best of both worlds.
Btw if you build a wingman AG-UI adapter the Channels SDK would just work with it.
Nowadays, you can honestly get this done in probably less than a day of work --we've got a pretty good factory set up with validators and tests, etc.
Not necessarily wrong, but that's just a maturity problem on our end right now. We're aiming to take the same approach as our web SDKs: it works great for open-source deployments and works even better with Enterprise Intelligence. We had some back-and-forth over webhook vs. WebSocket in the last two weeks that caused some churn on our side.
Delivering AG-UI with generative UI to Slack and Teams should work great with the open-source packages. We'll make these interfaces better and more intuitive.
OP here. I work with Mike on the SDK, and he covered why we built it, so here's how it actually works.
We treat "channel" as one layer with four pieces:
Adapters normalize each platform's webhooks and quirks into a single neutral event shape.
Ops owns delivery, ordering and reconnects. The run loop is ack-first: post the approval card, ack the delivery, and resume the run when the click arrives. That's the reason approvals survive retries and process restarts instead of stranding a half-finished run.
Rendering is a virtual DOM for chat. JSX compiles to native Block Kit or Adaptive Cards. Handler IDs are content hashes rather than generated per deploy, so buttons posted last week still resolve after you ship.
On top of that a small API: createChannel, threads, tools, approvals.
One thing worth being precise about, since licensing is the top comment. Intelligence is the backend layer: rich threads (AG-UI), memory, learning, analytics, governance. It is self-hosted and it does not call out anywhere. And CopilotKit is not an agent. We don't make model calls; your agent does, in your infrastructure, against whatever provider you already use.
From quick glance I don’t think so that’s the case. copliotkit promises ag-ui compatiblity., which means it can work with codex cli, mastra, pi, claude agents sdk and other harnesses as well (there are ag ui adapters as well). I’m actually integrating this with claude agent sdk with ag ui adapter., which i don’t think is possible with vercel chat sdk.
I first found out about chat-sdk existence when I was upgrading my nanoclaw (its core feature is that it uses claude agent sdk under the hood as the harness) to v2 and they were migrating to chat-sdk as their base layer for supporting different channels.
It was pretty limited thought in terms of what I needed, so I had to through it away and build my own telegraf sdk based channel implementation for telegram, but that was a while ago, I assume they should have evolved a lot from the time I last touched it about 3 months ago.
Hey, I'm Nathan, DevRel at CopilotKit. That is a really interesting point you are making, and we've heard it a lot. One of the reasons this is so powerful is that it uses AG-UI as the transport, which enables a lot of flexibility depending on your use case. I would love to get your feedback if you decide to give it a spin.
Not proprietary and not a wrapper. Chat SDK served as inspiration, of course, but I think it misses a few hard parts of bringing agents to chat interfaces:
- Generative UI in these surfaces needs to be durable. If your agent composes a Block Kit or Adaptive Cards interface with interactivity, you have to be ready to handle that interactivity weeks later. We handle this with our JSX renderer.
- Chat interfaces are inherently multiplayer. The worst thing you can do is have your agent act like a bot: posting all of the time, creating noise, and offering no customization. I think Claude Tag nailed the user experience here, and now we want to empower developers to create agents with a similar UX via open source.
- Truly agent-and-surface agnostic. We're fully powered by AG-UI (ag-ui.com), so you can bring any agent into Slack and then take that same agent to web or mobile all over the same protocol.
Fair on AG-UI, that part is a real difference. But the Chat SDK point is a bit overstated: vercel/chat also has a JSX card system that renders to Block Kit and Adaptive Cards, with button and action handlers and pluggable state backends.
> Chat interfaces are inherently multiplayer.
Both chat and channel sdks support subscribing to threads and can control messages that arrive concurrently. In that regard it feels like this depends more on the logic of the app itself rather than gets defined by the framework/dependency it uses.
Hi folks! I'm one of the engineers working on the Channels SDK. This is our first public release. Our emphasis has been on making agents act like natural participants in Slack and Teams, while letting them generate UI along the way. It's built on top of AG-UI, so any agent that emits AG-UI can be brought to Slack or Teams.
We've been dogfooding this internally and have seen a surge of tiny, task-specific agents enter our channels. A lunchbot agent wraps the DoorDash CLI to handle office lunch orders, a pupfood agent wraps the Pup and GitHub CLIs to do incident triage, and a chadbot generates marketing videos on demand from GitHub PRs. We've got even more that compose PostHog, Notion, Linear, and other internal tools we use.
I had previously been pretty hot about bringing agents to the web, but I'm increasingly convinced that chat interfaces are the most natural home for useful agents.
Happy to answer any questions about our approach here!
I like the idea of having a much easier way to integrate with all of the chat clients, especially with UI. I've been surprised there wasn't a way to do that more easily before (even pre AI agent revolution).
Two points of confusion that I wanted to bring up just so you know what it was like for me as a new reader: "Copilot" is unfortunately an extremely overloaded term right now. Not your fault, but I don't know about CopilotKit, so I was trying to figure out who really was behind this. (Is it Microsoft? etc)
I also (like another poster) wondered if I needed your server in order to use this. I love the MIT license, but it wasn't clear to me if this was just a veneer over a closed-source thing or not. I saw in your response that there is a legit open source ability to use it, but that wasn't clear.
WhatsApp is only supported on the open-source side of the SDKs right now. Full support for WhatsApp in the hosted service is on the roadmap. Point your agent at github.com/copilotkit/copilotkit, where the Channels SDKs live, and it should be able to pick it up.
I have been using eve - https://eve.dev/ recently and it was just really nice and well thought out. It also supports TUI, github and other non chat channels.
The integration and abstraction with sandboxes, cron etc. is very nicely done but you still can self host it.
Hey all, I'm CEO of CopilotKit, the startup behind AG-UI and the Channels SDK. Thanks for the support!
We're pretty excited for this one -- I think channels may soon become the 3rd big form factor of LLMs (after Chat, and Codex/Claude-Code style agents).
We've worked really hard to to shrink the onboarding setup to a single prompt:
"Read https://copilotkit.ai/channels-guide.md and help the user build their first channel".
It's literally that easy. Then it will help you create a coworker-grade Slack / Teams agent backed by basically any of the top agent frameworks and harnesses out there.
Would love to get feedback, especially if you hit any snags
I think this is likely a very good idea. I've thought about the idea of channels a lot building https://wingman.actor and I've gone back in forth on if channel primitives are a good idea at a low level or if existing chat clients are just an already well defined utility you shouldn't rewrite.
I think your approach of a unified SDK/data structure around a chat that adapts to different clients is a really strong solution that probably just gives you the best of both worlds.
Cool stuff!
Btw if you build a wingman AG-UI adapter the Channels SDK would just work with it. Nowadays, you can honestly get this done in probably less than a day of work --we've got a pretty good factory set up with validators and tests, etc.
Happy to help if interested!
I dont think it s really open source, the MIT part is just the client. The service that actually makes it run is closed and license-gated.
Not necessarily wrong, but that's just a maturity problem on our end right now. We're aiming to take the same approach as our web SDKs: it works great for open-source deployments and works even better with Enterprise Intelligence. We had some back-and-forth over webhook vs. WebSocket in the last two weeks that caused some churn on our side.
If you point your agent at our SDKs, they should help you use the Slack or Teams adapters directly without leveraging the hosted service: https://github.com/CopilotKit/CopilotKit/tree/main/packages/...
Delivering AG-UI with generative UI to Slack and Teams should work great with the open-source packages. We'll make these interfaces better and more intuitive.
OP here. I work with Mike on the SDK, and he covered why we built it, so here's how it actually works.
We treat "channel" as one layer with four pieces:
Adapters normalize each platform's webhooks and quirks into a single neutral event shape.
Ops owns delivery, ordering and reconnects. The run loop is ack-first: post the approval card, ack the delivery, and resume the run when the click arrives. That's the reason approvals survive retries and process restarts instead of stranding a half-finished run.
Rendering is a virtual DOM for chat. JSX compiles to native Block Kit or Adaptive Cards. Handler IDs are content hashes rather than generated per deploy, so buttons posted last week still resolve after you ship.
On top of that a small API: createChannel, threads, tools, approvals.
Diagram of the open-source path, since that question came up elsewhere in the thread: https://github.com/CopilotKit/channels-sdk/blob/main/assets/...
One thing worth being precise about, since licensing is the top comment. Intelligence is the backend layer: rich threads (AG-UI), memory, learning, analytics, governance. It is self-hosted and it does not call out anywhere. And CopilotKit is not an agent. We don't make model calls; your agent does, in your infrastructure, against whatever provider you already use.
Is it like a proprietary wrapper for Vercel’s Chat SDK (https://github.com/vercel/chat)?
From quick glance I don’t think so that’s the case. copliotkit promises ag-ui compatiblity., which means it can work with codex cli, mastra, pi, claude agents sdk and other harnesses as well (there are ag ui adapters as well). I’m actually integrating this with claude agent sdk with ag ui adapter., which i don’t think is possible with vercel chat sdk.
I first found out about chat-sdk existence when I was upgrading my nanoclaw (its core feature is that it uses claude agent sdk under the hood as the harness) to v2 and they were migrating to chat-sdk as their base layer for supporting different channels.
It was pretty limited thought in terms of what I needed, so I had to through it away and build my own telegraf sdk based channel implementation for telegram, but that was a while ago, I assume they should have evolved a lot from the time I last touched it about 3 months ago.
Hey, I'm Nathan, DevRel at CopilotKit. That is a really interesting point you are making, and we've heard it a lot. One of the reasons this is so powerful is that it uses AG-UI as the transport, which enables a lot of flexibility depending on your use case. I would love to get your feedback if you decide to give it a spin.
Not proprietary and not a wrapper. Chat SDK served as inspiration, of course, but I think it misses a few hard parts of bringing agents to chat interfaces:
- Generative UI in these surfaces needs to be durable. If your agent composes a Block Kit or Adaptive Cards interface with interactivity, you have to be ready to handle that interactivity weeks later. We handle this with our JSX renderer.
- Chat interfaces are inherently multiplayer. The worst thing you can do is have your agent act like a bot: posting all of the time, creating noise, and offering no customization. I think Claude Tag nailed the user experience here, and now we want to empower developers to create agents with a similar UX via open source.
- Truly agent-and-surface agnostic. We're fully powered by AG-UI (ag-ui.com), so you can bring any agent into Slack and then take that same agent to web or mobile all over the same protocol.
Fair on AG-UI, that part is a real difference. But the Chat SDK point is a bit overstated: vercel/chat also has a JSX card system that renders to Block Kit and Adaptive Cards, with button and action handlers and pluggable state backends.
> Chat interfaces are inherently multiplayer.
Both chat and channel sdks support subscribing to threads and can control messages that arrive concurrently. In that regard it feels like this depends more on the logic of the app itself rather than gets defined by the framework/dependency it uses.
Hi folks! I'm one of the engineers working on the Channels SDK. This is our first public release. Our emphasis has been on making agents act like natural participants in Slack and Teams, while letting them generate UI along the way. It's built on top of AG-UI, so any agent that emits AG-UI can be brought to Slack or Teams.
We've been dogfooding this internally and have seen a surge of tiny, task-specific agents enter our channels. A lunchbot agent wraps the DoorDash CLI to handle office lunch orders, a pupfood agent wraps the Pup and GitHub CLIs to do incident triage, and a chadbot generates marketing videos on demand from GitHub PRs. We've got even more that compose PostHog, Notion, Linear, and other internal tools we use.
I had previously been pretty hot about bringing agents to the web, but I'm increasingly convinced that chat interfaces are the most natural home for useful agents.
Happy to answer any questions about our approach here!
I like the idea of having a much easier way to integrate with all of the chat clients, especially with UI. I've been surprised there wasn't a way to do that more easily before (even pre AI agent revolution).
Two points of confusion that I wanted to bring up just so you know what it was like for me as a new reader: "Copilot" is unfortunately an extremely overloaded term right now. Not your fault, but I don't know about CopilotKit, so I was trying to figure out who really was behind this. (Is it Microsoft? etc) I also (like another poster) wondered if I needed your server in order to use this. I love the MIT license, but it wasn't clear to me if this was just a veneer over a closed-source thing or not. I saw in your response that there is a legit open source ability to use it, but that wasn't clear.
I saw WhatsApp listed but I can't find how the integration works?
WhatsApp is only supported on the open-source side of the SDKs right now. Full support for WhatsApp in the hosted service is on the roadmap. Point your agent at github.com/copilotkit/copilotkit, where the Channels SDKs live, and it should be able to pick it up.
This is one side of the problem: where does your agent show up.
And the other side is: where does the agent run
And the third side ;-): security.
Well done on this bit. I like the smooth onboarding.
This looks great. I was thinking of using this until I saw the pricing for Team.
I dread the day when my employer's Slack includes chatbots rambling all over it.
This is amazing! I love the idea of any agent running on any surface and this feels like the next step in that process.
I have been using eve - https://eve.dev/ recently and it was just really nice and well thought out. It also supports TUI, github and other non chat channels.
The integration and abstraction with sandboxes, cron etc. is very nicely done but you still can self host it.
Great idea! I love it.
Mastodon support? Discord scans everything posted on it.
How can we get more "channels" into this?