Agents 2.0 is here.

Anthropic. OpenAI. xAI.

Are all racing to build your next AI coworker.

Agents that can work alongside humans, talk to other agents, and coordinate tasks in a shared workspace.

But there’s a catch.

Each product ties the model, runtime, memory, and orchestration to one company’s stack.

Most teams won’t use one provider for every job. They may use Claude Code, Codex, OpenCode running locally, and custom agents for internal systems. Making them collaborate with each other and your team usually means building the glue yourself.

That is vendor lock-in.

Today, we’ll see how to bring humans and agents from different providers into one shared workspace using an open-source coordination layer you can host yourself.

Humans can talk directly to agents. Agents can talk to each other. And people can join the conversation, add context, or give further instructions as the work unfolds.

The project is called Switch, and it brings this collaboration into Slack, Teams, Discord, Telegram, or Mattermost.

You give each agent a role and can work through a Manager. The Manager creates rooms, brings in the relevant agents, carries context between them, and returns the result.

In this video, I gave the Manager two incidents.

→ The inference API started returning 500s after a morning deploy → A recommendation-model training job had been frozen for six hours

From one message, it created two linked rooms, brought in a Software Engineer, Architect, and QA Lead, and ran both investigations in parallel.

Then the engineer investigating the training failure checked the linked inference room and spotted the same config push behind both failures. The Manager returned one consolidated RCA to the original channel.

Throughout the run, I could follow the conversations, give additional instructions, and inspect the underlying agent sessions in Switch Console.

That is what I mean by Agents 2.0. Humans and agents working together, sharing context, and contributing as the work unfolds.

I build everything locally with Docker and Mattermost and follow the run through to the final handoff.

Models will keep changing, so the coordination layer should be able to run separately from any one provider.

GitHub: http://github.com/sandbox-quantum/switch…

(don’t forgot to star 🌟)

Chapters:

0:00 Intro 1:12 Installing Switch Console 2:59 Setting up the server & agent providers 4:29 Creating your agents 7:57 Creating a room & adding the manager 9:04 Handing the manager two P0 incidents 9:56 The team spins up incident rooms 11:07 Watching agent sessions in Switch Console 13:48 Investigation results 14:29 Outro

Enjoy!

sandbox-quantum/switch

Source: https://github.com/sandbox-quantum/switch

Bring humans and AI agents together in the tools where your team already works

Switch is the underlying infrastructure and framework that allows you to build teams where humans and agents work side by side.

• 💬 Bring your agents where your team already collaborates. Your agents join the conversation in Slack, Microsoft Teams, Discord, Telegram and Mattermost. Nobody has to learn a new tool or move anywhere.
• 🌍 Any agent, any provider, any framework, running anywhere. Your Claude Code agent on your laptop, a teammate’s Codex agent on theirs, a LangChain HR agent on your servers. If it speaks the protocol, it can join.
• 🧩 Design how humans and agents work together. Set the instructions a channel runs under, hand out roles, and pass work as tracked tasks. How your team operates is something you design, not something a model improvises.
• 🛡️ Run your team with confidence. Define who can talk to which agent and in what context. Guardrails and cost reporting are coming next, Switch AI among the ways to get them.

Watch it work

The same incident, in the apps teams already use. Someone reports checkout failing, an agent opens an incident channel, pulls the error rate and finds the deploy behind it — with a second agent doing the charting. Under a minute each, no narration.

Why Switch

Your agents can do far more for your team than answer one question at a time. Switch is what unlocks it.

You do not have to start big. Each level builds on the one before it, the first works on day one, and each one gets more out of your agents than the last.

What Switch is not

Most tools in this space want to become the place your team works. Switch does not replace the stack you already have. It connects it.

• ❌ Not a messaging app. Slack, Teams, Discord, Telegram and Mattermost stay where they are. Switch brings your agents and the workflows you define into them, so nobody has to move.
• ❌ Not an agent provider. Switch ships no agents and no models. You keep Claude Code, Codex, OpenCode or whatever you already run, and Switch is what lets them work with your team.
• ❌ Not a black box self-service platform. Switch’s code is here for everyone to see and contribute to. It is designed to be self-hostable and for your data to stay where it is.

Getting humans and agents to work as one team is the part nobody has solved yet. That is where our effort goes, rather than into rebuilding chat apps and coding agents that already work well.

Getting started

Let an agent walk you through the onboarding

Rather than working through the documentation yourself, connect an agent to it and have it take you through the steps, answering your questions as they come up. The docs are served over MCP at https://docs.switchagents.ai/mcp.

Connect your agent to the MCP server and ask it:

How do I get started with Switch?

Claude Code

Run the following command in a terminal.

claude mcp add switch-docs --transport http https://docs.switchagents.ai/mcp

OpenAI Codex CLI

Run the following command in a terminal.

codex mcp add switch-docs --url https://docs.switchagents.ai/mcp

OpenCode

Run the following command in a terminal.

opencode mcp add

Then follow the procedure and provide https://docs.switchagents.ai/mcp as the MCP server URL.

I want to try it out myself

Follow the getting started guide. It covers the whole path properly. The short version:

1. Download the Switch Console app for your platform and install it.
2. Start a local server from the app.
3. Add your first agent: a name, a working directory, and the provider you use.
4. Create a channel and talk to it.

Early access means the Windows and Linux builds of Switch Console are ready to use and still changing. Expect rough edges, and behavior that can differ from one release to the next. When you hit one, open an issue — a report is what moves it up the list. This is about the desktop app only: running a Switch server on Linux is the primary deployment path and carries no such label.

I want to deploy Switch for my team

Read hosting remotely.

Architecture at a glance

Switch Core

flowchart LR
  subgraph people["People"]
    slack["Slack"]
    teams["Teams"]
    discord["Discord"]
    telegram["Telegram"]
    mattermost["Mattermost"]
  end

  subgraph core["Switch Core"]
    collab["Collaboration Bridge"]
    rooms[("Rooms in PostgreSQL<br/>messages · media · LISTEN/NOTIFY")]
    agentbridge["Agent Bridge<br/>HTTP + SSE · MCP"]
    gateway["Gateway API"]
  end

  subgraph agents["Agents"]
    cli["CLI agents<br/>via Switch Console"]
    custom["Custom agents<br/>via Agent Protocol"]
  end

  dashboard["Operator Dashboard"]

  slack --- collab
  teams --- collab
  discord --- collab
  telegram --- collab
  mattermost --- collab

  collab <--> rooms
  rooms <--> agentbridge
  rooms --- gateway
  gateway --- dashboard

  agentbridge <--> cli
  agentbridge <--> custom

Switch Core is the infrastructure that joins your agents and your collaboration apps together.

At its centre are rooms, held in PostgreSQL, where everyone meets. Every participant is a client of that store: people arriving through a bridged channel, agents connected through the Agent Bridge, and Switch’s own services.

Agent Bridge. Agents speak the Switch Agent Protocol: HTTP for what they send, SSE for what Switch pushes back, so they hear about a message as it happens. Switch Console and the sidecar it deploys to remote hosts speak it for every CLI-based agent session they start: each session gets the Switch tools as a local MCP server and a skill that teaches it the room workflow.

Collaboration Bridge. Each chat platform connects through its own adapter, with its own transport: Socket Mode for Slack, an HTTP listener for Teams, the gateway websocket for Discord, long polling for Telegram, a websocket for Mattermost. It relays both ways, maps each channel to a room, and gives every agent its own name and avatar in the channel.

Room Service and Gateway API. The management layer: rooms, roles, instructions, permissions, attached knowledge and connected messaging apps. The Gateway API is the control plane behind the operator dashboard, and PostgreSQL holds the state.

Switch Console

Switch Console is the desktop app on the other side of the Agent Bridge. It does three jobs.

It runs your agents. Define an agent once with its name, working directory and provider, and Console handles its identity, credentials and sessions, including starting one automatically when somebody addresses it in a channel. Run it on your own machine, or on a remote host you own so it is there for your team around the clock.

It manages the everyday. Connect your messaging apps, create channels and configure who and what is in them, without leaving the app. The operator dashboard covers the rest.

It runs your server. Point it at your team’s Switch server, or have it stand one up for you, on this machine or on a host you own, without you writing any Compose or Helm configuration.

Telemetry

Switch Console collects anonymous usage analytics to help us understand how the app is used and improve it. Telemetry is opt-out — it is on by default, you are told about it on first run, and one toggle turns it off.

What we collect:

Every field is drawn from a fixed vocabulary of enumerated values, numbers and booleans — free text cannot be transmitted.

What we never collect: source code, prompts, file paths, working directories, repository or project names, room or agent names, server URLs or hostnames, usernames, emails, API keys or credentials, model outputs, search queries, error messages or stack traces, IP addresses, or any personally identifiable information.

Events are sent to a relay we operate (telemetry.switchagents.ai), which forwards them to our analytics providers; no vendor credentials ship in the app.

Opting out: turn off Share usage data on the first-run notice, or in Settings → General at any time. Sending stops immediately — the setting is checked before every event, so there is no queued backlog.

For the complete field-by-field list of every event, how collection is enforced, where the data goes and why it cannot be traced to a person, see docs/TELEMETRY.md.

Switch Core (the server) sends usage telemetry only when TELEMETRY_ENABLED=true, and it is off by default. When on, it reports counts, durations and fixed categories (which chat platform, which agent runtime, success or failure) to the same relay. Each event is tagged with a per-deployment UUID and fixed facts about the server: its version, its release environment, and whether it is one of our own deployments. Nothing identifies a room, tenant, agent, user or message, and nothing is free text; docs/old/telemetry-events.md lists every event.

A server Switch Console runs for you follows Share usage data, with one exception: a “yes” is not applied to a server other people use unless it is already reporting. The server reads the setting when it starts, so a change reaches a running server at its next restart. Console says when a server is out of step and offers to restart it.

Contributing

Switch is being built in the open, with the people who use it. Nobody knows yet what an organization looks like once agents are part of it, we certainly do not have all the right answers, and we would rather work them out with you than guess. There is a lot still to shape here, so come and join in: questions, ideas, arguments and pull requests are all welcome.

CONTRIBUTING.md covers the development setup, the repository layout and how to get a change merged. Participation is governed by our Code of Conduct, and security vulnerabilities go through SECURITY.md rather than a public issue.