Show HN: The Channels SDK – Bring Any Agent to Any Channel (Slack, MS Teams)

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 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.

[dead]

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.