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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I dread the day when my employer's Slack includes chatbots rambling all over it.