Switch - our team is now composed of 5 devs and 45 agents, all in Slack

I lead the Switch team at SandboxAQ. Switch is an open-code framework that brings the AI agents we use into the collaboration tools where we already work, so humans and agents can share context and work together. 

Yep, we’re a hybrid team of five human developers and 45 AI agent co-workers, all collaborating on Slack ( and Discord). And that's just my team, don't get me started on the shape our entire company is taking.

We've all been hearing phrases thrown around like "AI first company" or "AI native company.". Yes, we get it, you use a lot of ChatGPT and Claude Code. But I'd argue that none of this really fits my vision of "AI native" or "AI first".

What we've turned into, on the other hand, seems to actually start getting there. We became an organization where more than two thirds of our colleagues are AI agents.

I understand that this can sound both incredibly exciting and concerning at the same time, and trust me, it is both! Just like agentic coding is both: a multiplier of productivity or a divider, depending on how you use it. Same goes for the solution I'm going to talk about here.

So here is the story of Switch, the technology that transformed us into this gloriously stitched-together team of humans and AI agents, how it came to life, and how we started using Switch to build Switch.
Here is the link to the github repository, in case you want to skip my lengthy and terrible writing:
https://github.com/sandbox-quantum/switch

How it started: collaborating with our Claude Codes in a room

We started with a frustration: we couldn't share our Claude Code sessions between colleagues. I'd work on a design with my agent for a while, and then I'd want my colleague's opinion on that session, including all its context, not just a summary.

Sure, there are hacky ways to share context: skills, or common artifacts that sessions can reuse, like docs, Confluence pages, repo files, MCP, pretty much anything an agent can pick up. But those felt hacky.

What if instead we had a shared room, like a chat group, where multiple people could coordinate with the same Claude Code sessions? That sounded cool.

And that's where the concept of the Switch room came from: a place where both agents and humans work together towards one goal, with shared context and shared history.

We didn’t want to reinvent the wheel. We were looking for something like WhatsApp group chats, where our Claude Code would be just another user that we could talk to. So we turned to an existing protocol, Matrix, and the homeserver implementation Tuwunel. That gave us a head start on the infrastructure, and the chat clients.

A few weeks later, there we were, working with our Claude Code agents in element.io chat groups, through our very first version of Switch: mostly a wrapper around Tuwunel that let you connect your Claude Code agents to the homeserver as users/clients.

Important point here: the Claude Code sessions were still running as usual in terminals on our own laptops. They connected to the room through a loaded plugin that bundles a local MCP server, which lets the agent send messages to the room via tools and receive messages synchronously via the chat app’s channels feature.

From that moment on, most of our development moved to the chat rooms:

New Jira ticket? Let's create a chat room with the developer working on it, his own Claude Code, and other relevant folks with their own Claude Codes.

Need a brainstorm? Let’s create a new room, with every relevant stakeholders, humans and agents.

Need someone’s review on a feature or on a design ? Bring that person and its agent to the room where the work on the ticket happened
And the list goes on.

This is where we started saying: "We're building Switch, with Switch", maybe too much. But isn't it cool to say you use the product you build to build that same product?

The turning point: Bring your favorite agents to your favorite messaging app

At this point we started thinking to ourselves: "there’s potential here." The way we were working felt like the future of agents, where they would stop being isolated tools that each person uses individually, and become something closer to agent co-workers.

But there was a catch. We tried to share this early prototype internally, and it didn’t catch on. Nobody wanted to move to a new app and try to get all their co-workers to come along with them. Switch couldn’t replace the stack people already used. It had to evolve to meet people where they are. 

• You already have a place where you collaborate with your colleagues: Slack, Microsoft Teams, Discord, etc. People will have a hard time moving from those to a new Matrix client or whatever other collaboration app we'd want to set up, and for good reasons! Let’s instead connect to an existing collaboration app, and bring the agents where your team already collaborates!
• Same is true for your agents. You already have your favorites, the ones you use the most: CLI agents like Claude Code, OpenAI Codex, OpenCode, or agents built with frameworks like LangChain, Google ADK, etc. We're not expecting you to drop those for something we'd build instead. Leave the agent building to the folks who are already good at it. Switch should not ask you to stop using your favorite agents, it brings those agents to where you want them.

With that goal in mind, the next iteration of Switch became more of an interconnector between your agents and your existing collaboration space. And it doesn't care much about what it interconnects, as long as it speaks the right protocol. Your agent speaks the Switch protocol? Then invite it to your messaging app. Does your messaging app implement the necessary interface? Then let Switch bring your agents to it.

Matrix remained our common substrate to bridge into those different messaging apps. Every Matrix room is now associated with a channel in one of them, and interactions are mirrored between the two.

Supported agents have their own connectors that let them speak the protocol. That typically means a local MCP stdio server, plus a skill that teaches the agent how to use the tools, how to collaborate in rooms, and the other things an agent needs to work on a hybrid team.

So here we are: we've connected our favorite CLI based agents (in our case Claude Code and OpenAI Codex) to our company's Slack.

This is a game changer. We can now bring the agents we create to everyone else on our team, in the place where they're already used to collaborating at work. Our usage of Switch to build Switch took off, and then it started gaining adoption throughout the company. Once our developers demonstrated working with our agents with less friction, in a mature collaboration app, we were able to extend the reach of Switch into other territories:

• Our marketing team has a technical question? We have a Claude Code agent that sits on the repo and is available on Slack, and it can answer directly. Same for the sales team.
• Our tech savvy product manager has her own Claude Code, sitting on top of her competitive analysis knowledge base, using her own carefully crafted PM skills. Now she gets to share that agent with any user or any agent in need of PM style assistance.
• Other dev teams are now bringing their own agents (usually Claude Code or OpenAI codex) and replicating the same patterns, working side by side with their coding agents, as a team.

We finally broke through the barrier of spreading this to other teams and units of the company, working on vastly different products and markets altogether.

The unlock: The Switch collaboration framework

Having our favorite agents working side by side with us in slack is quite an achievement, and we are enjoying it. But it’s only the first step. The more we work within our hybrid teams, the more we’ve uncovered areas for making the work more relatable and productive.. Let me give you a few examples:

• The agents we use for coding tend to be quite verbose and love explaining low level technical details. In some rooms/channels that's fine; in others, where we're talking with non-technical people, it really isn't. Channels have implicit rules about how participants should behave. (Most) humans are pretty good at reading those rules; agents and LLMs trained mostly on 1-1 conversations, or over-optimized for coding tasks, are not. They need to be taught how to behave in these rooms.
• Most agents are capable in many areas and could handle different kinds of roles and responsibilities. My Claude Code could be the coder on a task assigned to me, and the reviewer on a task assigned to my colleague or to another agent. Someone else's Claude Code could take the mantle of deploying to staging when a user wants to test things out. Different agents should be able to assume a role, depending on the context.
• Which leads to the next point: if different agents can assume a role, how do you know which one is doing it right now? You should be able to address the role, not the agent.
• Channels relate to each other. The channel where you plan and track the work and the channel where you execute it are connected. We humans know that, and when the work is done we know where to go to say so. Agents don't. We need a way to tell them which other rooms are relevant, and why, so they can jump there if and when needed.
• Some contexts require knowledge from external systems of record. In the room you create to work on a Jira ticket, your agent should probably get a reference to that ticket when it enters, so it can go and check it.

These agents don't instinctively know your ways: how you work, how they should behave in an environment that is foreign to them, what you want or need from them. How much they can help you is constrained by their ignorance of how proper human collaboration happens.

While those may feel like mundane inconveniences, trust me, once you start adding multiple agents into your workspace, they magnify. You quickly realize that to gain velocity you need to keep things under proper control.

Agents need a framework that teaches them how to behave in this new environment they're not used to and don't have the tools to fully grasp. A framework that allows you to design the way agents and humans work together when doing the work that matters to you.

And this is how, little by little, we started building the different blocks of the Switch collaboration framework. Let me introduce a few of them:

• Room instructions: every agent that enters a room (a chat app channel) reads them. Think of it like a room level skill that each agent automatically loads into its session on entry. 
• Roles: something an agent can assume in a context (a room, or a group of rooms), which comes with its own set of instructions. Agents and humans can talk directly to the role, and it resolves to whoever is holding it. Think of it as a skill agents can load, where others can simply address the current holder instead of guessing which agent that is.
• Room links: every room can be attached to another, with a description of how they relate. Agents entering a room see all the rooms attached to it, and can jump to any of them if and when needed.
• External references: rooms can have external references attached, like Jira tickets, Confluence pages, GitHub repos, pretty much anything that supports the purpose of the room and the work to be done. Agents entering the room see all of them.

Refer to the official documentation for more!

‍

Now here is the fun part: the agents don't just live inside the Switch framework, they help build it. All of the above is available to them too. An agent can create a room, write its instructions, define a role and its instructions, link rooms together, attach the references it thinks the next agent will need, invite agents and humans to rooms, etc. So when we design a new way of working, we don't design it for our agents and then hand it down, we design it with them, in the room, and they help us set it up themselves. The framework evolves to meet the needs of the people and the agents who are working in it.

So here we are, with the right tool to help us bring forth the fury of agents' co-workers into our day to day collaboration and workflows, all this while keeping slop in check!

The figure above is a rough, simplified outline of how the Switch team is organized: an interconnected web of rooms where humans and agents work side by side to keep the wheel spinning. To give you an idea of what that looks like in practice, here is how a bug report becomes a released fix, end to end:

1. A user reports a bug in the Bug Report room, through the Slack channel it is bridged to.
2. The bug manager agent replies in the thread, asks a few clarification questions, triages the bug and creates the Jira ticket.
3. The bug manager then heads to the Workforce Hub room to tell the workforce manager agent about it.
4. The workforce manager works out through git blame that Clara is the right person for this one. It creates the branch, creates a room for the fix, invites Clara and her coding agent into it, and asks the agent to start troubleshooting.
5. Clara's agent troubleshoots, fixes the bug, deploys the fix to Clara's local dev stack through her own room based deployment setup, opens a PR and pings Clara for review.
6. Clara reviews and approves.
7. Her agent goes to the deployment room and asks the deployment manager agent to deploy to staging, and a new testing loop starts.
8. Once the fix holds up in staging, Clara goes to the release room and asks the release manager agent to cut a patch release with it.
9. That room's workflow runs its course (the agent gets approval from the manager, then watches the release jobs, and so on) and the bug is officially fixed.

That is a long chain of steps, and Clara only shows up for the two that actually need her judgment: the review, and the call to release. That is what makes it scale. We now get through far more bugs than a team our size ever could, and none of it is magic. Every handover in that chain rests on the pieces described above: the room instructions tell each agent how to behave where it lands, the roles let anyone address whoever currently holds workforce manager or release manager without knowing which agent that is, the room links are what let an agent walk from the bug report to the hub to the fix room to the release, and the references put the Jira ticket and the repo in front of the agents that need them. Take those away and you are left with a few agents sitting in a chat app, waiting for someone to tell them what to do next.

And that is one workflow out of many. The same handful of building blocks is what the rest of our week runs on, and the workflows you would want are almost certainly not ours. That is the point: Switch does not hand you a set of ready-made workflows, it hands you the material to design the ones your team actually needs, and the means to run them where your team already works.

Let's be real

So yeah, that’s a glimpse into our AI native hybrid team and organization. And you know what? It's pretty cool! It feels like entering a new paradigm of teams and orgs, where we design work for both agents and humans. Remember the period of extreme fun and psychosis you had when you started using coding agents to build stuff? This feels like a new one, except now you're designing how your organization of agents and humans turns the wheel.

Now I would be lying to you if I told you that this solution will automatically bring you a 100x boost in productivity for you and your team with little effort. It won't, and it never will. Let's stop with those asymptotical "AI makes you a 100x engineer" takes. It doesn't. Sure, you can write 100x the code you used to, but I can guarantee you nobody cares about that code, and probably neither do you. Let's use realistic terms instead: let's say agents made your team 3x more productive. We strongly believe this solution has the potential to double that. We're fairly confident, because we're getting close to it ourselves. Not there yet, but close.

I use the word "potential" here, and for a good reason. We make getting your agents into your favorite messaging app is the easy part. You can set that up with Switch in minutes, and that's pretty cool, but you'll quickly realize that alone won’t give you the increase in productivity. For that you need to use the framework to design the collaboration and the workflows that let your team gain velocity without going off the tracks. And that is not easy, for two main reasons:

The solution is still in early development, and the experience of working with this framework still has to be drastically improved, to hopefully make it much easier to reach the use cases that will bring you that 3x. Let me give you an example:. Say I spend days designing a use case where a team of agents on Slack autonomously processes and fixes GitHub issues posted on the repo, with humans in the loop mostly for review and steering. That sounds like something a few people would be interested in, but there is no way to share it. Everyone would have to start from scratch. Just imagine using Python, but writing your entire stack from scratch with only the standard library every time.‍

You won't be able to just turn your brain off and get that 3x boost. If you do, your hybrid team will produce more slop than you could ever imagine. This is a framework, and you need to learn the right patterns, the right ways to design how your agents work with you and your team. We'll do our best to make it as easy as possible, but it will never be easy, and it shouldn't be. If something promises a 3x boost in productivity and asks nothing of you, there is a catch somewhere.

Alright, enough talking, want to try it out?

I realize that this touch of transparency and humility might not be the best way to advocate for a new solution, but hopefully it will at least be refreshing in a world where everything thrown at you seems too perfect to be true.

We released the Switch repo a few days back, so if you want to try it out, here you go: github.com/sandbox-quantum/switch. And here is the website, flintai.dev/products/switch, just in case, although I'm sure everyone here will be more interested in the repo 🙂

Don’t expect the most polished solution ever. There is still a long way before this can reach its potential. Part of the reason we shared it this early is that we believe that it’s the kind of product that has to be built with the community. We don’t expect to have all the right answers, so come help us steer the ship! Feedback, both negative and positive are more than welcome!

Bests,
Louis, Lead Eng of the Switch team.