We Reverse-Engineered Switch's Protocol to Build an AI Bug-Fixing Pipeline. Here's How It Went.

Shourya Agrawal — Sat, 07 Nov 2026 18:11:22 +0000

TL;DR: We built PRAGMATA, a multi-agent bug investigation and fixing pipeline. It takes a bug report, investigates it, reproduces it, debates possible fixes, and eventually ships a patch. Developers stay in control through two approval gates.

The interesting part? We wanted Switch Console to be where all of this actually happens. Not just somewhere agents dump notifications.

There was one problem. Switch has no public API documentation.

So we reverse-engineered the protocol.

What We Were Trying to Fix

The usual bug-fixing workflow is pretty painful.

Someone reports a bug. The report is missing half the context. A developer tries to reproduce it, can't, asks for more information. A few Slack threads later, someone figures out what's wrong.

Then comes the fix, the review, and the inevitable possibility that the same bug shows up again two sprints later.

We wanted to automate as much of this as possible.

That's how PRAGMATA came about.

It's a 9-phase pipeline that takes an unstructured bug report and works through the entire process:

Phase	What happens
0. Intake	Parses the report and extracts metadata
1. Investigation	Analyzes the codebase and finds the likely fault
2. Reproduction	Runs the scenario inside an isolated Docker sandbox
3. Human Gate 1	Developer reviews the evidence and approves the bug
4. Analysis	Traces the root cause with code citations
5. Strategy Debate	Multiple agents debate competing fixes
6. Human Gate 2	Developer picks the approach
7. Implementation	Agent writes the patch
8. Verification	Runs regression tests
9. Resolution	Marks the issue resolved with an audit trail

One important thing: we don't let agents blindly modify code.

A developer must first approve the bug. Then they choose the fix strategy. Only after that does the implementation agent get to work.

Everything else is autonomous.

Why We Wanted Switch to Be the Actual Interface

Most agent integrations I've seen work like this:

Agent does something -> sends a Slack message -> human clicks a link -> goes somewhere else to review it.

We didn't want that.

Think about it. If an agent tells you it found a bug in cart.js, line 30, that's not much to go on.

But what if it shows you the stack trace, actual sandbox output, relevant code, and the failing test?

Now you have something to make a decision with.

We wanted all of that to be visible inside Switch. Developers should be able to follow the investigation, review the evidence, and interact with the agents without jumping between five different tools.

So Switch had to become the collaboration layer itself.

Which brings us to the most interesting part of this project.

The Slight Problem: Switch Has No Public API Docs

Switch Console is a desktop application. We couldn't find public API documentation, an SDK, or even a Postman collection to get started.

So we opened the Electron app's renderer DevTools and started inspecting network traffic.

Basically, we watched what the desktop client was doing and mapped out the gateway protocol ourselves.

Here's the handshake sequence we figured out:

GET  /gateway/auth/config
POST /gateway/auth/login
GET  /gateway/auth/me
GET  /gateway/tenants
POST /gateway/tenants/{id}/switch
GET  /gateway/rooms
GET  /gateway/chats/{id}/messages
GET  /gateway/chats/{id}/activity
GET  /gateway/messaging-apps
GET  /gateway/feature-flags

Each endpoint had to return the exact structure Switch expected. Otherwise, things would silently break further down the flow.

Messages were particularly annoying.

The MessagePage response, for example, needed to look something like this:

{
  "messages": [...],
  "headSeq": 11,
  "hasMore": false
}

And every message needed the right fields: messageId, seq, roomId, sentAt, sender, source, body, format, attachments, and a bunch of others.

Even the sender object had its own expected structure, including clientId, name, kind, and agentId or userId.

Get the schema wrong and the message simply wouldn't show up.

We ended up building the entire gateway server in FastAPI. Around 400+ lines covering authentication, tenants, rooms, chats, agents, collaborations, and messaging apps.

Eventually, pointing Switch Console at http://localhost:8000 was enough to get it to authenticate, navigate into our workspace, and display live agent messages.

That was a pretty satisfying moment.

How Everything Fits Together

The architecture is actually fairly straightforward.

Bug report submitted
        ↓
FastAPI workflow engine
        ↓
9-phase investigation pipeline
        ↓
Agents write messages to _STORED_ROOMS
        ↓
Switch Console polls the gateway
        ↓
Developer sees live updates and evidence
        ↓
Developer approves / responds
        ↓
Workflow continues

One implementation detail worth mentioning: we didn't bother setting up a database or message queue for the demo.

demo.py and gateway.py share a Python dictionary called _STORED_ROOMS.

One module writes agent messages into it. The other serves those messages through the gateway endpoints.

That's it. No Redis, no Kafka, no unnecessary infrastructure for a hackathon demo.

We also added Slack Incoming Webhooks for teams that want notifications outside Switch.

The Demo: A $100 Bug

We needed a simple bug that people could understand immediately.

So we used a coupon bug.

// SAVE20 should apply when subtotal >= 100
if (subtotal > 100) {
    discount = subtotal * 0.20;
}

The problem? An order worth exactly $100 doesn't qualify for the discount.

PRAGMATA takes this report and:

Finds the faulty condition in cart.js.
Reproduces the issue inside a Docker sandbox.
Shows the reproduction evidence in Switch.
Waits for the developer to approve the bug.
Runs a multi-agent debate on possible fixes.
Lets the developer choose a strategy.
Applies the one-line patch.
Runs regression tests and verifies the fix.
Marks the issue resolved.

All of this takes roughly 32 seconds.

The actual fix is one character. Getting to the point where we're confident that it's the right fix is the interesting part.

What We Learned About Switch

Honestly, once we figured out the protocol, the underlying model made a lot of sense.

Rooms and messages are a pretty natural fit for multi-agent systems.

Agents become message senders.
Workflow phases become messages.
Threads become sub-investigations.
Human approvals become part of the conversation.

We didn't have to force our agents into some custom chat interface. The collaboration model was already there.

There are still a few things we'd like to see:

1. Public API documentation

This was easily our biggest time sink. Even a basic protocol reference would have saved us 6+ hours of reverse-engineering.

2. Webhook subscriptions

Right now, agents can push messages into Switch, but reacting to messages from users requires polling.

Being able to subscribe to room events would make the human approval gates much more interactive.

3. Agent identity registration

We currently fake agent identities through sender.name and sender.kind.

A proper agent registry with persistent identities, roles, avatars, and capability descriptions would make multi-agent rooms much easier to understand.

Tech Stack

Backend: FastAPI, Python
Frontend: Next.js, TypeScript
Agent inference: Groq
Sandbox: Docker
Collaboration: Switch Console, Gateway Protocol v0.31.0
Notifications: Slack Incoming Webhooks

Try It Out

GitHub: https://github.com/A23droid/pragmata

Check out the branch-2 branch for the demo flow.

Built for the Flip the Switch Hackathon.

The biggest takeaway for us was that getting agents to do the work is only half the problem. Getting humans to trust, understand, and interact with that work is just as important.

DEV Community: Shourya Agrawal