Switch: routing AI agents into Slack, Teams and Discord channels
Connect any AI agent to your team in Slack, Teams & Discord. Open-source and self-hostable.
At a glance
- What is it?
- Switch is a self-hostable TypeScript framework that connects agents built with Claude Code, Codex, LangChain or MCP to the messaging apps a team already uses. The README describes a design for channel-scoped instructions and tracked tasks, but leaves the deployment and permission details thin.
- Who is it for?
- Adopt Switch if your team already lives in Slack or Teams and you want several agents from different frameworks reachable in the same channels without building your own chat adapter layer. Do not adopt it if you need a permissive licence for a commercial product, or if you need published numbers on guardrail behaviour, because the README states those are still to come.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Switch is trying to fill between chat apps and agent runtimes
Most agent tooling assumes one user talking to one agent in one terminal. Teams do not work that way. A bug report arrives in a channel, a colleague asks a follow-up question, someone else wants to see the logs, and the agent that could answer is running on a laptop three desks away. Switch's stated purpose is to remove the adapter work that sits between those two worlds. The README frames it as infrastructure rather than a product: "the underlying infrastructure and framework that allows you to build teams where humans and agents work side by side." The intended user is an engineering team that has already built or adopted agents and now wants them reachable in conversation, not a team looking for a ready-made agent. Switch does not appear to ship an agent of its own. Its job is routing, channel context and task handoff.
How agents and platforms meet in the middle
The repository describes a hub model. Agents connect from wherever they run, and messaging platforms connect on the other side, with Switch in between. The README lists Slack, Microsoft Teams, Discord, Telegram and Mattermost as supported surfaces, and says an agent can join "if it speaks the protocol." MCP appears in the repository topics alongside LangChain and OpenAI, which points to the Model Context Protocol as the integration path, though the README does not spell out the handshake. The structural idea that does come through is that a channel carries instructions. The README describes setting "the instructions a channel runs under," handing out roles, and passing work as "tracked tasks" rather than free-form messages. That is a meaningful design choice: the unit of work is a task with an owner, not a chat message, which is what would let a triage agent hand off to a coding agent and then to a deployment agent without a human re-typing context. The README's level 3 and level 4 descriptions sketch exactly that chain, but they are illustrative scenarios, not documented behaviour.
What the README does not tell you about getting it running
This is the weakest part of the supplied material. The README points to docs.flintai.dev/flintai/switch/getting-started for setup, and the repository carries a CI workflow at .github/workflows/pr-ci.yml and a CONTRIBUTING.md, but no install command, environment variable, or configuration key appears in the README itself. There is no docker-compose file mentioned, no example .env, and no sample channel configuration. The releases are tagged switch-console-v0.34.0, switch-console-v0.33.0 and switch-console-v0.32.0, all dated September 2026, which suggests the console is the component under active versioning, but the README does not explain what the console is or whether it is required for a headless deployment. Anyone evaluating Switch has to go to the external documentation to answer basic questions: where does it run, what does it store, how are platform credentials supplied. I cannot fill those gaps from the material here, and neither should a reader assume defaults.
The licence is not plain Apache 2.0
The repository's licence field reports NOASSERTION, while the README badge reads "Apache 2.0 + Commons Clause." Those two signals do not contradict each other, but they do mean the licence is not a standard OSI-approved one. The Commons Clause is typically used to prohibit selling the software itself while leaving other use untouched, and it is the reason the licence field cannot resolve to a recognised identifier. For an internal deployment this distinction may never matter. For anyone embedding Switch in a product they sell, it matters a great deal, and the only reliable source is the LICENSE file in the repository. I am not giving legal advice here; the point is that a team that assumes "Apache 2.0" from the badge and moves on has skipped the part of the file that changes the answer.
Guardrails and cost reporting are announced, not shipped
The README is direct about this in a way that deserves credit: "Guardrails and cost reporting are coming next, Flint AI among the ways to get them." Read that alongside the earlier claim that you can "define who can talk to which agent and in what context," and there is a tension. Access control is described as available; guardrails and spend visibility are described as future work. For a self-hosted deployment where agents can read channel history and act on it, the absence of shipped guardrails is the limitation that should shape a pilot. The README also leans on level-based framing, from level 1 through level 4, with level 4 described as "your company runs on Switch." That is a roadmap presented as a ladder. Levels 1 and 2 read as things the current feature set plausibly supports. Level 4 is aspiration, and it is labelled as such in the structure of the document rather than in a disclaimer.
Where a narrower tool is the better answer
If your only requirement is a Slack bot that calls one model and replies in a thread, Switch is more machinery than the problem needs. A small Slack Bolt app with a single API call does that with fewer moving parts and no extra service to operate. The clearer comparison is with agent frameworks that already ship their own chat integrations, such as LangChain's own connectors or the Slack and Teams surfaces that some hosted agent platforms provide. The difference in approach is scope. Those integrations bind one framework's agents to one platform. Switch's claim is the inverse: any agent, any of five platforms, with the routing layer as the shared piece. That is worth the extra component only when you actually have agents from more than one runtime, or more than one chat platform, and want them to share channel context and task handoff. If you have one agent and one platform, the abstraction is cost without return.
Maintenance surface and what versioning tells you
Three releases in the four days between 2026-09-03 and 2026-09-06, all under the switch-console tag, and a last push on 2026-09-10. That cadence suggests active work on the console component specifically. It also suggests the project is young and moving, which has a practical consequence: configuration and interface details are more likely to shift between minor versions than they would in a settled tool. The repository is not archived, which is the minimum bar. Beyond that, the material does not include a changelog, a deprecation policy, or a statement about which versions receive fixes. A team planning to run Switch in production should treat the release notes for switch-console-v0.34.0 and its predecessors as the source of truth for what changed, and should expect to read them before each upgrade rather than after.
Who should pick this up, and what to check first
Switch fits a team that already runs agents in more than one place and wants them in the chat app the team uses daily, with the routing layer self-hosted so channel content does not leave the company's infrastructure. It does not fit a solo developer with one agent, a team that needs a permissive licence for a commercial product, or anyone who needs documented guardrails before letting an agent act in a shared channel. The verification order is short. Read the LICENSE file to settle the Commons Clause question. Read the getting-started documentation at docs.flintai.dev/flintai/switch/getting-started to find the actual configuration keys, since the README provides none. Confirm that the agents you intend to connect speak MCP, because that is the integration path the repository topics point to. If all three check out, the level 1 and level 2 patterns in the README are the realistic starting point, and the level 3 and level 4 chains should be treated as designs to grow into rather than features to switch on.
Editorial conclusion
Adopt Switch if your team already lives in Slack or Teams and you want several agents from different frameworks reachable in the same channels without building your own chat adapter layer. Do not adopt it if you need a permissive licence for a commercial product, or if you need published numbers on guardrail behaviour, because the README states those are still to come. Before committing, verify three things: the actual licence text in the LICENSE file rather than the badge, the current configuration keys in the docs at docs.flintai.dev/flintai/switch/getting-started, and whether the agent you intend to connect already speaks MCP.
Community notes