LangBot worked on the first try. Here's why

Most of our agent tests are stories about something breaking. This one isn't.

LangBot is an open-source platform for building AI bots for chat apps, with around 18,000 stars on GitHub. One setup covers Discord, Telegram, Slack, LINE, QQ, WeChat, WeCom, Lark, DingTalk and KOOK. It has a web panel, a plugin system, a knowledge base and MCP support.

We connected it to Swytchcode, which runs a bot's API calls with your keys, holds every write for your approval, and keeps rules the bot can't change. Then we ran our seven checks against a mocked Stripe. All seven passed, with no changes on either side, and there was nothing to lock down.

That almost never happens. So it's worth asking why.

Why nothing broke

1. The agent has no shell. On almost every agent we've tested, the risk isn't Swytchcode's tools. It's the agent's own shell or file tools, which can edit the rules file directly. LangBot's agent doesn't have those unless you turn on Box, its optional sandbox. Without Box, the bot's tools were Swytchcode's 11 and LangBot's skill tools, and nothing else. There was simply no way to reach the rules.

2. The agent lives apart from your files. Since version 4.11, LangBot's agent is a plugin called Local Agent. It runs in a separate plugin runtime container. Swytchcode runs on the host, and LangBot reaches it over HTTP with a token. Neither container has the rules file or your keys.

3. It passes tool calls through cleanly. LangBot hands a tool's arguments over as one object. Some platforms spread them into their own function calls, where a name like tool can clash with their own code. LangBot doesn't. When Swytchcode returned an error, LangBot passed the full message on to the agent, so it could tell the user what went wrong.

The result is the setup we'd recommend to anyone: the bot can ask for things, and only Swytchcode can do them. The rules sit outside the bot's reach, so there's nothing to argue it out of.

In our test, reads ran straight away, writes waited for a person to approve, pasted API keys were refused, and the bot couldn't loosen or replace a rule. The skill, which teaches the bot how to use Swytchcode, loaded when the bot needed it.

Two things to know

Every pipeline gets Swytchcode. LangBot pipelines use every MCP server you add, unless you've limited them. That's handy, but it means a public bot and a private one share the same Swytchcode tools. If they shouldn't, limit the pipeline's extensions, or run a separate Swytchcode project for each.

Box changes the picture. Box gives the bot commands, in sandbox containers. We didn't test it. If you turn it on, check that those containers can't reach the Swytchcode folders before you connect a real account.

Set it up

The short version, with LangBot in Docker and Swytchcode on the host. You need a Swytchcode account, and approvals need the Business or Enterprise plan.

npm install -g swytchcode
swy init --operator --editor=none --project ~/agent-swy
swy login
swy mcp serve --profile operator --project ~/agent-swy --transport http -d
swy mcp token

In LangBot's web panel, open MCP, add a Remote server at http://host.docker.internal:5476/mcp, and add an Authorization header of Bearer <token>. Then zip up ~/agent-swy/agent-skill/swytchcode-operator and upload it under Skills.

The LangBot setup guide has the Linux steps and connecting your first app.

We tested LangBot 4.11.1 with the Local Agent plugin, a scripted model and a mocked Stripe, using its debug chat. We haven't tested Box, a native install, a real model, or a real approval on a phone.

Boring is the goal

There's no dramatic story here, and that's the point. When the agent can only ask, and something else decides, there's nothing to break into. LangBot got there by keeping its agent small and its sandbox optional.

If you're picking a bot platform for anything that touches money or customer data, that's the shape to look for.