Caspian SDK: An Open-Source Agent Communication SDK for Email, Slack, and Discord

Most AI agents only exist inside one chat window. They can reason, plan, and call tools, but the moment a human needs to hear from them somewhere else, a developer has to bolt on a Slack bot, an email poller, and a Discord client by hand. Caspian SDK is an open-source agent communication SDK that removes that step. It gives an agent one identity and a real inbox and outbox across the channels people already use, with a single handler that answers on all of them.

The project is built by TryCaspian and sits at github.com/TryCaspian/caspian-sdk. As of today it has 653 stars and 133 forks, created in mid-July 2026 and still shipping commits daily, so this is an early but active project rather than an established standard.

What it actually does

Caspian separates two things that most agent integrations tangle together: what the agent decides to say, and how that message physically reaches a human. You write one on_message handler and call connect_email(), connect_slack(), connect_telegram(), and so on. Every channel normalizes into the same conversation and message model, and message.reply() always answers in the right thread on whatever platform the message came in from. The pitch is that a team building a support or assistant agent shouldn't have to maintain four separate auth flows, four payload shapes, and four reconnect loops just to let the agent talk.

Channels that actually work today

This is where scan notes and marketing pages tend to blur, so it's worth being precise. Pulling directly from the current README, self-hosted with your own credentials, the SDK supports email (an instant hosted inbox), Telegram bots, Discord, Slack, Zulip, Bluesky, GitHub issues and PRs, Instagram DM, and Facebook Messenger. X/Twitter and SMS also work, but with real strings attached: X requires a paid X developer API subscription (the free tier is write-only), and SMS needs your own GSM modem and SIM. There's also a Telegram user-account mode that automates a personal account over MTProto rather than a bot, which the project itself flags as ToS-gray and opt-in only.

WhatsApp Business, phone and voice, iMessage, and RCS are listed as hosted-only, meaning they run through Caspian's managed gateway rather than something you self-host with your own credentials today. Anyone who scanned this repo and walked away thinking "email, WhatsApp, Slack, Discord" all work the same way should know WhatsApp specifically is not a bring-your-own-credentials integration yet.

Setup and authentication

Installation is pip install caspian-sdk or npm install caspian-sdk, plus the separate caspian-cli tool (pipx install caspian-cli or uvx caspian-cli) to run caspian init, which mints an API key and writes it to a .env file. Free channels, email, Telegram, Slack, Discord, Bluesky, connect instantly with no developer sign-in. Paid channels (X, WhatsApp, iMessage) require a one-time caspian login and prepaid credit added through their dashboard. By default the SDK talks to Caspian's hosted gateway at api.trycaspianai.com, though the repo ships a docker-compose.yml for teams that want to self-host that gateway instead of routing traffic through the vendor's servers.

On licensing: the client libraries you actually pip install or npm install are MIT licensed, permissive and safe to embed in a commercial product. The root of the monorepo, which includes the gateway server code, carries an AGPL-3.0 license. That distinction matters if you plan to run your own gateway rather than use the hosted one, since AGPL requires you to share source changes to any network service you build on it. The README's badge says Apache-2.0, which does not match the actual LICENSE file in the repo, so check the license file directly before you build anything on the self-hosted server path.

The part worth being direct about

Giving an agent a real outbox is exactly as risky as it sounds. Once message.reply() is wired up, the agent can send a reply on Slack, email, or Discord the moment it decides to, with nothing in the SDK itself forcing a human to look at the message first. The library gives you webhook verification and capability negotiation so a channel can't be asked to do something it physically can't, but it does not gate outbound sends behind approval. If your agent is reasoning about who to contact and what to say, a hallucinated recipient or a wrong-channel reply goes out just as fast as a correct one. Anyone deploying this should build their own review step, at least for anything customer-facing, rather than assuming the SDK handles that for them.

How this differs from browser-automation tools

It's easy to lump any "agent plus social platform" tool into one bucket, but Caspian is a different layer than something like a social-account automation tool. Browser automation tools drive a UI to post and manage a single social account. Caspian instead gives an agent a first-class identity across messaging channels through SDKs and provider APIs, email, Slack, Discord, Telegram, and the rest, so the agent can hold a conversation and reply in a thread rather than post and scroll. If your problem is "manage my Instagram account," that's a different tool. If your problem is "let my agent answer people wherever they message it," this is closer to the right shape.

Is it worth adopting

For a team already building an agent that needs to talk to real people rather than just answer in a demo chat window, Caspian is a reasonable bet: free channels cover the common cases (email, Slack, Discord, Telegram) without a credit card, the offline test fakes make it possible to build without hitting real APIs, and the roadmap (an MCP server, Reddit and LinkedIn adapters) suggests active development. The honest caveats are that it's three weeks old as an open project, WhatsApp and voice are hosted-only rather than self-serve, and there is no built-in guardrail against a bad reply going out on a live channel. Treat it as infrastructure worth prototyping with, not something to point at production traffic unsupervised on day one.