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
swiftlyTyped
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.
ChaseRensberger
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.
chengyongru
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.
davidmckayv
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 dread the day when my employer's Slack includes chatbots rambling all over it.
SwellJoe
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.
mrud
This is amazing! I love the idea of any agent running on any surface and this feels like the next step in that process.
mefinsf
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.
comments (10)
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
swiftlyTyped
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.
ChaseRensberger
chengyongru
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.
davidmckayv
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!
mikeryan52
opwizardx
SwellJoe
The integration and abstraction with sandboxes, cron etc. is very nicely done but you still can self host it.
mrud
mefinsf
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.
lukasco