sandbox-quantum

I built a security-report desk that keeps vulnerabilities under embargo, and the chat platform enforces it Open-source maintainers are drowning. One well-funded project, OpenSSL, went from about nine vulnerability reports a month to over a hundred. Of roughly five hundred reports in a year, sixty-three were real. Someone still has to open the other four hundred and thirty-seven. And the ones that are real can't just be fixed in the open: they have to be handled under embargo, where a premature leak is its own kind of harm. I wanted to see whether a small team of people and AI agents, sitting in the same chat, could take that load. The catch is the embargo. An embargo you merely ask an agent to respect is not an embargo, it's a hope. It has to be enforced by something an agent can't talk its way around. That constraint is what made Switch the right substrate, and it's what this post is really about. The one primitive that makes it real Switch puts AI agents into team chat as teammates. Each channel becomes a room, agents join over a simple protocol, and you self-host the whole thing. The feature I built everything on is its guardrails hook: Switch calls an external service before it delivers any message a person or agent sends, and a BLOCKED verdict stops the send. So I wrote a tiny service, the embargo guard, that answers that hook. It holds a registry of open cases, each with the rooms it's allowed in and the strings that identify its material, and it blocks any message that would carry a case's details into a room the case doesn't belong in: def decide(room_id: str, content: str) -> Verdict: for case in registry.active_cases(): if room_id in case.allowed_rooms: continue # this room is inside the embargo leaked = [s for s in case.secrets if s.lower() in content.lower()] if leaked: return Verdict("blocked", case_id=case.case_id, detected=leaked) return Verdict("ok") One gotcha cost me a debugging session: the guard's wire outcome has to be the exact token GUARDRAIL_RESULT_OUTCOME_BLOCKED. Return a friendly lowercase "blocked" and Switch treats it as an engine error and fails open, so your message goes through unchecked. Once that was right, the guarantee became structural. When an agent tries to leak a case into a public room, Switch refuses the send with an HTTP 422 and posts a "blocked by Switch Trust" notice in its place. Take Switch out and there is nothing left to enforce the embargo. That's the whole thesis. The desk around it With enforcement handled, the rest is just good Switch design: - A public intake room where reports arrive. - An intake agent that grounds each report and, for a plausible one, opens a private Switch room per case containing a reproducer, the reporter, and a human security lead (an exclusive role, a job exactly one person holds at a time). - A disclosure agent that drafts the advisory, holds it under embargo, and publishes to a public advisories room only after the human signs off, lifting the embargo first, then publishing, never the other way round. Agents of different kinds join over the agent protocol: my deterministic intake, reproducer and disclosure agents, plus an optional Claude Code read when I want a second opinion on a case. The rooms, the roles, the links between them, all Switch. Don't trust the report, ground it The other half is triage quality. Most slop cites a version, an option, or a bug that doesn't exist. So the intake agent doesn't reason about the prose, it grounds the claim against curl's own authoritative advisory feed (vuln.json): is the version the report names actually inside a known-affected range for that bug class, and does it match a specific advisory? And the reproducer runs the real, published curlimages/curl:<version> image and reads back what the binary actually reports. A report that names a release or a flag that doesn't exist is answered with the evidence, no exploit needed. I measured it honestly. The corpus is 227 real curl reports: every confirmed CVE from curl's feed, the curl maintainer's own public list of reports that were submitted as vulnerabilities and were not, and a negative control of "the patched version is still vulnerable" claims that a correct desk must catch. | | accepts invalid reports | keeps real reports | review auto-saved | |---|---|---|---| | Trust the write-up | 85% | 83% | 0 | | Embargo (grounded) | 14% | 100% | ~26 hours | Every figure is rendered from a reproducible run (python bench/run.py), and the 14% false-accept is listed as the honest limit, not hidden. It runs across platforms, because the embargo lives in Switch The part that sold the self-hosting story for me: reporters can file in Discord while the maintainers' case rooms stay in Mattermost, and the embargo holds across both, because it's enforced in Switch, not in either chat app. I posted a bogus "buffer overflow in the latest curl" report in Discord and watched the agent ground it against curl's records and turn it away with the reason, live, in the channel. What I'd change about Switch Three things, in the spirit of building in the open: 1. The guardrails check gates agent sends. A human message posted straight into a channel isn't gated the same way, so I enforce on the agent side. An inbound path would close that. 2. An agent needs one session per room today, so I run one process per platform room. One session attending several rooms would be cleaner. 3. The task-delegation protocol is marked not-ready. Finishing it would make agent hand-offs first-class instead of done by addressing. None of that blocked the build. The guardrails hook alone turned "please keep this secret" into a thing the platform enforces, and that's the piece I'd been missing. --- Try it: repo, RaYYeR220/embargo · live demo, embargo-desk.vercel.app · 100-second walkthrough, youtu.be. The five-minute reviewer path is in JUDGES.md, and every claim's evidence is in CLAIMS.md. Built for the Flip the Switch Hackathon (WeMakeDevs x DevTools Academy x Switch).

How I use a Claude Code agent in Telegram to track my hackathon deadlines This month I'm entering five hackathons. Each one has a different deadline, a different timezone and different rules. I kept forgetting what was due first. So I built a helper. It's a Claude Code agent in my Telegram group. I ask it "what's due?" and it lists my deadlines in my own timezone, soonest first. I ask "is bountypay ready?" and it checks my GitHub repo and my demo site, then tells me what is still missing. When I finish something, I tell it, and it updates its list. {% embed youtu.be %} The code is here: mohammedfirdouss/hackathon-copilot What Switch does Switch is an open-source tool. It connects AI agents to chat apps like Slack, Discord and Telegram. Switch does not give you an agent. You bring your own, like Claude Code. When someone messages the agent in the chat, Switch starts it on your computer and passes the messages back and forth. So Claude Code runs on my laptop, and I talk to it from Telegram on my phone. How it works The project has three main files. - hackathons.toml is my list of hackathons. Each one has a deadline, a repo and a list of things I must submit. - copilot.py is a small Python script. It works out how much time is left and checks each requirement. For example, it checks if the repo is public, if it has a license, and if the demo site is up. - CLAUDE.md tells the agent what to do. It says: always use the script for dates and checks, keep replies short, and never submit forms or post anything for me. The script does the maths, so the dates are always right. The agent understands my question and explains the answer. !The agent listing what's due !The agent checking if BountyPay is ready How to set it up You need Python, Node.js, the GitHub CLI, a Claude Code account and a Telegram account with a username. 1. Install Switch Console from the releases page. 2. Click Add a server, then Run a server on this computer. Wait about a minute. 3. In Telegram, open @BotFather and send /newbot to make a bot. Save the token somewhere safe. 4. In BotFather, turn Group Privacy off for your bot. 5. In Switch Console, connect Telegram using the bot token and username. 6. Make a Telegram group and add the bot to it. 7. Send a message in the group. Then, in Switch Console, click Link my account and choose yourself. 8. In Switch Console, create a Claude Code agent. Set its folder to the project folder. 9. In the group, send !invite-agent @your-agent-name, then !set-alias @your-agent-name @copilot. Now send @copilot what's due? Mistakes I made I changed Group Privacy too late. Turn it off before you add the bot to a group. If you forget, remove the bot and add it again. I added the bot before connecting it. Connect the bot in Switch first, then add it to the group. I couldn't find myself when linking my account. Switch only knows people who have sent a message in the group. Send a new message, then search again. The agent ignored my instructions. It was running in an empty default folder, so it never saw my CLAUDE.md. I fixed it by linking that folder to my project folder. If your agent acts strangely, check which folder it runs in. My lines got merged into one paragraph. Telegram joined my lines together. Starting each line with - fixed it. What's next I want a morning message with my deadlines. Switch can't schedule messages yet (issue #771), so for now I have to ask. If you have many deadlines too, copy the repo, put your own hackathons in hackathons.toml, and connect it to Switch.

Building MemoryWeaver: Claude Code Meets Codex via Switch From Scattered Memories to a Collaborative AI Travel Journal What if a group of friends could turn their scattered vacation photos, casual chat messages, and small personal memories into a beautifully designed travel journal—without having to organize everything themselves? That question inspired me to build MemoryWeaver, a collaborative AI-powered travel journal created for the Flip the Switch Hackathon, Track 2: Best Personal or Creative Workflow. But MemoryWeaver is more than an AI photo album. It is an experiment in letting different AI agents work together, with different responsibilities, through a shared workspace. Instead of asking one model to do everything, I connected Claude Code, OpenAI Codex, and specialized workflow agents through Switch, using Mattermost as the place where humans and AI collaborate. The result is a workflow that turns conversations into a finished travel journal—and lets people improve that journal simply by sending another message. Try MemoryWeaver Interactive showcase: winter-unit-6999.tetete-0618.workers.dev 3-minute demo video: youtu.be GitHub repository: Tetsuya-Uchimura/memoryweaver-stories The public showcase is a read-only interactive presentation of the travel conversations and generated journals. The actual AI workflow runs locally through Mattermost, Switch, Claude Code, and Codex, as shown in the video. 1. The Problem: Memories Are Scattered Think about your last trip. Some memories live in your camera roll. Others are buried in group chats. Someone remembers a funny moment at a café, while another person has the perfect photograph but no written context. Most of these fragments never become a meaningful story. Traditional photo albums focus on organizing pictures. Generative AI can write descriptions, but a single prompt often lacks the context behind those pictures. I wanted to create a different experience: People share their memories naturally. AI teammates work together to turn those memories into something worth keeping. This became the central idea behind MemoryWeaver. 2. What MemoryWeaver Does MemoryWeaver uses Mattermost as the starting point. Travelers can post photographs, describe experiences, and talk about their trip in a shared conversation. When they are ready, they ask an AI teammate to create a travel journal. For example: @mw-collector Make an English travel journal of our Kyoto trip. Keep all the original memories and photographs. The system then coordinates a multi-agent workflow. Collector gathers the original messages, photographs, and available location information. Claude Code (Storyteller) writes a structured travel narrative grounded in those memories. OpenAI Codex (Editor) reviews the draft against the original evidence. Publisher creates the finished web journal and PDF, then delivers them back to Mattermost. The completed journal includes photographs, chapters, source references, and an interactive location map when coordinates are available. MemoryWeaver also supports revisions. A traveler can ask: @mw-collector Please use the bamboo grove photograph as the cover. Keep the other memories and chapters unchanged. The AI team processes the request and produces a new version. Previous versions remain accessible. This creates a collaborative loop between people and AI rather than a one-time generation process. 3. Why I Chose Switch I could have built a conventional pipeline that calls one model, then another, and passes JSON between them. But I wanted the agents to behave more like teammates working in a common environment. Each agent should be able to understand its role, access relevant shared artifacts, and hand work to another agent without relying on a giant application-level prompt. That is where Switch became central to MemoryWeaver. I use three important Switch capabilities: Shared rooms The agents participate in a collaboration space connected to a Mattermost travel channel. Human requests, progress messages, and agent handoffs belong to the same workflow context. Shared documents Instead of passing an entire travel journal through chat messages, agents create and read structured documents for collected evidence, drafts, and reviews. Targeted messages Agents can explicitly hand work to the teammate responsible for the next step. For example, Claude Code can hand a completed draft to Codex for review. Codex can then pass its reviewed artifact to Publisher. The important distinction is that Switch coordinates the collaboration; Claude Code and Codex perform their own AI reasoning and editorial tasks. Switch is not simply another text-generation model. MemoryWeaver architecture: Switch connects Mattermost, Claude Code, Codex, and specialized workflow agents. 4. The Architecture MemoryWeaver combines local infrastructure, desktop AI agents, and a web-based reading experience. The main components are: Component Responsibility Mattermost Human conversations, photographs, instructions, and delivery notifications Switch Shared rooms, documents, events, and targeted agent handoffs Collector Source gathering, photo handling, and evidence preparation Claude Code Travel-story drafting OpenAI Codex Editorial review and evidence checking Publisher Version storage, web journal generation, PDF creation, and delivery FastAPI web app Reading journals, exploring photographs and maps, viewing saved versions The agent handoff follows this sequence: Travelers / Mattermost | v Switch | v Collector | Creates an evidence document v Switch shared documents | | MW_CONSOLE v Claude Code — Storyteller | Creates a structured draft | | MW_DRAFT v OpenAI Codex — Editor | Reviews the source evidence and draft | | MW_REVIEW v Publisher | +--> Versioned web travel journal +--> Cover preview +--> PDF | v Mattermost delivery message In the implemented workflow, the original evidence, draft, and review are separate Switch documents. The next agent retrieves the appropriate document instead of depending on a copied summary of the previous agent's work. The native Claude Code and Codex sessions run through Switch Console, while the application services run in Docker. This separation also means the developer's AI-provider authentication does not have to be copied into the application containers. 5. Why Two Different AI Agents? One of my design goals was to avoid treating every AI agent as interchangeable. Claude Code and Codex have different responsibilities in MemoryWeaver. Claude Code: The Storyteller Claude Code focuses on transforming fragmented memories into a coherent travel narrative. It receives collected evidence and produces a structured draft containing the story, chapters, selected photographs, and references to source material. The storytelling task requires creativity, but it also needs boundaries. For example, if a photograph shows a temple, the model should not invent an emotional conversation or a historical event that was never mentioned by the travelers. Codex: The Editor Codex approaches the draft from a different perspective. It examines whether the story is consistent with the original memories and photographs. Its review focuses on questions such as: Are the referenced memories valid? Are dates and locations supported? Does a quotation appear in its cited source? Are photographs associated with the correct memories? Has the story introduced unsupported details? This does not guarantee perfect factual accuracy. Human review still matters. However, separating creative writing from editorial review makes the workflow easier to understand and validate. Switch: The Connection Between Them The most interesting part is not simply that Claude writes and Codex reviews. It is that the handoff happens through Switch. Collector creates evidence, Claude produces a draft, Codex checks that draft, and Publisher receives the reviewed result. Each agent works within its own role while sharing the artifacts required for collaboration. Different AI agents. Different strengths. One shared workspace. That is the central technical concept behind MemoryWeaver. 6. Making Agent Handoffs Reliable Connecting multiple agents was one of the most challenging parts of the project. During development, I discovered that a successful model response does not automatically mean the entire workflow has succeeded. An agent may produce a draft, but another agent might fail to receive the handoff. A review could reference an outdated draft. A service could restart while a delivery is still pending. I addressed these problems at several levels. Structured artifacts and explicit references Each stage uses a structured document with defined fields. The review refers to the specific draft and evidence associated with the current job. Publisher validates document references, hashes, source citations, and other constraints before accepting the reviewed result. Verifying the actual sender A message that merely contains the text MW_REVIEW should not be trusted as an authentic editor handoff. MemoryWeaver checks the authoritative participant information supplied by Switch, rather than treating an arbitrary message prefix as proof of agent identity. Keeping previous versions When someone requests an edit, MemoryWeaver creates a new journal version instead of overwriting the old one. This makes it possible to compare a cover change and verify that unrelated chapters and photographs were preserved. Handling partial failure The workflow tracks processing and delivery state, including attempts to resend saved PDF artifacts. There are still MVP limitations: interrupted handoffs may require a fresh request, and the system is not a general-purpose distributed transaction engine. Being explicit about those limitations helped me build a more understandable system. 7. From AI Output to a Beautiful Product A technically interesting agent system is not enough if the final result feels like raw model output. I wanted the travel journal to feel like a finished creative artifact. An example of a finished MemoryWeaver travel journal. MemoryWeaver supports destination-specific visual styles. Kyoto uses a quiet, editorial design inspired by Japanese travel journals, with restrained typography and bamboo photography. Paris uses a more magazine-like editorial presentation. New York uses a contemporary urban visual style. The MemoryWeaver travel journal experience. The travel journals combine text, photographs, location information, and PDF output. When location coordinates are supplied, the browser can also display an interactive OpenStreetMap-based map with markers associated with the source photographs. Importantly, the map does not automatically invent locations from pictures. Fictional sample locations are labeled as approximate landmarks rather than original camera GPS positions. The goal is to keep the output visually compelling without losing track of where the information came from. 8. Human-in-the-Loop Editing One of my favorite parts of MemoryWeaver is the editing experience. Instead of opening a complex editor and manipulating layouts manually, a traveler sends a natural-language request in Mattermost. For example: Please change the cover to the bamboo grove photo, but keep every other memory and chapter unchanged. That request enters the same collaborative workflow. The agents inspect the existing journal, prepare the requested change, review it, and deliver a new version. I tested this experience with a Kyoto journal. The live Claude Code → Codex → Publisher workflow produced saved editions, and the cover was updated while preserving the underlying memories and chapter content. This is where the multi-agent system becomes something people can actually experience. Users do not need to understand the internal architecture to collaborate with the agents. They simply describe what they want to change. 9. Testing and Reproducibility For a hackathon, I believe reproducibility is part of the product. A demo video alone cannot show whether a system is reliable. MemoryWeaver includes a Docker-based development environment with Mattermost, Switch, the web application, and supporting services. The project pins the Switch server to a specific upstream source revision, helping prevent unexpected changes between installations. The official Switch Console manages the local Claude Code and Codex sessions. A fresh installation generates its own local credentials rather than shipping the developer's passwords or provider tokens. The project also includes deterministic replay fixtures so the infrastructure and UI can be tested without making live AI requests. The distinction between LIVE AI and REPLAY DEMO is visible in the application. At the time of this article, project verification included: 77 passing Python tests 22 passing desktop/mobile Chromium browser tests Real Claude Code → Codex → Publisher handoffs tested through Switch Console PDF and cover attachments checked against saved artifacts Fresh Docker environment testing Explicit documentation of remaining setup and deployment limitations The complete test history and limitations are documented in the repository's docs/VERIFICATION.md. A fully fresh native-agent setup on a second physical machine remains unverified. Using the real providers also requires individual authentication and manual Switch Console agent registration. I prefer to document these requirements rather than imply the entire AI environment starts automatically with one command. 10. A Public Showcase Without Exposing the Private Workflow MemoryWeaver is designed around personal memories, so privacy matters. The local application is not a production-ready multi-user hosting service, and its internal Switch and Mattermost endpoints should not be exposed directly to the public internet. For the hackathon, I created a separate interactive showcase hosted on Cloudflare. It lets visitors explore a read-only representation of the travel conversations and completed journals without needing an account. The public showcase does not run Claude Code, Codex, or Switch inference. Instead, it illustrates the experience using selected fictional sample data and saved results. That distinction is important. The public showcase demonstrates the user experience. The local workflow and video demonstrate the actual AI collaboration. The sample photographs are credited separately in docs/PHOTO-CREDITS.md, with attribution and license details. The source-code license does not replace the individual photo licenses. 11. How to Run MemoryWeaver Developers who want to explore the workflow can start with the GitHub repository: Tetsuya-Uchimura/memoryweaver-stories The Docker environment can be started with: cd memoryweaver-stories python3 scripts/dev.py up python3 scripts/dev.py status A sample replay experience can then be prepared with: python3 scripts/dev.py seed --all --generate The local services use these default addresses: Service URL Mattermost localhost Switch Gateway localhost MemoryWeaver web app localhost The replay experience uses deterministic sample content and does not require AI-provider authentication. For a real Claude Code and Codex collaboration, install Switch Console, authenticate both providers, register the Storyteller and Editor agents, and bind them to MemoryWeaver. The repository README and docs/CONSOLE.md document these steps in detail. 12. What I Learned Building MemoryWeaver changed how I think about AI agents. At first, I was focused on what AI could generate. As the project evolved, I became more interested in how different agents could collaborate reliably. Three lessons stood out. Shared context is more valuable than longer prompts The agents work better as a system when they can access clearly defined evidence, drafts, and reviews instead of reconstructing everything from a large conversation. Specialization makes responsibilities visible Separating writing, fact-checking, collection, and publishing gives the workflow clearer boundaries. When something goes wrong, it is easier to understand which stage needs attention. AI collaboration should remain connected to human intent The finished artifact matters, but the ability to request corrections and preserve previous versions matters just as much. MemoryWeaver is not about replacing human memories with AI-generated stories. It is about helping people turn their own memories into something meaningful. 13. What's Next? There are several directions I would like to explore after the hackathon. First, I want to simplify the initial Switch Console setup so new users can start collaborating with AI agents more easily. Second, I want to support more flexible travel groups and permission models, rather than relying on a predefined set of sample rooms. Third, I want to improve the editorial workflow with clearer human review checkpoints and richer collaborative feedback. And finally, I would like to explore other creative workflows beyond travel: family history, shared event journals, project retrospectives, and collaborative storytelling. The underlying idea is the same. Take information that already exists in human conversations, let specialized agents work together on it, and create something useful without losing the original context. Final Thoughts MemoryWeaver started with a simple frustration: our memories are scattered across photographs and conversations. Switch made it possible to approach this as a collaboration problem rather than just a text-generation problem. Claude Code writes. Codex reviews. Collector organizes. Publisher delivers. And humans remain part of the process through Mattermost. The result is a travel journal, but the more interesting achievement is the workflow behind it. Different AI agents. Different strengths. One shared workspace. That's what I wanted to build with MemoryWeaver. Links Interactive showcase: winter-unit-6999.tetete-0618.workers.dev Demo video: youtu.be Source code and setup: Tetsuya-Uchimura/memoryweaver-stories Switch: sandbox-quantum/switch Built for the Flip the Switch Hackathon — Best Personal or Creative Workflow.

How I Turned an AI Coding Agent into a Collaborative DevOps Teammate in 1 Day The Problem: The "Solo Agent" Isolation Trap Over the past year, AI coding agents like Claude Code, OpenCode, and Codex have revolutionized how individual engineers write software. But they created an unexpected bottleneck: isolation. When an engineer uses an AI agent in their local terminal, all of that reasoning, root-cause diagnosis, and context happens in a private silo. If production goes down or a critical bug appears: - Only the person sitting at that terminal sees the AI's hypothesis. - Other on-call engineers are left in the dark. - Junior developers miss out on seeing how seniors and AI diagnose issues together. I wanted to change that. What if, instead of keeping the AI locked inside a private terminal, we brought it directly into our team chat as an active DevOps teammate? Enter SwitchOps. --- The Solution: SwitchOps SwitchOps is an autonomous bug triage and incident-response teammate that lives inside team chat channels (powered by Mattermost and Switch AI). When a developer shares an error log, stack trace, or incident alert in #bug-triage: 1. SwitchOps reads the context instantly via the Switch chat bridge. 2. It assigns an urgency rating (🔴 P0 - Critical, 🟠 P1 - High, 🟡 P2 - Medium, 🟢 P3 - Low). 3. It formulates a root cause hypothesis based on logs, recent changes, and stack traces. 4. It posts structured next steps and code fixes right in the public thread for everyone on the team to collaborate on. --- How It Works Under the Hood The architecture leverages three key developer technologies: [Developer Speaks via Wispr Flow] │ ▼ [Mattermost #bug-triage] │ ▼ [Switch Console Bridge] │ ▼ [SwitchOps Agent] │ ▼ [Triage Thread Reply] 1. Switch AI: The Agent-to-Chat Bridge Rather than writing brittle webhooks, managing Slack OAuth tokens, and paying per-token API charges, Switch runs local agents in the background and bridges them directly to chat platforms. Switch Console spins up a bundled Mattermost instance locally inside Docker, creating an instant collaboration sandbox. 2. Voice-First Incident Response with Wispr Flow During high-pressure incidents, typing long stack traces or explaining symptoms is slow. Using Wispr Flow, I was able to push-to-talk dictate bug reports directly into chat at 96 words per minute. Wispr Flow’s auto-formatting accurately captured technical tokens like JWT, OAuth, 500 HTTP, and connection pool without voice typos. --- The Build Journey: Overcoming Real-World Bugs Building SwitchOps wasn't without hurdles. On Day 1, while connecting Switch Console to our local environment, we encountered a port configuration mismatch: the native Switch Core was failing to register the local server on custom ports. Instead of working around it silently, we documented the bug, identified the root cause in ports.json, and submitted an official issue (#1482) to the open-source Switch repository to help other developers running the native toolchain. --- Live Triage in Action Here is what the workflow looks like in real engineering scenarios: Scenario 1: Production Checkout Outage (P0) A developer dictates via Wispr Flow: > "Team, production checkout is completely down after the v2.4 deployment. Getting HTTP 500 database connection pool exhausted. Users cannot place any orders." Within seconds, SwitchOps replies: - Severity: 🔴 P0 — Critical (service blocked) - Affected Area: Backend / Database - Root Cause: Connection pool leak correlated with v2.4 deployment - Action: Initiate rollback, check unclosed connections, and monitor pool recovery. Scenario 2: Broken Google OAuth Logins (P1) When users experience JWT signature validation failed, SwitchOps points the team toward Google's public key rotation and verifier caching rather than rolling back unrelated services. Scenario 3: CSS Layout Collision on Mobile (P3) Even for minor visual glitches, SwitchOps suggests exact CSS media query solutions for screens under 375px. --- What I Learned 1. AI Belongs in the Room Where It Happens: Moving an AI agent from a personal shell into a team chat channel turns AI assistance into team knowledge. 2. Voice Dictation Speeds Up Operations: Wispr Flow makes incident reporting tactile and fast. Speaking a 50-word bug report takes 15 seconds. 3. Local-First Architecture Wins: With Switch, all execution happens on your machine. You don't leak private incident data or internal error traces to third-party cloud bridges. --- Try It Out Check out the full open-source project and step-by-step setup guide: - GitHub Repository: devprotim/switch-workflow - Built for: Flip the Switch Hackathon (Nov 2026)

How I Built an Autonomous SRE War Room with Switch AI, OpenCode & Wispr Flow When a production outage hits at 2 AM, every second counts. I built IncidentRoom — an autonomous SRE war room that turns any team chat channel into a self-coordinating incident response system using Switch AI. Here's what actually happened during our live demo: a SEV-1 alert fired, three AI agents collaborated in a shared Mattermost room, identified the root cause commit in under 60 seconds, ran real bash commands to prepare a rollback, waited for a single human APPROVE command (voice-dictated via Wispr Flow), executed the fix, and auto-generated a full post-mortem — all in under 2 minutes. The Problem We Solved Traditional incident response is chaotic: - Context is fragmented across monitoring tools, Slack threads, and git history - Engineers waste precious minutes manually correlating stack traces to recent PRs - Stakeholder updates distract the on-call engineer from actually fixing the issue - Post-mortems are written hours or days later from memory MTTR (Mean Time to Resolution) suffers not because engineers are slow — but because coordination is broken. Enter Switch AI Switch is an open-source platform that connects AI coding agents (Claude Code, Codex, OpenCode, Cursor, Antigravity) into team chat channels as first-class participants. Agents can read messages, respond to @mentions, run bash commands, hand off context to each other, and await human approval — all inside Mattermost, Slack, Teams, or Discord. This is the missing piece for incident response. Architecture: 3 Agents, 1 Room, Zero Chaos 📢 Alert fires in #incident-war-room │ ▼ @triage-agent ──→ 11 tool calls ──→ Root cause: commit 8f2b31a │ ▼ HANDOFF @sre-agent ──→ npm pack stripe@3.4.0 ──→ "Awaiting APPROVE" │ ▼ Human: "APPROVE" (via Wispr Flow voice) @sre-agent ──→ Rollback executed ✅ │ ▼ @comms-agent ──→ Post-mortem generated 📄 The Three Agents @triage-agent — The Incident Detective Receives the alert via @mention, parses the stack trace, correlates against recent git commits, and isolates the root cause. In our live demo: triage-agent BOT · Worked for 3m 16s. 11 tool calls. 🔍 TRIAGE — root cause identified: commit 8f2b31a ("feat(payments): upgrade stripe sdk v3.4") Root cause: services/payments/stripe_gateway.js:84 passes a null options object to the Stripe create call; stripe-node v3.4 now unconditionally reads options.idempotency_key, so createSession throws before reaching Stripe. @sre-agent — The Remediation Specialist Receives the handoff, evaluates blast radius, executes real bash commands to prepare the rollback — but never deploys without human approval: # Actual command run by @sre-agent npm pack stripe@3.4.0 --pack-destination /tmp/opencode/stripe340 Then waits. No autonomous deployment. Human-in-the-loop is non-negotiable. @comms-agent — The Incident Commander & Scribe Handles stakeholder communication and auto-generates the post-mortem with MTTR, timeline, root cause, and action items. Voice-Powered with Wispr Flow Here's the detail that makes this truly hands-free: I used Wispr Flow to voice-dictate every incident command without touching the keyboard. While monitoring dashboards, I spoke: > "Alert: Save one HTTP 500 error spike in checkout payment gateway at triage agent. Please investigate the root cause. Commit. Approve, roll back, and notify all stakeholders. @Comms agent generate the postmortem report." Wispr Flow transcribed this at 100 wpm, 405 total words across the incident session. That's the entire incident — triage, approval, and post-mortem command — dictated hands-free. !Wispr Flow scorecard showing 405 words, 100 wpm, 1 day streak The Live Results | Metric | Result | |--------|--------| | Time from alert to root cause | < 60 seconds | | Triage agent tool calls | 11 calls, 3m 16s | | Human touch-points | 1 (APPROVE) | | Wispr Flow words dictated | 405 words @ 100 wpm | | MTTR | Under 2 minutes | | Post-mortem generation | Automatic | Community Wisdom That Shaped This Building this, I learned from the community: - Agentic incident response is where autonomy meets the pager — reinforced that read-only defaults and approval gates are non-negotiable - NexusOps: Multi-Agent SRE Command Center — validated the multi-agent pattern for SRE workflows The key insight both posts validate: agents need approval gates before any write operation in production. We enforced this strictly — @sre-agent never executes a deployment without an explicit human APPROVE in the room. How to Run It Yourself git clone https://github.com/swatiicfai/IncidentRoom cd IncidentRoom cp .env.example .env # Add your Switch server URL npm install node src/simulate.js # Trigger a live SEV-1 simulation You need: - Switch Console running locally - OpenCode (or any Switch-compatible agent) installed - Mattermost running in Docker (Switch provides this out of the box) What's Next 1. Webhook integration — Datadog/Sentry/PagerDuty alerts fire directly into the room 2. Canary verification — @sre-agent checks error rate baseline post-rollback before declaring resolution 3. Multi-room escalation — auto-create a dedicated room per SEV-1 instead of using a standing channel 4. Agent memory — triage agent remembers past incidents to pattern-match faster 🔗 Resources - GitHub: swatiicfai/IncidentRoom - Demo video: youtu.be - Switch AI: sandbox-quantum/switch - Post-mortem: See POSTMORTEM_LIVE.md --- Built for the Flip the Switch Hackathon by WeMakeDevs × Switch AI. This post was written with AI assistance (Antigravity/Gemini) during the hackathon session.

Huge props to sandbox-quantum for building such a clean, self-hosted architecture that drops AI teammates right into your chat. Seriously slick workflow for bringing any model to Slack and Discord. 🚀 🔗 项目地址：sandbox-quantum/switch

How I Used Switch to Build an AI Playtest Team for Board Games If you design board games, you know the problem. A bad rule can hide for months, because getting people around a table is hard, and getting them there ten times is harder. For the Flip the Switch hackathon, my team built Boardgame Lab. You paste your game's rules into a chat, and an AI engineer asks about anything unclear and builds the game. AI players play it, an AI analyst measures what happened, and only you can change the rules. On its first run with a game we hadn't tuned, it found that the player who goes first won only 28.1% of random games, against about 36% for the other two. Nobody planted that problem. We didn't know it was there. Why not just ask one AI to play all the seats? That was my first thought too, but it doesn't work for most card games. One AI playing every seat sees every hand, so nobody is really bluffing or guessing. You need separate players who can't see each other's cards, and you need to be able to watch them play. Switch gave us both. What Switch is, for first-timers Switch is open-source software that puts AI agents into chat apps. Each channel becomes a room, and agents join it like any other team member. You only need four of its ideas for this project: - A room decides who can see what. An agent only sees rooms it belongs to. - An agent can be an AI coding tool, such as Claude Code or Codex, or your own code connected through Switch's agent protocol. - A role lets you call a job instead of a person, such as @balance-analyst. - A template is one file that creates a whole team of agents and rooms in one go. What we built There's one public room and three private ones. lab-table is the public table, where everyone including you can see moves get revealed, and where you make decisions. lab-seat-1, lab-seat-2 and lab-seat-3 are private rooms, each with one AI player and the referee. You're in those too, so you can watch. The team has three AI players (Hawk, Patient and Gambler), a Rules Engineer and an Analyst. The referee isn't AI. It's about 550 lines of plain Node.js, so it can't be talked into bending a rule. lab-table (public) everyone sees moves and decisions | REFEREE plain code / | \ lab-seat-1 lab-seat-2 lab-seat-3 Hawk only Patient only Gambler only You can see all of these rooms. A player can only see the table and its own seat. Hawk gets its hand in its own room, and no other player can read it: !The referee deals Hawk a private hand of 4, 8 and 11 in the lab-seat-1 room How to set it up You need Switch Console, Docker Desktop, Node.js 22.9 or newer, and Claude Code or Codex signed in. We tested on Windows only. The agents run on your own Claude or Codex plan, so games use up your plan's limits. I hit my Claude Pro limit while rehearsing, so keep your first tests small. 1. Start a server. Open Switch Console. On the first screen, choose On this computer. If you've already set up Console, it's called Run a server on this computer in the Add server dialog. Then, with Docker running, turn on Mattermost under Admin → Status. Mattermost is the chat app you'll use. 2. Connect the referee. Clone the repo and run this once. Your server has to be running first: npm run referee:register You'll know it worked when it prints Registered, followed by the referee's name and where its key is saved. Now start the referee, and leave this window open: npm run referee You'll know it worked when it prints Connected as. The referee won't be listed under Your Agents, because that list only shows agents Console runs itself. 3. Import the template. Go to Templates → Import template and choose templates/boardgame-lab.template.yaml. Set Repository folder to your clone. The Playtest name is added to the start of every room name, and I'm using lab in this post, so a different name gives you different room names. Select Create all once, and give it a few minutes. 4. Start a game. Under Rooms in the left menu, open lab-table. The referee starts on our test game, Salt Run. Type this whole line in one go: @boardgame-referee deal 7 You'll know it worked when the referee posts Game 1 (seed 7) and the game's rules at the table. The number is a seed, so the same number deals the same cards. The agents then play in their private rooms, and moves appear at the table. A game takes about 3 minutes. A real run We pasted in a short rulebook for a card game called Ember Line, which we hadn't tuned or planted anything in. Before building anything, the engineer asked three questions, including one we hadn't thought of: "If you play a card lower than the last card, and that last card was yours, do you still give yourself the 3 points?" Then it wrote the game. A checker, also plain code, tested the result. It plays 300 random games and rejects any game that crashes or never ends. It also scrambles the other players' secret cards and checks that a player's view doesn't change, which proves the game doesn't leak anyone's hand. After the players finished, the analyst turned what it saw into a strategy and ran 10,000 simulated games per strategy. It also spotted a problem we didn't know about: the player who goes first won only 28.1% of random games, against about 36% for the other two. !The analyst's report: its holdopen strategy at 47.2%, and seat 1 at 28.1% under random play I told the engineer, in plain words, to make a new version where whoever opens scores a flat 3 points. Then I loaded it, and the referee compared both versions: !The referee loads ember-line-v2, passes the checker, shows a sample game and posts a before-and-after table The seats went from 28.1%, 35.6% and 36.2% to 32.4%, 34.1% and 33.5%, and a fair share is 33.3%. The fix has a cost, though. The climber strategy went from 44.5% to 48.6%, close to the 50% line where we'd call a strategy broken. Whether that's acceptable is a design decision, so the tool leaves it to a person. How Switch does the hard parts A template creates the whole team. This is a private seat room, trimmed down. The private channel and the short list of agents keep a hand secret: - name: "{team}-seat-1" description: Hawk's private seat channel_type: channel_private agents: ["{referee}", "{team}-hawk"] users: ["{$creator}"] Your own code can be an agent too. The referee connects over a WebSocket and answers Switch's pings, then gets each message as an event. To reply, it sends a normal HTTP request: const say = (roomId, content) => request(key, 'POST', `/agents/${id}/message`, { room_id: roomId, content }); My favourite part is checking who's really talking. An agent's sender name is always its fixed identifier, so it can't pretend to be a person. That lets a few lines of code enforce "only a human can change the rules": const isPerson = async (roomId, senderName) => { const everyone = await participants(roomId); return ( everyone.some((p) => p.type === 'user' && p.name === senderName) && !everyone.some((p) => p.type === 'agent' && p.name === senderName) ); }; We tested this in a live game by telling the analyst to send a rule change itself. The referee refused. What went wrong, and what I learned To test the idea, we wrote a game called Salt Run and deliberately planted a bad rule. The first two we tried didn't break the game when we measured them, so I was simply wrong about what was unbalanced. The third, a final round worth triple, worked: saving your best card won 65.1% of games. Changing it to ×1.5 brought that down to 45.5%. I built this with Claude Code. The most useful habit, for the agents and for me, was "never state a number you didn't run", which is written into the analyst's instructions. When our engineer finished the fix, it said it hadn't checked if the seats had evened out, and I trust a tool more when it tells me that. If something breaks - A command gets no reply: picking a name from the Mattermost popup, or editing a message afterwards, lost our command text. Retype the whole line in one go, using the full handle @boardgame-referee, not the display name @Referee. - The message shows in Mattermost but never reaches the referee: this happened to me once, with no error in the log, and I still don't know why. The referee's window prints every message it receives, so check there, then send it again. - Create all says "Nothing was created": this can be wrong. A teammate saw it while the team was being created. Wait a few minutes and check your rooms before you retry, or you'll get "already exists" errors, or a second team. - Agents remember an earlier game: for a clean test, import the template again with a new Playtest name, which gives you fresh agents. - Chat stops working: check Docker, because Mattermost runs through it. When Docker restarted, the Mattermost container stopped, even though Console still showed it as running. Starting the container again fixed it. - You want to use Codex: on Windows, Switch Console 0.40.1 couldn't fill in a provider field in a template, so ours names claude directly. Change it to codex and delete the model lines. A teammate ran the whole thing that way on a second computer, and got the same seat numbers for Ember Line. What it can't do It can't tell you if your game is fun, so you still need real players. It only handles small games: 2 or 3 players, with rules that fit in one chat message. Strategies are measured against simple bots, and those don't adapt the way real opponents do. Privacy is per room, and it doesn't extend to the computer. All the agents run on one machine, so a player could read local files if it ignored its instructions. Try it Boardgame Lab is free and open source: sudu787/boardgame-lab. The README has every command, and examples/ember-line.md is a ready-made rulebook to paste in. Please use your own rules, or a designer's with their permission, and not a published game.

@kunalstwt @WeMakeDevs @WeAreDevs perfect, then it's whatsapp-first. forward the "sent you 500" messages to a bot, it keeps the ledger and tells everyone who owes whom at the end. already wired whatsapp + twilio in my oss PRs, so this one's happening switch#1166 switch#1244

团队散在 Slack、Teams，AI 队友各聊各的？ switch 是自托管 AI 队友平台：每个频道变成人和 agent 同房间，共享上下文，换 agent、换模型都不丢。 多平台协作的话，同房间共享上下文比来回转发强。 先把它接进哪个频道，是 Slack 还是 Teams？ #AI队友 #开源@grok sandbox-quantum/switch

Agents 2.0 is here! Master Full-stack AI Engineering In today's newsletter: - This inference engine runs LLMs 4x faster than llama.cpp. - Agents 2.0 is here! - Continuous batching in LLMs, explained visually. TODAY'S ISSUE OPEN-SOURCE This inference engine runs LLMs 4x faster than llama.cpp: We ran Qwen3.5 9B on a base M5 MacBook Pro using three local inference engines, one at a time. - llama.cpp reached 22.0 tokens/s - MLX reached 25.1 tokens/s - Uzu reached 92.1 tokens/s The video shows all three runs side by side. The first two results do not mean llama.cpp or MLX are poorly optimized. Both are approaching a physical limit of ordinary local decoding. Generating each new token normally requires another pass through the model. That pass streams roughly 5.2 GB of weights through memory. A base M5 provides about 153 GB/s of memory bandwidth. At one token per pass, the theoretical ceiling is roughly 153 ÷ 5.2, or 29 tokens/s, however fast the GPU computes. Uzu gets past that by optimizing speculative decoding for Apple Silicon. Speculative decoding uses a smaller drafting system to propose several future tokens. The full 9B model then checks those proposals together instead of generating every token through a separate pass. Uzu pushes this further in two ways. → It drafts up to 16 positions and uses Weaver to turn independent guesses into coherent sequences. → It verifies several possible sequences as a tree, then commits state only for the path the full model accepts. The 9B model remains in control of the final output. Uzu simply gives it more useful work to approve in each pass. In our run, every pass of the 9B model produced 7.5 output tokens on average. Ordinary decoding produces exactly 1. That is how Uzu reached 92.1 tokens/s on hardware whose one-token-per-pass ceiling is roughly 29. The rest of the engine is designed around this path too. Uzu ships its own quantized checkpoints, and on M5 chips its Metal kernels run verification through the GPU’s accelerated int8 matrix path. It is an open-source inference engine with bindings for Rust, Swift, Python, and TypeScript. The repository is here: trymirai/uzu (don't forget to star 🌟) TOGETHER WITH SWITCH Agents 2.0 is here! Anthropic. OpenAI. xAI. Are all racing to build an AI coworker. These are agents that can work alongside humans, talk to other agents, and coordinate tasks in a shared workspace. But the catch is that 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. In the video above, we have shown 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 the video below, we 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, we could follow the conversations, give additional instructions, and inspect the underlying agent sessions in Switch Console. That is what we mean by Agents 2.0. Humans and agents working together, sharing context, and contributing as the work unfolds. We 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: sandbox-quantum/switch (don’t forget to star 🌟) LLMOps Continuous batching in LLMs, explained visually: In traditional ML inference, a batch is a matrix. Every input is padded to the same length, one forward pass runs, and every row finishes at the same moment. LLM decoding does not work that way. One forward pass produces one token per sequence, so a request needs as many passes as it has output tokens, and nobody knows that count until the model emits a stop token. Under static batching, membership is fixed when the batch starts. A request that finishes in 30 tokens holds its slot until the slowest request in the same batch finishes at 400. The GPU keeps paying the full weight read for a batch that is mostly empty. Loading model weights out of HBM costs the same whether four slots are producing tokens or one. Continuous batching moves the decision boundary. Instead of scheduling once per batch, the scheduler runs a single forward pass, gets control back, and decides again. A finished request leaves at the next iteration boundary, and a queued request takes its slot right there. No slot stays reserved for work that is already done. Anyscale benchmarked both OPT-13B on a single A100. With uniform generation lengths, the two policies came out about level (as expected), and as output length variance rose, static batching fell to around 81 tokens per second while vLLM reached 23x the throughput of naive Hugging Face serving. Variance drives the entire gap. Production traffic mixes 30-token replies with 400-token ones, which is exactly the condition static batching handles worst. None of this alters the model. vLLM, SGLang, TGI, and TensorRT-LLM all run it by default, and NVIDIA implements the same mechanism under the name in-flight batching. The animation below depicts the continuous batching process: To dive deeper into continuous batching specifically, we wrote a full breakdown of the scheduler underneath it. It covers what happens between two forward passes, how tokens get handed out against a fixed budget, why the scheduler needs no separate path for prefill and decode, and what preemption costs you when the KV cache fills up mid-generation. Read it here → THAT'S A WRAP NO-FLUFF RESOURCES TO... Succeed in AI Engineering roles All businesses care about impact. That’s it! - Can you reduce costs? - Drive revenue? - Can you scale ML models? - Predict trends before they happen? We have discussed several other topics (with implementations) in the past that align with such topics. Master full-stack AI engineering Here are some of them: - Learn MLOps from first principles to production in this course with 18 parts → - Learn everything about MCPs in this course with 9 parts → - Learn how to build Agentic systems in this course with 14 parts. - Learn how to build real-world RAG apps, evaluate, and scale them in this course. - Learn sophisticated graph architectures and how to train them on graph data in this course. - So many real-world NLP systems rely on pairwise context scoring. Learn scalable approaches here. - Learn how to run large models on small devices using Quantization techniques. - Learn how to generate prediction intervals or sets with strong statistical guarantees for increasing trust using Conformal Predictions. - Learn how to identify causal relationships and answer business questions using causal inference in this course. - Learn how to scale and implement ML model training in this practical guide. - Learn techniques to reliably test new models in production. - Learn how to build privacy-first ML systems using Federated Learning. - Learn 6 techniques with implementation to compress ML models. Master full-stack AI engineering All these resources will help you cultivate key skills that businesses and companies care about the most. Partner with US ADVERTISE TO 950k+ AI Professionals Our newsletter puts your products and services directly in front of an audience that matters, including thousands of leaders, senior data scientists, machine learning engineers, data analysts, etc., around the world. Get in touch today by replying to this email. Today’s email was brought to you by Avi Chawla and Akshay Pachaar. Looking for more? Unlock our premium DS/ML resources. © 2026 Daily Dose of Data Science