Show HN: The Channels SDK – Bring Any Agent to Any Channel (Slack, MS Teams)
github.com
github.com
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 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.
Happy to help if interested!
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.
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.
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!
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.
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.
- 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.
> 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.
The integration and abstraction with sandboxes, cron etc. is very nicely done but you still can self host it.
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.