Techzine first reported the launch, while SandboxAQ’s announcement says Switch is available now and can connect agents made with Claude Code, Google ADK, LangChain, OpenAI tooling, and other frameworks. The public GitHub repository confirms that Teams is a supported target and that Switch maps collaboration channels into rooms where agents can receive messages and respond in real time.
But there is a material qualification missing from the launch language. SandboxAQ calls Switch “open source,” yet its published license adds the Commons Clause to Apache 2.0 and explicitly prohibits selling the software or derivatives of it. Under the Open Source Initiative’s definition, a license cannot restrict use in a particular field of endeavor. Switch’s code is publicly inspectable and modifiable, but for procurement, redistribution, managed-service, and platform teams, it is more accurately described as source-available software with a commercial-use restriction, not conventional open-source infrastructure.
A Teams channel becomes a room in another system
Switch does not turn Microsoft Teams itself into an agent runtime. Its repository describes a Matrix homeserver, using Tuwunel, as the system of record for the rooms in which humans, agents, and Switch services meet. Teams is connected through a collaboration bridge that uses an HTTP listener, maps a Teams channel into a room, and relays messages in both directions.
That architecture explains how Switch can present a common model across Teams, Slack, Discord, Telegram, and Mattermost. It also means the familiar Teams channel is only the front end. Conversations, agent roles, instructions, permissions, connected applications, and attached knowledge are managed through Switch’s own Room Service and Gateway API, with PostgreSQL holding state.
For a developer group, that can remove the repeated exercise of copying a Teams thread into an agent prompt, then pasting the agent result back into the thread. A coding agent can be assigned to a project room, receive the message history and configured instructions, and continue working as colleagues add information. The same design could support incident response: an agent can be introduced after an alert without needing a manually assembled briefing document.
The payoff is persistence, but persistence changes the security model. A Teams message that previously stayed within Microsoft 365 can be copied into Switch’s infrastructure and exposed to whichever agents and connectors have been admitted to the corresponding room. The product’s usefulness depends on that transfer of context. So does its data-handling risk.
The agent bridge is the real integration point
SandboxAQ positions Switch as model- and framework-neutral. The repository shows that this is implemented through a Switch Agent Protocol: agents send through HTTP and receive events through Server-Sent Events. Provider-specific connectors are generally composed of a local Model Context Protocol server and an agent “skill” that teaches a particular coding or task agent how to participate.
This is a reasonable separation of concerns. Slack and Teams remain collaboration surfaces; Switch handles rooms and routing; agents keep their own providers, working directories, credentials, and runtime environments. A company can theoretically place a local Claude Code agent on an engineer’s workstation, a Codex-based agent elsewhere, and a server-hosted LangChain agent in the same room.
It is also a long chain of trust. A Teams administrator approving the app integration is not merely installing a bot that summarizes messages. They are enabling a relay to a new service that can activate agents and pass them work context. Those agents may then have access to repositories, shells, cloud APIs, ticketing systems, deployment tooling, or knowledge bases, depending on how the organization configures their credentials.
Switch Console, SandboxAQ’s desktop app, is central to that setup. According to the project documentation, the Console defines each agent’s name, provider, working directory, identity, credentials, and sessions; it can start an agent when someone addresses it in a channel. It can run locally or on a remote host owned by the customer, and can also stand up a Switch server.
That is a powerful convenience feature, particularly for developer workstations. It is also the point at which a chat mention can become an instruction to an agent with local files, tokens, and command execution available. Teams and Slack admins will need to treat the Console host and agent configuration as privileged infrastructure, rather than as an ordinary collaboration plug-in.
Guardrails and cost reporting are not shipping features
SandboxAQ says Switch lets operators define who can talk to which agent and in what context. Its documentation also lists roles, instructions, permissions, and connected collaboration applications in the management layer. Those controls are essential, but the project’s own README says that guardrails and cost reporting are “coming next.”
That wording is significant for enterprises considering an early deployment. A Teams channel can be a noisy place: participants forward logs, attach artifacts, quote external text, tag bots, and debate competing remediation steps. Any agent in that environment needs strong boundaries around who may invoke it, what context it may read, which tools it may use, whether it may take external action, and where it can send output.
The launch materials emphasize that a room retains history, rules, and context. Retention is useful for continuity, but it also creates a problem familiar to Teams administrators: access controls change over time. Someone can be added to a channel after sensitive messages were posted; an agent can be moved from one team’s work to another; a connected system can be reauthorized with broader scopes. The practical question is whether the room’s stored context is re-evaluated against current permissions each time it is delivered to an agent. SandboxAQ’s public materials describe room permissions at a high level, but do not spell out that behavior.
Nor do the materials establish how teams can audit agent actions across the full chain: Teams message, Matrix room event, Switch policy decision, agent prompt, tool call, output, and any resulting GitHub, cloud, or ticketing-system change. Organizations should not assume a channel transcript is a sufficient audit record when the channel is instructing an agent to act.
“Open source” is not the license outcome here
The source code is public, and SandboxAQ says users can run Switch inside their own enterprise or issue free products using it. The company’s repository is active, contains hundreds of commits, and accepts contributions. Those are meaningful benefits compared with a closed hosted agent-orchestration service.
Yet the license deserves more scrutiny than the announcement gives it. The Commons Clause says users may not sell Switch or any derivative of Switch, defining “sell” broadly enough to include providing a product or service whose value derives substantially from the software’s functionality, including hosting and consulting or support services. It also says the restriction applies to derivatives.
For an internal enterprise deployment, that may be acceptable. A company can inspect the code, modify it, self-host it, and use it to run internal workflows. But the restriction can matter immediately for managed service providers, systems integrators, consultants packaging a supported distribution, and SaaS vendors building a commercial offering on modified Switch code. Those parties need legal review before assuming Apache 2.0-style freedom to distribute or monetize the result.
The distinction also matters operationally. Many enterprises have well-developed processes for consuming OSI-approved open-source components, including license scanning, notice management, patching, and approved support vendors. A source-available license with a commercial restriction often goes through a different review path. Calling it “open source” may cause project sponsors to underestimate that friction.
Windows and Linux remain early-access console targets
The public project page offers a Windows x64 executable for Switch Console, but labels Windows and Linux builds as early access. SandboxAQ says those builds are ready to use but still changing, and warns that behavior can differ between releases. It identifies Linux server deployment as the primary path and does not apply the same early-access label to running a Switch server on Linux.
For Windows-heavy organizations, that produces a sensible split: keep the durable server-side components on a controlled Linux host, then use the Windows Console only for development or limited administration while the desktop application matures. Treating a Windows workstation as a permanently available agent host may be viable for a small engineering group, but it complicates patching, credential protection, endpoint security, and availability.
Switch is arriving just after GitHub expanded Copilot cloud-agent collaboration into Slack and Microsoft Teams. GitHub’s approach is narrower and tied to its own cloud agent, paid Copilot plans, and repository permissions; Switch attempts to be the neutral layer that connects many agents and providers. That neutrality is its most compelling feature, but it also leaves each customer responsible for assembling a coherent policy across providers, agent frameworks, local runtimes, and collaboration platforms.
SandboxAQ has supplied the plumbing for a shared human-agent room. Before connecting it to production Teams channels, IT should decide which rooms may contain sensitive data, require service-hosted agents instead of workstation agents, restrict who can mention or steer each agent, and record every action beyond a chat reply. The product is available today; its guardrails and governance story, by SandboxAQ’s own account, is still catching up.