vercel/chat: one TypeScript bot for Slack, Teams, Google Chat and Discord

The problem vercel/chat solves: one bot, several messaging platforms

Every messaging platform ships its own event payload shape, its own authentication scheme, and its own idea of what a "thread" is. A Slack mention arrives as a Slack event; the same interaction in Microsoft Teams arrives as a Bot Framework activity. Writing a bot for three platforms usually means writing three sets of handlers that do the same thing.

vercel/chat is a unified TypeScript SDK that puts those platforms behind one API. The README describes it as a way to "write your bot logic once, deploy everywhere", covering Slack, Microsoft Teams, Google Chat, Discord, Telegram, GitHub, Linear, WhatsApp and more. The audience is TypeScript developers building support bots, internal assistants, or AI agents that need to live where their users already are, rather than in a separate web app. The repository layout supports that reading: examples/ contains express-discord-chat, nextjs-chat, nuxt-chat and telegram-chat, so the intended deployment surface is a web app with webhook routes, not a desktop or CLI process.

How the Chat class, adapters and Redis state fit together

The core object is a Chat instance constructed with three things: a userName, an adapters map, and a state store. Each adapter is created by its own factory function, so createSlackAdapter() returns the Slack implementation and the key "slack" is how the rest of the code refers to it. Adding Teams or Google Chat means adding another key and another factory import; the handler code below does not change.

The state store is a separate concern. The README example uses createRedisState() from @chat-adapter/state-redis, which suggests thread subscriptions and similar per-thread data are persisted outside the process. That matters for serverless deployment, where the handler may run in a different instance on the next message. The documentation does not describe the Redis key layout or what happens when the store is unreachable, so the failure behaviour of a Redis outage is not something the README answers.

Handlers are registered on the bot instance. onNewMention fires when the bot is mentioned; onSubscribedMessage fires for later messages in a thread the bot has subscribed to. Subscription is explicit: the example calls thread.subscribe() inside the mention handler, which is what makes subsequent messages arrive at the second handler. This is a deliberate two-step model, and it means a bot that forgets to subscribe will answer the first mention and then go quiet.

Installing vercel/chat and running a first Slack bot

The README's install path is two npm commands: the core package, then one or more adapters. The core package is named chat, not @vercel/chat.

npm i chat

Adapters are separate packages under the @chat-adapter scope. The README shows Slack, Teams and Google Chat installed together:

npm install @chat-adapter/slack @chat-adapter/teams @chat-adapter/gchat

The README's usage example wires a Slack adapter and Redis state into a Chat instance, subscribes to the thread on first mention, and echoes later messages:

import { Chat } from "chat";
import { createSlackAdapter } from "@chat-adapter/slack";
import { createRedisState } from "@chat-adapter/state-redis";

const bot = new Chat({
  userName: "mybot",
  adapters: {
    slack: createSlackAdapter(),
  },
  state: createRedisState(),
});

bot.onNewMention(async (thread) => {
  await thread.subscribe();
  await thread.post("Hello! I'm listening to this thread.");
});

If you would rather not assemble the config by hand, the README points to a scaffolding CLI. It generates the Chat configuration, a webhook route, an .env.example file, dependencies, and an optional Web adapter route, drawing from the adapter catalog:

npx create-chat-sdk@latest my-bot

What you should see after scaffolding is a Next.js app with the webhook route and env file in place; the CLI docs at chat-sdk.dev/docs/create-chat-sdk cover options and non-interactive usage. The README does not list the environment variable names for each platform, so read the generated .env.example rather than guessing them. The monorepo's own build:validate script hints at the shape of Slack credentials (SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET) and a REDIS_URL, but that is the repository's test harness, not user documentation.

Where vercel/chat stops: adapters, state and concurrency

The SDK is only as broad as its adapters. The README says to browse official, vendor-official and community adapters on chat-sdk.dev/adapters, and to build your own if nothing fits. That three-tier classification is worth reading literally: community adapters are not maintained by the same people as the core, so the SDK's portability promise degrades to the weakest adapter on your list. If you need a platform with no adapter, vercel/chat gives you an adapter interface to implement, which is a real cost, not a configuration change.

The Redis state dependency is a second boundary. A single-process bot could keep thread subscriptions in memory, but the README's example uses createRedisState(), and the repository's build:validate script sets REDIS_URL. That implies an always-available store alongside your bot. For a small internal tool, running Redis is extra infrastructure you would not need with a platform-native bot framework.

Concurrency is the third. The README lists "overlapping messages" as a feature with burst, queue, debounce, drop, or process options, which tells you the default behaviour is not obvious enough to leave unstated. The documentation page at chat-sdk.dev/docs/concurrency is where that policy is defined; the README itself does not say which mode is the default. If your bot writes to a shared resource on every message, read that page before shipping.

vercel/chat compared with the Vercel AI SDK and platform-native bots

The related searches around this project include "vercel chat sdk vs ai sdk", and the distinction is architectural rather than competitive. The AI SDK is about model calls: prompts, streaming tokens, tool calls. vercel/chat is about transport: receiving a mention from Slack or Teams, deciding whether to subscribe to the thread, and posting a reply. The README's AI streaming feature sits at the seam, offering native Slack streaming, Telegram private chat draft previews, and a post-plus-edit fallback, so the two can be used together. Choosing one does not exclude the other, and neither replaces the other.

The more direct alternative is a platform-native framework: Slack's Bolt, or the Bot Framework SDK for Teams. Those give you the full platform API on day one, including features the unified layer may not expose yet, and they are maintained by the platform vendor. The trade is that each one is single-platform, so a second platform means a second codebase. vercel/chat is the right call when the multi-platform requirement is real and the platforms you need are covered; Bolt is the right call when you are Slack-only and want every Slack feature immediately.

Licence, maintenance and the cost of upgrading

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The README points to LICENSE at the repository root. That is a permissive licence with no copyleft obligation, but it also means no warranty; if the SDK breaks your bot, the licence does not give you recourse. This is a description of the licence text, not legal advice.

On maintenance: the last push to the default branch was on 2026-08-28, and the most recent release listed is chat@4.39.0 on the same date, with @chat-adapter/x@4.39.0 and @chat-adapter/whatsapp@4.39.0 published minutes apart. The version numbers move in lockstep across the core and adapters, which is a meaningful signal for upgrade planning: you cannot hold the core at one version and an adapter at another without checking compatibility. The repository uses Changesets (.changeset/ is a top-level directory), so release notes are generated per package.

Upgrade cost is concentrated in the adapter packages. A minor bump to chat may require matching bumps to every @chat-adapter package you use, and each adapter tracks a different platform's API. The repository also ships a skills/ directory and an AGENTS.md file, and the README documents installing the SDK skill for coding agents with npx skills add vercel/chat, which suggests the project expects agent-assisted development to be part of the workflow. That is a convenience, not a substitute for reading the adapter docs when a platform changes its API.

Editorial conclusion

Adopt vercel/chat if your bot logic is TypeScript and you need more than one messaging platform without writing per-platform handlers; the onNewMention and onSubscribedMessage model plus a Redis state adapter is the shortest path. Do not adopt it if your target platform has no adapter on chat-sdk.dev/adapters, or if you need Python. Before committing, verify that an official or community adapter exists for every platform on your list, and check whether your deployment target can host the webhook routes the CLI generates.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes