SandboxAQ Switch: A Practical Guide to Human–Agent Workspaces

Direct answer

SandboxAQ Switch is an open-source, self-hostable coordination layer for putting AI agents and people into the same workspaces in Slack, Microsoft Teams, Discord, Telegram, and Mattermost. It does not replace those chat products, and it does not provide a model. Instead, Switch maps collaboration channels to shared rooms, connects agents through its Agent Protocol and provider connectors, and keeps the work context with the room as humans and agents join, leave, and hand off tasks.

For developers, the useful distinction is between coordination and execution. Switch can route a request to a Claude Code, Codex, LangChain, OpenAI, Google ADK, or other compatible agent, but the agent still owns its tools, credentials, sandbox, and side effects. A safe pilot should therefore begin with a read-only incident, support, or documentation workflow before adding write-capable agents.

What Switch changes in an agent stack

Most agent deployments begin with a person opening a separate coding-agent terminal, web dashboard, or API workflow. The result is often technically capable but socially isolated: teammates cannot see the agent’s context, ask it a follow-up question, or review what it did without copying messages between systems.

Switch takes a different approach. A channel becomes a room that can contain people, one or more agents, instructions, roles, attached knowledge, and tracked work. The collaboration platform remains the interface people already know. Switch supplies the bridge and the control plane.

The project’s official repository describes four practical levels of adoption:

• Move an everyday agent into a team messaging app.
• Encode repeatable workflows such as feature intake, bug triage, and incident response.
• Connect triage, coding, review, deployment, and knowledge agents around the same work.
• Extend the model across departments and teams.

That progression is more important than the launch headline. The first value is not “autonomous company.” It is eliminating repeated context transfer while keeping a human-readable trail of what happened.

Architecture at a glance

The following is an original editorial model based on Switch’s public README and repository structure. It separates the collaboration bridge from the agent runtime and from the application tools that can create side effects.

Visual 1 — Original Switch architecture diagram. The chat adapters and rooms preserve collaboration context, while each connected agent remains an independently operated runtime. The official Switch repository is the source for the architecture concepts and connector model.

The README identifies a Matrix homeserver (Tuwunel) at the center of Switch Core. People arriving through a bridge, agents connected through the Agent Bridge, and Switch services participate as Matrix clients. Collaboration adapters then map Slack, Teams, Discord, Telegram, or Mattermost channels into rooms. The Gateway API manages rooms, roles, instructions, permissions, attached knowledge, and connected messaging apps, with PostgreSQL holding state.

That split creates a useful security boundary: a message in Slack is not automatically a database write. The connected agent receives a request through the bridge and must use its own configured tools and permissions to act.

Switch compared with a conventional agent deployment

Visual 2 — Coordination comparison. This table is an editorial synthesis of the public repository and launch coverage. Switch reduces collaboration friction; it does not remove the need to secure each agent and external integration.

What developers can connect

SandboxAQ’s announcement says Switch is model- and platform-agnostic. The repository documents connectors for agents built with Claude Code, Codex, and other frameworks, while the launch material names Google ADK, LangChain, and OpenAI tooling as examples. The important implementation requirement is not a particular model. It is that the agent can communicate through the Switch Agent Protocol or an available connector.

The project also exposes a documentation MCP endpoint at https://docs.flintai.dev/mcp. The README gives these examples for asking a compatible coding agent to guide onboarding:

1## Claude Code
2claude mcp add switch-docs --transport http https://docs.flintai.dev/mcp
3
4## OpenAI Codex CLI
5codex mcp add switch-docs --url https://docs.flintai.dev/mcp

For OpenCode, the documented flow is to add an MCP server and provide the same URL through its setup prompt. Treat these commands as onboarding examples, not proof that every CLI version has identical syntax. Check the project documentation and your installed client’s help output before automating setup.

After documentation access is configured, the repository’s short local path is:

1. Download and install Switch Console for the target platform.
2. Start a local Switch server from the console.
3. Add an agent with a name, working directory, and provider.
4. Create a channel or room.
5. Connect the collaboration app.
6. Address the agent in the room and observe the complete request trail.

The official README includes downloads for macOS, Linux, and Windows. It labels Linux and Windows console builds as early access, while the Linux server deployment is described separately as the primary remote path.

A safer pilot: incident triage before autonomous remediation

A good first workflow is an incident room with a read-only observability agent and a human incident lead. The agent can summarize alerts, inspect approved logs, correlate a deployment, and draft a rollback plan. It should not receive deployment credentials in the first pilot.

Visual 3 — Original request flow for a read-only pilot. The human review step remains outside the model’s reasoning loop and before any consequential action. The diagram is an editorial recommendation, not a claim that Switch itself enforces this exact workflow.

A production version should add explicit controls around the agent:

• Use a dedicated identity and least-privilege credentials for each agent.
• Give the triage agent read-only access to an allowlisted set of systems.
• Keep secrets out of room history, prompts, logs, and screenshots.
• Require approval for deployments, refunds, external messages, permission changes, and destructive operations.
• Log the original message, room, agent identity, tool call, authorization decision, and result.
• Set timeouts and response-size limits on every bridge and tool integration.
• Define what happens when a bridge disconnects or a message is delivered twice.
• Test whether replies can accidentally expose private room context to a broader channel.

Switch’s room instructions are useful policy context, but they should not be treated as a complete security boundary. Server-side authorization in each connected tool must independently enforce tenant, user, resource, and operation permissions.

The open-source claim needs a license check

The launch announcement calls Switch open source and the source is publicly available on GitHub. However, developers should read the repository’s current LICENSE file before redistributing or commercializing it. At the time of research, the repository displayed an Apache 2.0 license with an attached Commons Clause. Unite.AI correctly highlights the practical consequence: the code can be used internally and modified, but the Commons Clause restricts selling a product or service whose value derives substantially from Switch itself.

That is not a minor footnote for platform teams. “Public source,” “free to run,” and “OSI-approved open source” are different claims. Before adopting Switch as a hosted offering, confirm the exact license text, notices, trademark terms, and any later repository changes. For an internal deployment, also pin a reviewed commit and retain the corresponding license and dependency inventory.

Switch, MCP, and agent interoperability

MCP is one of the connection layers Switch can use, but Switch is not simply an MCP server directory or a replacement for agent frameworks. Its job is to coordinate participants and preserve work context. MCP servers remain responsible for exposing tools and resources; the agent runtime remains responsible for deciding when to call them; the target system remains responsible for authorizing the operation.

This separation connects naturally with the site’s MCP Apps guide: an agent may use an interactive interface for a review or dashboard task, but the UI does not become the backend authority. It also reinforces the security principles in the Google ADK zero-trust guide, where deterministic controls sit around model reasoning and side effects.

For discovery, packaging, and policy-aware selection, the Agentic Resource Discovery guide is a useful companion. A room can help people find the right specialist agent, but discovery must not silently grant that agent access to sensitive data.

Common mistakes and debugging checklist

Treating room membership as authorization

A person being present in a channel does not prove that the agent should see every attachment or execute every tool. Define room-level visibility separately from tool-level authorization, then test with users from different tenants and roles.

Giving a coding agent ambient credentials

The convenience of running an agent from a developer workstation can hide access to SSH keys, cloud credentials, local repositories, and unrelated files. Use a dedicated working directory, a controlled identity, and a disposable or isolated runtime where possible.

Assuming every bridge has the same delivery semantics

Slack Socket Mode, Teams HTTP listeners, Discord gateway connections, Telegram polling, and Mattermost websockets have different retry, ordering, rate-limit, and acknowledgement behavior. Record message IDs and design idempotent handlers before trusting an automated workflow.

Starting with a multi-agent autonomous loop

A room containing triage, coding, deployment, and notification agents is compelling in a demo but difficult to audit. Start with one agent, one data class, one room, and one reversible task. Add another participant only after you can explain every message and side effect.

Confusing a successful message with a successful task

A bridge can deliver a response even when the underlying tool failed, timed out, or returned partial data. Make agents report structured status, evidence links, timestamps, and explicit failure states. The room transcript should make uncertainty visible rather than turning it into confident prose.

Frequently asked questions

Is Switch a new Slack or Teams replacement?

No. Its stated purpose is to connect agents to Slack, Teams, Discord, Telegram, and Mattermost while those collaboration tools remain in place.

Does Switch include an AI model?

No. The project is infrastructure and framework software. You bring the agents and providers you already operate.

Can Switch run on infrastructure I control?

The public README describes the project as designed to be self-hostable and says the server can run on a remote host you own. Validate deployment requirements, supported versions, and operational hardening in the current documentation before production use.

Is the code truly open source?

The source is public, but the repository’s displayed Apache 2.0 plus Commons Clause licensing deserves careful review. Do not assume that “open source” in a product announcement has the same legal meaning as OSI-approved open source.

Should I let an agent deploy code directly from a room?

Not as a first step. Begin with read-only investigation and human-reviewed plans. If you later permit writes, use separate identities, narrow scopes, approval gates, idempotency, audit logs, and a tested rollback path.

Conclusion

Switch addresses a real bottleneck in agent adoption: capable agents often live in separate tools while the team’s context lives somewhere else. Its shared-room model gives people and agents a common place to discuss work, retain history, and coordinate across providers without forcing a new chat product.

The most defensible way to adopt it is deliberately small. Pin a reviewed repository version, read the license, connect one read-only agent, restrict the room’s data, instrument every bridge and tool call, and require a human decision before side effects. If that workflow proves useful, Switch can become a coordination layer for richer agent teams. It should not become an excuse to collapse identity, authorization, and model output into one unreviewed channel.

Sources and visual credits

• SandboxAQ launch announcement on PR Newswire — primary announcement and product claims.
• Switch official GitHub repository — README, architecture, connectors, setup path, repository status, and license.
• Switch README — onboarding commands, supported collaboration platforms, rooms, and deployment notes.
• Techzine coverage — independent product and workflow context.
• Unite.AI coverage and license analysis — independent reporting and Commons Clause discussion.
• Visuals 1–3 are original editorial Mermaid diagrams and tables by Essa Mamdani, based on the official repository and cited reporting. The official repository also links to its own Slack, Discord, and Mattermost walkthrough recordings.

Related reading

Continue exploring related AI engineering and developer tooling topics:

• zvec-grep: Local-First Search for AI Agents
• Cloudflare AI Search: A Practical Guide to Agent Retrieval Infrastructure
• Google Cloud Agent Registry: A Practical MCP Governance Guide