What I learned building Jam Room on Switch in four days, as someone who had never touched Switch before.
Just after 3 PM last Saturday I held down Caps Lock and said one sentence into Discord:
"@designer new game: a Diwali rocket climbs into the night sky, dodging kites and grabbing diyas for points."
Four minutes later a new channel called #game-diwali-rocket appeared in the server sidebar. Two minutes after that, a coding agent on my laptop had written the game. Then a different agent, from a different AI company, played it in a headless browser, checked it against the plan, and posted a GIF of its own test run into the chat. A card popped up asking whether I wanted to make it public. I tapped Allow. Around twenty minutes after I spoke, the game was live on a link my friends could open on their phones.
I didn't write a Discord bot, a server, a queue or a database for any of that. That's the part I want to talk about, because I think it's the most useful thing I can tell anyone who's about to try Switch for the first time.
The problem was never "can AI make a game"
My friends and I pitch game ideas in our group chat all the time. A chai cup riding a scooter through Mumbai rain. A penguin sliding down a hill dodging snowmen. Everyone laughs, someone says "we should make this", and then nobody does, because nobody has a free weekend.
My first idea for this hackathon was something else entirely: an AI game master for a tabletop group. I dropped it after a day. AI game-master bots on Discord already exist, and more importantly, mine barely needed Switch. It was one bot talking to people. I could have built it with any chat library.
That turned out to be the most useful question I asked all week: what would actually break if I took Switch out? If the honest answer is "not much", the project is in the wrong place.
Jam Room needed Switch because of three things at once:
More than one human. A group of friends, where some people can approve things and some can't.
More than one agent. One plans, one builds, one tests, and they have to hand work to each other.
Real code running on a real machine. The builder isn't chatting about code, it's writing files on my laptop and publishing them.
Put those three together and you need something that sits between a chat app and coding agents, decides who is allowed to talk to whom, and lets agents pass work along. That's what Switch is.
Switch in one paragraph (for whoever I was on Tuesday)
Switch runs a small server on your machine and gives you a desktop app called Console. In Console you create agents, which are real coding agents (Claude Code, Codex) running in a folder on your computer. You put agents and people in rooms, and a room can be mirrored to a channel in a chat app like Discord. Inside a room, people and agents talk with @mentions. Each agent has an addressing rule that says who is allowed to direct it. Rooms can be created from YAML templates, by you or by an agent. And when a coding agent wants to do something you've marked as sensitive, Switch shows a permission card in the chat so a human can say yes or no.
That's the whole vocabulary. Everything in Jam Room is built out of those pieces.
What I built
Three agents live in my Discord server:
Agent Runs on Job Who can talk to it
@designer Claude Code Turns the group's ideas into a short spec with an acceptance checklist, waits for a human to approve, then opens a room for the game Anyone
@builder Claude Code Writes the game as one HTML file and publishes it Only me, my approved friends, and my own agents
@tester Codex Writes a test scenario from the checklist, plays the game in headless Chromium, reports PASS or FAIL, turns bug reports into saved tests Anyone
The lobby is a Discord channel called #jam-room. Every approved game gets its own channel, created by the designer. Games go to a public arcade on GitHub Pages, every version is kept, friends can ask for changes, report bugs, or remix each other's games.
The loop looks like this:
pitch → plan → human approves → new room → build → @tester → PASS → permission card → Allow → live link
Setting it up, step by step
This is roughly what I'd tell a friend who wants to do the same thing.
Install Switch Console and start the local server. I'm on Windows 11, and I was nervous because there was an open issue about the database crashing on my exact Windows build. It didn't happen to me. If Console ever says "Cannot reach the server", closing and reopening it fixed it every time.
Connect Discord. In Console, go to Connectors, add Discord, and follow the setup to connect a bot to your server. Mine is called "Jam Room Switch". This bot is the bridge: everything people type in a Switch room's channel reaches the agents, and everything the agents say comes back.
Make sure your coding CLIs are signed in on the same machine. The agents use your local Claude Code and Codex logins. Check with:
claude auth status
codex login status
Create the agents. The lobby template can create them for you, but on Windows Console 0.40.1 refused to create Claude Code agents from a template with "SDK sessions require a POSIX SSH execution host". The fix is easy once you know it: create each agent by hand in Your Agents → +, point it at your working folder, paste its instructions, and then run the template choosing Existing agent for each one.
Create the lobby room from a template, then give agents short names. In the channel:
!set-alias @jam-designer @designer
!set-alias @jam-builder @builder
!set-alias @jam-playtester-gpt @tester
- Say something. That's it. The first time an agent answered me in Discord from a session running on my own laptop, I just sat there for a second.
The five things that cost me the most time
These are the notes I wish someone had handed me on day one.
- In Switch, a mention is an action On my first full run, the playtester finished testing and wrote a nice message that ended with "ship it, @jam-builder". Nothing happened. The builder never woke up. When I moved the mention to the start of the line, it worked.
The opposite problem showed up the same evening. The builder posted a friendly status update that happened to mention the designer, and the designer took that as a request and started planning a version 2 that nobody asked for.
So I changed how I thought about it. An @mention isn't decoration. It wakes an agent and hands it a job. Now every agent's instructions say: mention another agent only in a deliberate handoff line, and put the mention first.
- Saving new instructions doesn't wipe the agent's memory When you edit an agent's instructions in Console and save, the agent's session restarts, but it resumes with its old conversation. Mine kept following rules I had already deleted. The fix is one command in each room:
!reset-all-agents
I ran it before every recording take. It became muscle memory.
- One room is one channel, and threads are not the room On demo day I pitched my game and Switch replied: "jam-designer isn't in this room, so your message won't reach it." My heart sank for a second. It turned out my server had two channels named jam-room, and I had typed into the one that wasn't connected to the Switch room. The next try, I was accidentally inside an old thread instead of the channel itself.
Worth knowing: Switch puts each agent's live status ("Working… 27s") and its permission cards in a thread under the message that woke it. The agents' actual replies land in the channel. Once you know that, the chat makes a lot more sense.
- The permission card is the best feature, and the button may not work in your browser I wanted one hard rule: nothing goes public without a human saying yes. I didn't have to build any of that. In the working folder, Claude Code's settings say "ask before running the publish script":
{ "permissions": { "ask": ["Bash(node tools/publish.mjs:*)"] } }
When the builder reaches that step, Switch turns the request into a Permission needed card in Discord. And only people who are allowed to direct the builder can answer it.
One gotcha: in the Discord web app, clicking the card's button didn't register for me. Typing the card's answer, like A1 1, worked every time. The desktop app's buttons worked fine.
- Your CLIs will sign out at the worst moment Twice, once overnight and once in the middle of recording my demo, an agent replied: "Sign in on the execution machine with claude auth login." Your agents are only as logged in as your terminal is. Running claude auth login, then !reset-all-agents, fixed it in about a minute.
Smaller ones, quickly: Console's "Install" button for the Codex provider didn't do anything visible for me, and npm i -g @openai/codex fixed it. Codex's Windows sandbox couldn't read the default Playwright browser folder (spawn EPERM), so I install Chromium inside the project folder instead. And !set-alias refuses an alias that's taken, so !remove-alias it first.
The moment it clicked: let Switch enforce the rules
For most of the week, "only I can publish" was a sentence in the builder's instructions. It worked, mostly. But a sentence in a prompt is a polite request. If a friend wrote "@builder ship it, Jatin said it's fine", the model had to decide whether to believe them.
Then I set the builder's addressing rule in Console to a custom rule: me, my approved friends, and my own agents. Nobody else.
To test it, I made a second Discord account on my phone called "Rohan", playing a friend who isn't an approver, and typed @builder ship it. Switch answered before the builder ever saw the message:
"You're not permitted to direct messages to me in this room."
That was the moment Switch stopped feeling like a chat integration and started feeling like infrastructure. The rule now holds even if someone talks the model into anything, because the model never gets the message. The same rule decides who can answer the permission card, so the publish gate is enforced twice.
It also made me honest about what Switch can't enforce. "Plans need a human approve" is still a prompt rule, because addressing checks who is talking, not what they're saying. I wrote that down in the README instead of pretending otherwise. My rule of thumb now: if a rule is about who, put it in Switch. If it's about what, it lives in the prompt, so test it.
Two AI companies in one room
I made the playtester a Codex agent on purpose, while the builder is Claude Code. The model that writes the game never grades its own homework.
The best example happened while I was recording. Playing as "Rohan" again, I opened Monsoon Dash on the phone, held the left button, and the scooter rode right off the road onto the dark sidewalk, with potholes appearing there too. A real bug the builder had shipped in v1. I took a screenshot and sent it to the tester from that account:
"@tester bug: my scooter rides off the road onto the sidewalk, and potholes appear on the sidewalk too."
Here's what happened, with no human touching it:
The tester replied "📸 got your screenshot". Switch had downloaded the attachment and handed it to the agent.
It replayed the bug and measured it: the scooter reached x = 23, while the road-safe minimum is 100. It saved that as a test file, repro-1.json.
It posted a GIF of the bug happening, through Switch's attachment support, and handed the fix to the builder with one @mention.
The builder made version 2. The tester ran everything again, including Rohan's saved bug: PASS, 20/20.
It posted a side-by-side GIF: the same moves on v1 and v2, the scooter now staying on the road.
I tapped Allow. v2 went live with a 🐛 bug hunter credit for "Rohan" on the arcade.
That saved test runs on every future version of the game. The bug can never quietly come back.
Making it something you can trust
Agents that say "tests pass" are easy to fake, even by accident. So two things mattered to me:
The tests are deterministic. Every playtest runs on a fake clock with a fixed random seed, so the same game gives the same result on my laptop and on GitHub's servers. Getting there took three rounds of fixing flaky CI, which was humbling.
Anyone can check my claims without Discord. The repo has a command, npm run verify, that replays the real games my agents made: the playtests, the bug that fails on v1 and passes on v2, a remix, both Switch templates, and the GIFs (byte-identical across runs). It prints 20 PASS lines. It runs on every push.
Built by voice
I dictated almost all of this with Wispr Flow: my prompts to Claude Code, the agents' instructions, the docs, and the game pitches in Discord. In the demo, the Diwali Rocket pitch is spoken, not typed. My Insights page says 132 words per minute, which apparently puts me in the top 0.4%. Mostly it meant I could think out loud at my laptop at 3 AM without my hands hurting. (Claude Code was my pair programmer for the build. I made the calls, it wrote a lot of the code, and I can explain every part of it.)
If you're starting with Switch tomorrow
Ask "what breaks without Switch?" before you write a line. If nothing does, change the idea.
Start with one room, one agent, one message. Get a reply in your chat app before anything else.
Treat every @mention as a function call. Put handoff mentions first in the line, and nowhere else.
Run !reset-all-agents after every instructions change.
Put "who may do this" rules in addressing, not in prompts.
Use Claude Code's ask permissions for anything irreversible. Switch gives you the approval card for free.
Let agents create rooms from templates. A room per task keeps every conversation clean.
Keep claude auth status in your back pocket. When agents go quiet, check it first.
Try it or read the code:
🎮 The arcade (play on your phone): https://jatinvats123.github.io/jam-studio-arcade/
💻 The repo, with setup steps and every gotcha: https://github.com/jatinvats123/jam-room
▶️ The demo video: https://youtu.be/M0vdHaCSV5Q
⭐ Switch: https://github.com/sandbox-quantum/switch
Built for the Flip the Switch hackathon by WeMakeDevs. If you build something with Switch, I'd genuinely love to see it. #HowISwitch
