switch: agents join the chat your team already uses

Guardrails and cost reporting are marked as coming next

The feature list has four bullets, and the fourth one is the one an evaluator should stop on. The first three are capabilities you can use: agents join the conversation in the apps the team already has, any agent that speaks the protocol can join regardless of provider or framework, and you design how humans and agents work together by setting the instructions a channel runs under, handing out roles and passing work as tracked tasks. The fourth says you can define who may talk to which agent and in what context, and then adds that guardrails and cost reporting are coming next, with a named commercial product among the ways to get them. That is a roadmap item sitting inside a security claim. So the access model described today is configuration and convention rather than enforcement, and anyone putting an agent with production access into a shared channel should know that before they read the rest of the page. The phrase about how the team operates being designed rather than improvised is the strongest idea in the document, and it is a design principle rather than a feature.

The adoption ladder has four levels, and level 2 is where the work is

The product is presented as a ladder, and the levels differ in kind rather than in quantity. At level 1 an everyday agent moves into your messaging app: you work on a feature with a colleague and your own coding agent in one channel, pull a colleague in to review with the whole trail already present, or stand up an agent that knows one slice of the system so any colleague can question it directly. Level 2 is where you encode how work runs. A bootstrap channel where anyone asks a manager agent to start something, and the agent opens the channel, brings in the right people and agents, attaches context and gets it moving. A feature request channel where an agent triages, asks the questions you would have asked, and files the result in Jira, Confluence or Notion. A bug channel where an agent reproduces what it can, collects logs and versions, and either files the ticket or tells the reporter what is missing. Level 3 has the whole chain, from triage through coding and review to deployment on a test environment, with an agent writing incident write-ups into team knowledge. Level 4 is a sentence about the company.

Three things it refuses to be, and why that matters

The section on what switch is not is doing more work than it appears to. It is not a messaging app: Slack, Teams, Discord, Telegram and Mattermost stay where they are, and switch brings agents and workflows into them. It is not an agent provider: no agents and no models ship with it, and you keep whatever coding agent you already run. And it is not a black box self-service platform, on the grounds that the code is there for everyone to read and contribute to and that the design assumes self-hosting with data staying in place. The positioning line above it is that most tools in this space want to become the place your team works, while switch connects the stack you have. For an evaluation that is the right question to ask of any tool in this category, and the answer here is favourable, because nothing you already run has to change except gaining a place to talk to it. The stated effort goes into the unsolved part, which is getting humans and agents to work as one team, rather than into rebuilding chat apps.

Secrets ship blank and one recipe fills seven of them

The self-hosting story starts with a deliberate hole. The environment example refuses to be copied by hand, because its secret fields are blank on purpose so that no known default credential can reach a running stack, and the old default was an admin login pair that the comment names directly. The replacement is a single recipe that generates the secrets for you:

init-env:
    #!/usr/bin/env bash
    set -euo pipefail
    if [ -e .env ]; then
      echo "✋ .env already exists — refusing to overwrite it." >&2
      echo "   Delete it first if you really want to regenerate every secret." >&2
      exit 1
    fi
    if ! command -v openssl >/dev/null 2>&1; then
      echo "openssl is required to generate secrets but was not found on PATH." >&2
      exit 1
    fi
    cp .env.example .env
    for key in DB_PASSWORD DB_OWNER_PASSWORD \
               AGENT_REGISTRATION_TOKEN JWT_SECRET_KEY GATEWAY_ADMIN_PASSWORD \
               MATTERMOST_ADMIN_PASSWORD MATTERMOST_USER_PASSWORD; do
      secret="$(openssl rand -hex 24)"
      sed -i.bak "s|^${key}=.*|${key}=${secret}|" .env
    done
    rm -f .env.bak
    echo "✅ Wrote .env with freshly generated secrets."
    echo "   Gateway admin login: $(grep '^GATEWAY_ADMIN_EMAIL=' .env | cut -d= -f2-) / $(grep '^GATEWAY_ADMIN_PASSWORD=' .env | cut -d= -f2-)"
    echo "   The stack binds to 127.0.0.1 only (set SWITCH_BIND_ADDR to expose it)."

Seven keys are filled, covering two database passwords, an agent registration token, a JWT signing secret and four Mattermost-related credentials, each generated as 24 random bytes rendered as hexadecimal. The recipe refuses to overwrite an existing environment file so it can never rotate live secrets by accident, and it fails early if the tool it needs for randomness is not on your path. It finishes by printing the gateway admin login, which is convenient for a first run and is exactly the string you do not want in a shell history file on a shared machine.

The example still says latest, which is the failure the comment describes

The image coordinates section contains the most valuable piece of configuration reasoning in the repository, and then contradicts itself one line later. The comment explains that the version variable is required and has no default in the compose file, because it used to fall back to the moving tag, so a missing or misspelt value silently floated the entire stack to whatever had most recently been published, with nothing to say so, and compose now refuses to start instead. The next lines are the actual defaults:

SWITCH_REGISTRY=ghcr.io
SWITCH_IMAGE_NAMESPACE=sandbox-quantum
SWITCH_VERSION=latest
# Host ports each service publishes. Defaults match the values baked in before
# these knobs existed; override any that clash with something already running on
# your machine (Switch Console's local-server mode picks free ports automatically).
GATEWAY_HOST_PORT=3000
API_HOST_PORT=8000
MATTERMOST_HOST_PORT=8065
POSTGRES_HOST_PORT=5432
# Host interface the published ports bind to. Defaults to loopback so the stack
# is reachable only from this machine; set to 0.0.0.0 to expose it on the
# network — do that only behind a reverse proxy / firewall.
SWITCH_BIND_ADDR=127.0.0.1

The third line is the moving tag the paragraph above explains is unsafe. So a user who follows the file's own advice to copy it gets the behaviour the comment warns about, and the safeguard only helps someone who reads the comment first. The registry and namespace values pin the images to a container registry under the sandbox organisation, which is a third name to keep track of alongside the repository and the product.

Ports bind to loopback, and one mode picks free ports for you

The same block documents how the stack exposes itself, and the default is the safe one. The host interface defaults to the loopback address so the stack is reachable only from the machine it runs on, and the comment says to change that only to expose it on a network, and to do it behind a reverse proxy or firewall. Four host ports are configurable: the gateway, an API, a Mattermost instance and a Postgres instance. The comment on those is an admission that the configuration grew after the fact, since the defaults match values that were baked in before the knobs existed. Two observations follow. A Mattermost port in the defaults means the standalone stack ships a chat server rather than connecting to an existing one, which is a heavier thing to run than the product description implies. And the console's local-server mode picks free ports automatically, which is a different port strategy for the same application, so a reader should work out which mode they are in before assuming a port number is stable.

Supply-chain and legal artefacts sit next to the source

The repository root is broader than a service repository usually is, and the extra files are the interesting part. There is a contributor licence agreement as a PDF alongside a Markdown version of the same thing, plus a NOTICE file, a security policy, a release process and a licence. There is also a signature directory, a supply-chain manifest for a scanning service, an artefacts manifest, a secret-scanning configuration and a pre-commit configuration. Two more reveal what the project actually contains: a Python lint configuration next to a TypeScript-primary codebase, and a renoovate configuration in JavaScript rather than JSON. Directories cover connectors, the console, core, deployment, the gateway, internal code, templates for agents and rooms, and a component called the switch expert. So this is a polyglot monorepo with a plugin manifest, a set of connector implementations and an expert component, which is consistent with a product that has to attach to five different chat platforms and to an agent ecosystem rather than to one runtime.

Three canary builds in an afternoon, with 0.3.0 cited as the stable example

The release list is the last thing to read, and it shapes how you should pin. The three most recent releases are canary builds of the same version, published within about ninety minutes of each other on a single afternoon, which tells you the canary line moves continuously. Meanwhile the environment example cites a released tag in the low zero-point-three range as the version to use for a reproducible stack. Those two facts together are the pinning guidance the project does not state in one sentence: canaries are for testing your deployment against the newest code, and the earlier tag is what a reproducible stack should name. There is also a documented convention for recordings in the readme that is worth copying if you maintain a similar repository. Videos are not committed, because a committed video costs every future clone, and instead a recording is attached to a pull request comment so it is served from a content delivery network. The readme even records that a video tag does not survive its own sanitiser.

Editorial conclusion

switch is worth reading if your team already runs coding agents locally and the problem is that nobody else on the team can see or use them, because the whole design is about bringing a laptop agent into a shared channel rather than about a new chat client. Two things to weigh before you build on it. Guardrails and cost reporting are described as coming next, so the access-control story you want is not in the box yet, and the product's own documentation names a commercial route as one way to get them. And self-hosting means running the whole stack, including a chat server, a database and a gateway, with secrets you generate yourself, so read the environment example and the recipe that fills it before you assume a quick start.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sandbox-quantum/switch on GitHub