LangBot: a Python platform for shipping LLM bots to Discord, Slack, WeChat and more

The problem LangBot solves: one agent, many chat platforms

Writing a bot for Discord is a weekend. Writing the same bot for Discord, Slack, Telegram, WeChat and Lark is five separate codebases with five sets of credentials, five message formats, and five retry behaviours. LangBot's answer is to put the agent logic in one place and treat each chat network as an adapter underneath it.

The README frames this as a production-grade platform for building agentic IM bots, and the support table backs the claim with a long list: Discord, Telegram, Slack, LINE, QQ, WeCom, WeChat, Lark, DingTalk, KOOK, Satori, and Matrix. Matrix is the interesting entry, because the README notes it can bridge to Signal, WhatsApp, Messenger, iMessage, Mattermost, Google Chat, IRC, XMPP and Zulip. That means a single LangBot pipeline can reach networks the project never wrote an adapter for.

The audience is fairly clear from the feature list. This is not aimed at someone who wants a 200-line script answering messages in one Discord server. It is aimed at teams who already have a model endpoint or an agent platform such as Dify, Coze, n8n or Langflow, and who now need that agent reachable wherever their users already are.

How the pipeline, adapters and web panel fit together

The README describes a multi-pipeline architecture: different bots for different scenarios, each with monitoring and exception handling. Read together with the repository layout, the shape is a message bus. A platform adapter receives an inbound event, normalises it, and hands it to a pipeline. The pipeline decides which model or agent backend to call, runs the conversation turn, and returns a reply that the same adapter serialises back into the platform's format.

What sits inside a turn is where the project spends its complexity budget. The README lists multi-turn dialogue, tool calling, multi-modal support and streaming output, plus a built-in RAG knowledge base. Tool calling is backed by MCP support, and the pyproject.toml confirms it with mcp>=1.25.0,<2.0.0 as a direct dependency. Plugins are event-driven, and the repository ships a skills/ directory alongside src/ and web/.

The web management panel is the part that changes how you operate the thing. The README is explicit that configuration, management and monitoring happen in a browser interface, and that no YAML editing is required. The panel screenshot in the README shows message volume, model calls, success rate and active sessions. For a bot that runs unattended across several platforms, that operational surface matters more than the chat features.

Installing LangBot and getting a bot answering on one platform

The fastest path in the README is a one-line launch through uvx. It requires uv to be installed first, and the README says the panel should then be reachable at http://localhost:5300.

uvx langbot

If you would rather run it as a service, the README gives a Docker Compose path. Note the profile flag: the compose file is organised into profiles, and all brings up the full set of services rather than a subset.

git clone https://github.com/langbot-app/LangBot
cd LangBot/docker
docker compose --profile all up -d

The Dockerfile is worth reading before you build it yourself. It builds the web frontend in a node:22-alpine stage, then compiles nsjail 3.6 from source in a separate stage, and copies only the nsjail binary and its runtime libraries into the final python:3.12.7-slim image. The comment in the Dockerfile explains why: the sandbox backend is self-contained and does not need a host Docker socket. It also installs the Docker CLI client so an optional langbot_box service can drive a mounted host socket. That is a meaningful design decision, and it is the reason the image is not a thin one.

After the panel loads, the workflow the README implies is: add a model provider, add a platform adapter with its credentials, then wire them into a pipeline. There is a public demo at demo.langbot.dev with the credentials [email protected] and langbot123456, which is a reasonable way to look at the panel before installing anything. The README warns not to enter sensitive information there, which is correct advice for any shared environment.

The project also ships examples/http-bot/ and examples/web-page-bot/ in the repository, and the README links to longer written guides for deploying a multi-platform bot and for connecting DeepSeek to WeChat, Discord and Telegram.

Where LangBot gets awkward: Python version, dependency weight and sandbox assumptions

The first hard constraint is the interpreter. pyproject.toml sets requires-python to >=3.11,<4.0, while the README badge advertises Python 3.10 to 3.13. Those two statements do not agree. If you are pinning an environment, trust the packaging metadata, not the badge, and confirm which one the release you install actually enforces.

The dependency list is long and platform-specific. It pulls in discord-py with pynacl for voice, python-telegram-bot, slack-sdk, lark-oapi, dingtalk-stream, qq-botpy-rc, aiocqhttp, gewechat-client, nakuru-project-idk, plus a LangChain stack, SQLAlchemy with Alembic, and document parsers for PDF, DOCX, EPUB and HTML. Installing this on a constrained host is not a small operation, and every one of those packages is a supply-chain surface you inherit.

The sandbox story is the other place to look carefully. The Dockerfile deliberately builds nsjail so the Box runtime can isolate code without a host Docker socket, yet it also installs the Docker CLI for an optional service that does mount the socket. Those are two different isolation models in one image. If you plan to let the bot execute code, decide which one you are actually relying on, because the security properties are not the same.

Finally, the README does not document rollback, version pinning for the web panel, or what happens to stored conversations when you upgrade. Given three releases in the month before this writing (v4.10.8, v4.10.9, v4.10.10), that gap is worth closing on your own before you upgrade a live deployment.

LangBot compared with wiring a bot directly to one platform SDK

The obvious alternative is to skip the platform and use the vendor SDK directly: discord.py or discord-py for Discord, python-telegram-bot for Telegram, slack-sdk for Slack. LangBot depends on those same libraries, so the difference is not capability per platform. The difference is where the abstraction sits.

With a direct SDK you write the message loop, the conversation state, the model call and the retry logic yourself, and you get exactly the behaviour you wrote. Nothing sits between your code and the platform, which makes debugging a failing webhook straightforward. The cost appears the moment you want a second platform: you now maintain two message loops, two state stores and two deployment paths.

LangBot inverts that. You pay an upfront cost in dependencies and in learning the pipeline model, and in exchange the second, third and fourth platform are configuration rather than code. The same trade applies to the model side. If you already run Dify, Coze, n8n or Langflow, LangBot is positioned as the IM front end for it rather than a replacement, which is a sensible division: those tools are good at orchestration and poor at being a WeChat bot.

One more comparison point is worth naming. The related searches include AstrBot, another multi-platform chat bot project in the same space. If you are choosing between them, the deciding factor is likely which platform adapters and which model backends each one lists as supported, since the architecture idea is similar.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent: v4.10.8 on 2026-08-20, v4.10.9 on 2026-08-31, and v4.10.10 on 2026-09-04, with pyproject.toml already at 4.10.11. That cadence is good for fixes and bad for anyone who wants a quiet deployment, because it implies you will be deciding whether to upgrade roughly every couple of weeks.

The project ships real tooling for that decision. The Makefile defines test, test-quick, test-integration-fast, test-coverage and test-all-local targets, and the scripts directory holds test-quick.sh, test-integration-fast.sh and test-coverage.sh. There is also a lint target running ruff check and ruff format --check over src/langbot/ and tests/, and a pre-commit configuration at the repository root. If you fork LangBot, that is a working baseline to run before you ship a change.

On licensing: the repository is Apache-2.0 and pyproject.toml declares license-files = ["LICENSE"]. Apache-2.0 is permissive and includes an explicit patent grant, which is usually what a company wants when embedding a component in a product. There is also a CLA.md at the repository root, which governs contributions to the project rather than your use of it. That is a summary of what the files say, not legal advice; if you are redistributing a modified LangBot, read the LICENSE text and your own counsel's view of it.

Editorial conclusion

Adopt LangBot if you need one agent definition running on several IM platforms at once and you would rather configure it in a browser than in YAML; the docker compose --profile all up -d path gets you a working panel on port 5300 quickly. Do not adopt it if you need a single-platform bot with a minimal dependency footprint, or if your runtime cannot provide Python 3.11 or later. Before committing, verify three things yourself: that the platform adapter you need is listed as Official in the support table, that your target model provider appears in the LLM table, and that the pipeline and access-control settings in the web panel match how you intend to expose the bot to real users.

Frequently asked questions

Official sources

1. langbot-app/LangBot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases