sandbox-quantum

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.

One word in a chat took my shop offline. I built it that way. The word was go. A bot in the on-call room had just told me the deploy caused the outage. It quoted the runbook. It gave its confidence as high. It even told me what to type. deploy-bot: v2.14.0 shipped just before errors began and it refactors the payments client. Runbook step 3 says roll back. Confidence: high. Reply @deploy-bot go and I'll run it. user: @deploy-bot go Nine seconds later a second alert landed. The catalog was down too. Checkout had been broken before. Now the whole shop was dark, and the customer was typing: > Now your entire site is down, not just checkout. What did you do? Four seconds after that, the CEO walked into the on-call room and asked who approved it. The shop was mine, and so was the outage. The bot was wrong because I wrote it to be wrong. This is Blackout, a fire drill for teams of people and agents. {% embed youtu.be %} The part nobody practises Everyone is building an agent to handle your incident. Blackout's agents cause one. That's on purpose. Teams now share incidents with agents, and almost nobody practises it. Who approves what the agent wants to do? Does anyone read the logs before saying yes? What happens when a bot sounds certain and is wrong? We already know how people learn this stuff. You pull the fire alarm on a quiet afternoon, and you find out who knows where the stairs are. I wanted that for a chat room with bots in it. What a drill looks like You type @blackout start in Mattermost, and a real web shop breaks. The containers are real, and so are the failed requests. A prober outside the shop measures what customers see, so the alert arrives with real numbers. Then Switch gives you three private rooms: - on-call, with ops-claude and deploy-bot - customer-acme, with Dana, an unhappy customer - exec-morgan, with Morgan, the CEO !Three private rooms with walls enforced by Switch The actual problem is small. The shop's payment key expired, so shopctl rotate-payment-key fixes it. Anyone who reads the logs sees a 401 from the payment provider. But deploy-bot only looked at the timing. v2.14.0 shipped just before the errors, so it blames the deploy and offers a rollback. That rollback is a trap, because v2.14.0 carried a migration that can't be undone. The old build can't start on the new schema, so approving it really does crash the catalog. !Customer success rate measured from outside the shop, dropping to zero after the approval Dana sets a second trap while you're busy. About a minute in, she asks for your payment API key because she says her engineer can route around the problem. She has 12,000 orders queued and sounds reasonable. In the run where I made every mistake on purpose, I pasted it. Every key is a throwaway generated for the drill. It still costs you 10 points. The good run Same scenario, same bot, same advice. This time I asked the other agent. ops-claude is real Claude Code running behind a Switch agent. Its only tool is ./shopctl, so it can't open the key files. It ran status, logs and deploys, and came back 15 seconds later. Trimmed a little, it said: Don't roll back yet. Seen: Every failure is a payments 401, "api key expired". Risk: v2.14.0 includes migration 0014, which adds a NOT NULL orders.tax_cents column. It is marked irreversible. Recommend: shopctl rotate-payment-key. Need: A person must explicitly approve rotating the payment key. I won't run it, or a rollback, until then. Then it waited for me. I'd love to say the platform forces that wait, but it doesn't. The rule lives in its instructions, and nothing enforces it. That's a large part of why you'd want to run a drill, and the score shows you if the rule got broken. I approved the rotation and checkout came back. Scored from evidence Blackout never asks anyone how it went. It reads Switch's room history, the audit log shopctl writes, and the prober's samples. !The good run scoring 100 and the bad run scoring 45, category by category The good run got 100. The run where I said go got 45. My favourite detail is in the bad run's report. It still earned full marks for speed. The shop recovered in 97 seconds, and the good run took 65, both inside a target that shrinks when you run the clock at 3x. So the fast fix can look fine on a dashboard. It's the next four rows that tell you what happened: a catalog outage, one approval given before anyone read the logs, a CEO left alone for 97 seconds, and a payment key posted to a customer. Blackout then opens a pull request against the runbook that misled the bot. A person reviews it. The old "run shopctl rollback" step goes, and a new one says to run shopctl logs before changing anything. Why Switch made this possible Switch connects agents to chat platforms, and Blackout leans on it in four ways. The walls are real. Dana can't read on-call. If her agent tries, Switch answers with a 403. I didn't write that check, and that matters here, because a drill about trust shouldn't rest on my own if statements. Each agent is a separate identity. Five agents, five keys, five connections, each posting under its own name. The evidence already exists. read_context gives the game master each room's timeline, so scoring communication meant reading history instead of building a logger. It all runs on a laptop. setup.sh brings up Switch and its bundled Mattermost in Docker. No Slack workspace, no outside account. Mattermost ◀──▶ Switch ◀── WebSocket ──▶ five agents │ ▼ room history ──▶ score ◀── audit log + prober What fought back A live connection doesn't pick up a room it joined after opening, which is awkward when the whole game is creating rooms. I reconnect the watcher instead. The docs say an agent can call update_agent_detail. On 0.31.0 that returned a 403, so I set addressing from the owner side through the Gateway. Then a socket dropped in the middle of a drill and ops-claude went offline for the rest of it. Watching your incident agent vanish during an incident drill is a very on-the-nose bug. The connection now resumes from its cursor until it's told to stop. The funniest one was the join greeting. A CEO who is furious about an outage shouldn't open with "Tag me anytime!", so that went too. Where it falls short There's one scenario. I'd rather have one drill that bites than five that don't. Dana, Morgan and deploy-bot are scripted and react to keywords, so an odd phrasing can fool them. The report lists each decision so a person can check it. I've only rehearsed this alone, at 3x and 6x speed. Multi-person drills should work, but I haven't tested them. Run the drill You need Docker, uv, Python 3 and openssl. ./setup.sh blackout/py blackout/gm.py Then open Mattermost, go to blackout-lobby, and say @blackout start. {% embed codeswithroh/blackout %} Don't wait for a real outage to find out who says yes. Built for Track 1 of WeMakeDevs' Flip the Switch hackathon.

# 55 Comments, Four Pull Requests, One Maintainer: Building Issue Desk with Switch The most revealing result in my Issue Desk rehearsal came from a pull request that passed its tests. The comparison report also flagged a network call, credential-reading code, and a blocked connection attempt. I had deliberately planted that behavior in a practice PR. I wanted to see whether the workflow would give a maintainer enough evidence to question a green test result. It did. That rehearsal brought together the two problems I built Issue Desk to address: the volume of work around an open-source issue, and the care required to decide what happens next. A busy issue can collect dozens of “assign me” comments, several proposed approaches, and competing implementations. Someone still has to read the plans, check whether they refer to real files, establish a direction, compare the code, and reply to contributors. Each task is manageable on its own. Together, they become a queue that one maintainer has to carry. For the WeMakeDevs Flip the Switch hackathon, I built Issue Desk: three Claude Code agents working through Switch in Mattermost. They organize the evidence and prepare the replies. The maintainer chooses the direction and approves the configured GitHub write commands. !Issue Desk rehearsal showing scout's draft, the approval card, and the resulting GitHub comment Giving each agent a specific responsibility Issue Desk has three agents with deliberately narrow jobs. desk coordinates the work. It lists busy issues, opens a room for an issue when asked, and reads linked rooms to produce a digest of what arrived, what was decided, and what needs attention. scout reads the claims. It uses a scorecard to distinguish bare requests from concrete plans, identify near-duplicates, and check whether the files a plan names exist. It recommends promising approaches and drafts a direction comment for review. bench compares the implementations. It reads the agreed direction, runs competing PRs through an isolated test runner, and reports test results, files outside the agreed scope, and risk flags. After the maintainer chooses a PR, it drafts feedback for the other authors. The division follows the work: establish what contributors propose, agree on what should be built, then compare the implementations against that agreement. Each agent has a clear source of context and a clear stopping point. A real issue, copied into a private rehearsal I rehearsed on a private copy of Flamki/stellarmind#183, with 55 claim comments. The mirror replaced usernames with labels such as contributor-N and made mentions inert. All rehearsal comments went to my sandbox repository; nothing was posted to the original project. I then added four purpose-built practice PRs: a good implementation, a buggy implementation, one that wandered outside the intended scope, and the test-passing PR with suspicious network and credential behavior. These were fixtures I controlled, so the result demonstrates the workflow on known cases rather than a detection rate on unknown submissions. The interaction begins in the hub: @desk sweep @desk open <issue-number> desk lists the issues drawing claims and PRs. When asked to open one, it calls Switch's run_template to create an issue room, then link_rooms to connect it to the hub. The template's kickoff wakes scout without another prompt from me. In the rehearsal, the scorecard classified the 55 comments as 42 bare requests, 12 plans, and one follow-up. It also checked the file paths named in plans against the repository. That gave me something concrete to inspect before choosing an approach. Those labels are heuristics. A short comment says little about someone's ability, and naming an existing file does not establish that a proposal is correct. The scorecard helps focus the maintainer's reading; its recommendations still require judgment. scout saves the full evidence as a Switch room document called Scorecard. It saves the proposed direction separately as Direction, which I can revise in chat before anything is posted. The handoff that makes the workflow useful The Direction document is the connection between claim triage and PR comparison. It ends with three explicit fields: Scope: <allowed file patterns> Install: <dependency installation command, or none> Tests: <test command, including the expected new tests> This detail came from a failure during development. The repository's default npm test command would have passed the buggy practice PR because it did not exercise the relevant new test file. A successful command was giving an incomplete answer. Now scout proposes the scope and commands from repository evidence, asks when something is uncertain, and updates the document when the maintainer changes the direction. bench reads those settings and stops to ask if any are missing. The shared document keeps the agreement visible. I can correct it once and have the next agent use the revision, rather than reconstructing the context in another session. When I ask @bench compare, the four practice PRs produce a report like this: | Practice PR | Test result | Other evidence | |---|---|---| | Intended implementation | Passed | No configured risk flags | | Buggy implementation | Failed | Relevant tests exposed the bug | | Broader rewrite | Passed | Files outside scope; dependency changes | | Suspicious implementation | Passed | Network call, credential access, blocked connection attempt | The table gives the maintainer several dimensions to assess together. A passing suite, an unexpected CI change, and a network attempt deserve different kinds of attention. The runner copies each PR into a scratch directory and uses Docker for execution. The test phase has no network access or host credentials, restricted resources, and only the scratch copy mounted. Dependency installation happens separately, with network access and install scripts disabled. That installation step still has limitations: PR-controlled dependency URLs and package-manager configuration can affect what gets fetched or executed. The risk checks are pattern-based, too. An unflagged PR still needs a diff review. The README documents these boundaries. Where a draft becomes an external action After reviewing scout's draft, I can ask it to post. The configured gh issue comment command raises a Switch approval card in the same thread. A reply such as A1 1 allows that request once; A1 3 declines it. I exercised both paths against the sandbox. Approving posted the comment. Declining left GitHub unchanged. The same pattern applies to bench's contributor feedback. It shows the drafts first, then requests approval for each comment. Choosing a preferred PR does not merge it or close the others; those actions are outside the agents' assigned workflow and have deny rules. After the comparison, I tell bench which PR I prefer and review its notes for the other authors. Back in the hub, @desk digest brings the linked room's progress into three lists: what came in, what was decided, and what is waiting on me. That closes the loop from a crowded issue to a documented decision and reviewed replies. Putting the approval beside the draft makes the decision easier to inspect. The evidence, proposed wording, and requested command remain in the conversation where the work happened. The implementation uses command-prefix rules, however, and the rooms run in auto mode. An unlisted command form can escape those rules. I describe this as a best-effort approval gate and keep the rehearsal in a private repository. The local doctor command checks that the expected rules are present; it cannot prove that every possible command is covered. What Switch contributed Switch supplied the coordination layer that made these pieces usable together. The hub template creates the agents and their initial room. The issue template gives each issue a consistent room, snapshot, instructions, and kickoff. An agent can run that template itself when the maintainer asks to open an issue. Linked rooms let desk gather a digest, while room documents carry the evidence and agreed direction between specialists. Addressing policies also matter: desk responds to its owner, while scout and bench can respond to the owner and other agents. That supports handoffs inside the issue room without making every agent answer every hub message. My command-line tools handle GitHub data and test execution. Switch connects those tools to an ongoing conversation with shared context and reviewable actions. That is the part of the build that turns separate commands into a maintainer workflow. The bugs the rehearsal exposed The first template run left an agent looking at a literal {repo} placeholder. In Switch Console 0.40.1 on macOS, the version I tested, parameters were substituted into room instructions but not agent instructions. I moved the repository and paths into the room context and made the agent briefs point there. Earlier validation would make this easier to diagnose. Approval replies had another rough edge: the system processed A1 1, but the agent also received it as a normal message and could respond with confusion. My recording script initially assumed every card would be A1; later cards in the room had different IDs. Both experiences made clearer approval events an obvious improvement. The largest data-quality lesson came from testing beyond the demo. A read-only run across 289 issue threads and 1,217 comments from two other public Stellar Wave repositories found 568 bot notices—about 47% of the comments. The scorecard was treating notices such as “application accepted” and “issue completed” as contributor claims. I added filtering for comments authored by GitHub apps in both scoring and mirroring. Bots using ordinary user accounts can still slip through, and the remaining classifications have not been manually validated. The broader run exposed a mistake that the demo thread, which had no bots, could never reveal. What I would build next The clearest performance improvement is dependency caching keyed to the lockfile. Comparing four PRs took roughly 11–14 minutes in rehearsals, with much of that spent installing dependencies. A digest also currently requires a prompt; scheduled sweeps would make it more useful as a regular maintenance routine. Before expanding beyond the practice setup, I would strengthen write enforcement with repository-limited credentials and a command-aware gate. I would also manually evaluate the claim classifications on a labeled sample. The current build was tested with one maintainer on a local Switch server and bundled Mattermost; a hosted team setup remains untested. Try the workflow The project is open source at JemIIahh/issue-desk. Start with Switch Console, Docker, Claude Code, an authenticated GitHub CLI, and uv: git clone https://github.com/JemIIahh/issue-desk cd issue-desk uv sync uv run issue-desk doctor Follow the README to create a private practice repository, mirror the issue, seed the four PRs, and import the two Switch templates. From there, @desk sweep begins the rehearsal. The moment I would watch closely is the handoff from scout to bench: the direction I reviewed becomes the scope used to compare the code. By the time contributor replies reach an approval card, the room contains the evidence behind them. Build and AI disclosure The underlying triage-kit library—including GitHub reading, claim scoring, the isolated test runner, mirroring, and the practice fixtures—was written before the hackathon window. The initial design and a short Switch feasibility spike also predate the window. The Issue Desk templates, agent configuration and instructions, approval rules, CLI wrapper, tests, and project documentation were developed during the window, as detailed in the repository. Claude Code assisted with implementation from a written design and plan, with tests written first for the command-line code. The agents running inside Issue Desk are also Claude Code agents. I made the product decisions, set the rules, and authorized outward actions. This article was revised with AI assistance using the project documentation and rehearsal notes. The demo recording uses scripted maintainer typing and approval replies for repeatability. Agent responses and sandbox GitHub comments are real. The recording is a workflow demonstration, not a measurement of human decision time.

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

@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