How I Contributed 5 Integrations to Switch During the Flip the Switch Hackathon

Open source has always been one of my favorite ways to learn software engineering. You get to work with real codebases, understand how existing systems work, solve problems, receive feedback from maintainers, and sometimes discover challenges you would never encounter while building a personal project. Recently, I started contributing to Switch, an open-source project that connects AI coding agents with messaging platforms. While exploring the repository, I noticed opportunities to extend its support for both messaging platforms and AI coding agents. That became the focus of my work during the Flip the Switch Hackathon by WeMakeDevs. Instead of building a completely separate application, I decided to contribute directly to Switch. So far, I have submitted five pull requests covering three messaging integrations and two AI agent providers. Here is what I worked on. First, what is Switch? Switch makes it possible to connect AI agents with messaging platforms so developers and teams can interact with their agents through familiar communication tools. Think about having an AI coding agent available through your team's messaging environment instead of constantly switching between different applications. That is one of the interesting ideas behind Switch. While exploring the project, I focused on two areas where I could contribute: Adding more messaging platforms. Supporting additional AI coding agents. 1. Bringing Signal into Switch My first major messaging contribution was adding Signal support. Signal is known for its focus on private communication, and I wanted to make it possible to connect Signal conversations with Switch agents. There was one interesting challenge: Signal does not provide an official bot API. After researching the available options, I used signal-cli as the communication layer. The implementation connects Switch to the signal-cli HTTP daemon using JSON-RPC 2.0 and Server-Sent Events (SSE). Some of the features I worked on include: Direct messages. Group conversations. Signal Note to Self. Quote-based replies. Activity indicators and typing notifications. Credential verification. One particularly interesting part was handling multi-instance deployments. During code review, I received feedback about quote replies relying on process-local state. That approach could cause problems when a connection moved between server instances. I improved the implementation with a bounded LRU cache and changed quote-reply handling so it can work across instance handovers without depending on a local cache entry. I also updated the daemon deployment documentation to support a shared internal endpoint. Pull Request: https://github.com/sandbox-quantum/switch/pull/1041 Original Issue: https://github.com/sandbox-quantum/switch/issues/792 The submitted PR reports 50 passing tests, along with successful Ruff and strict Mypy checks. 2. Adding Cisco Webex support The next contribution was Cisco Webex. Webex is widely used for workplace communication, and adding it to Switch creates another way for teams to interact with their AI agents. For this integration, I implemented a webhook-based messaging adapter. The adapter handles: One-to-one direct conversations. Group spaces. Threaded replies. Message chunking. File attachments. Interactive approval card actions. Webhook signature verification. Security was an important part of this implementation. I worked on HMAC signature verification, replay protection, and safer attachment downloading with IP validation and download limits. Another small fix involved Windows compatibility. I updated frontmatter matching to support both Unix and Windows line endings. The implementation also includes a dedicated test suite and a live Webex bot smoke test. Pull Request: https://github.com/sandbox-quantum/switch/pull/1027 Original Issue: https://github.com/sandbox-quantum/switch/issues/795 The submitted PR reports 25 passing tests. 3. Connecting Twilio SMS with Switch The third messaging integration was Twilio SMS. I wanted to explore a slightly different type of communication platform. Unlike chat applications, SMS has some practical limitations that need to be considered when building an integration. For example, message length affects the number of SMS segments, and sending too many segments can increase carrier costs. The adapter includes: Incoming SMS through Twilio webhooks. Outgoing messages through the Twilio REST API. GSM-7 and UCS-2 message segmentation. Markdown-to-SMS text handling. Twilio webhook signature verification. Phone number allow-listing. Attachment delivery through media URLs. One important design decision was requiring an explicit phone-number allow-list. This prevents unauthorized senders from triggering Switch workflows and helps avoid unnecessary downstream execution and messaging costs. I also added tests covering message segmentation, authentication, webhook handling, and outbound delivery. For validation, I tested the integration with a live Twilio setup, including an outbound SMS delivery and rejection of an unauthorized sender. Pull Request: https://github.com/sandbox-quantum/switch/pull/1049 Original Issue: https://github.com/sandbox-quantum/switch/issues/796 The submitted PR reports 27 passing tests. 4. Adding Factory Droid as an AI agent provider After working on messaging integrations, I moved to the agent-provider side of Switch. The first provider I worked on was Factory Droid. The goal was to make Factory Droid available as another coding agent that users can connect through Switch. The implementation uses the Agent Client Protocol (ACP). Some of the work included: Factory Droid CLI integration. ACP-based communication. Agent session creation. Model selection. Tool permission handling. CLI detection. Provider registration in Switch Console and Switch Core. I also worked on the permission flow so users can interact with agent tool permissions rather than having every action automatically approved. The integration was tested through unit tests and manual checks covering CLI detection, session creation, in-room communication, and permission handling. Pull Request: https://github.com/sandbox-quantum/switch/pull/1677 Original Issue: https://github.com/sandbox-quantum/switch/issues/783 The submitted PR reports 8 passing unit tests. 5. Adding Grok Build as an ACP provider My fifth contribution was adding Grok Build as an agent provider. Like Factory Droid, this integration uses ACP. Instead of creating an entirely separate communication mechanism, I used Switch's generic ACP adapter approach. The implementation includes: Grok Build provider registration. CLI launch configuration. XAI_API_KEY environment variable pass-through. Authentication detection through the ACP handshake. Runtime-mode selection based on modes advertised by ACP. Resumable sessions. Console plugin metadata and installation information. Unit tests and a real-CLI conformance probe. One important detail: the real Grok CLI was not installed in my development environment, so the live CLI conformance scenarios remain pending. I was able to validate the focused unit tests, type checks, builds, linting, and formatting. Pull Request: https://github.com/sandbox-quantum/switch/pull/1708 Original Issue: https://github.com/sandbox-quantum/switch/issues/775 The focused unit tests report 9 passing tests. What I learned from working on these integrations Working on five different integrations gave me an opportunity to explore several areas of software engineering. A few lessons stood out. 1. Every platform has its own challenges A Signal integration is very different from a Webex or Twilio integration. Each platform has its own authentication process, communication model, message format, and limitations. Trying to force every platform into exactly the same behavior does not always work. Understanding those differences is important. 2. Working code is not always production-ready code One of the biggest lessons came from the Signal review. Something that works perfectly on a local machine may behave differently when an application runs across multiple instances. That feedback helped me think more carefully about shared state, connection handling, and distributed deployments. 3. Testing makes a difference I spent time writing tests for authentication, message handling, edge cases, and provider behavior. The submitted PRs report the following focused test results: Contribution Reported passing tests Signal 50 Cisco Webex 25 Twilio SMS 27 Factory Droid 8 Grok Build 9 These are the test results reported in the respective pull requests, not a single combined test run. 4. Code review is part of learning I also learned that contributing to open source is not just about opening a pull request. Maintainer feedback can reveal architectural problems that are easy to miss when working independently. Understanding that feedback and improving the implementation is an important part of the process. My contributions at a glance Here are all five pull requests: Messaging platforms Signal messaging adapter – #1041 Cisco Webex adapter – #1027 Twilio SMS adapter – #1049 AI agent providers Factory Droid ACP provider – #1677 Grok Build ACP provider – #1708 All five pull requests are currently submitted for review. You can also find my contributions here: https://github.com/sandbox-quantum/switch/pulls/Darshan3690 Final thoughts This hackathon has been a great opportunity to contribute to a real open-source project. I started by exploring the Switch codebase and looking for useful integrations. That led me to work with messaging protocols, webhooks, external APIs, ACP providers, authentication, testing, and distributed application behavior. The most valuable part was not simply the number of pull requests. It was understanding an existing architecture, identifying missing integrations, implementing them, testing different scenarios, and improving the code based on feedback. A big thanks to the Switch maintainers and the WeMakeDevs team for creating an opportunity for developers to work on real engineering problems. I am looking forward to continuing my contributions and learning more from the open-source community. Building is important. But learning how to build with other developers is what makes open source special. Useful links Switch GitHub Repository My Switch Pull Requests Flip the Switch Hackathon WeMakeDevs