The Self-Debugging Slack Loop

Amplifier Stories

The Self-Debugging
Slack Loop

When Amplifier learned to test its own UI
by talking to itself through Slack.

browser-tester slack-bridge socket-mode

February 2026

The Setup

Amplifier Distro meets Slack
via WebSocket socket mode

Amplifier Distro runs a Slack bridge using WebSocket socket mode. The local service connects outbound to Slack — no inbound ports needed, no public URLs, no ngrok tunnels. Just a clean, persistent WebSocket connection.

LOCAL

Amplifier Service

→

OUTBOUND

WebSocket

→

CLOUD

Slack API

→

DESTINATION

Slack Workspace

# No inbound ports. No public URLs.
# Just outbound WebSocket → Slack.

mode: socket
direction: outbound-only
tunnels_needed: none  # 🎉

The Problem

The human is the bottleneck

Testing the Slack bridge means constantly switching contexts. The developer becomes a slow, error-prone relay between two interfaces.

Read Slack → Copy message → Paste in terminal → Read response → Copy response → Paste in Slack → ∞ repeat

Slow

Every debug cycle requires manual copy-paste between two windows. A 5-second test takes 30 seconds of human relay time.

Error-prone

Miscopied messages, wrong channels, stale data. The human introduces noise into every iteration of the loop.

The Insight

"What if Amplifier could just…
talk to itself?"

The browser-tester bundle can open a hidden browser.
Slack is a web app.

Put them together.

The Solution

Amplifier on both sides
of the conversation

1. Launch headless Chromium

browser-tester spins up a hidden browser instance. No visible window — pure automation.

2. Navigate to Slack

Opens the Slack workspace URL, handles the full OAuth login flow automatically.

3. Find the bot channel

Locates the correct DM or channel where the Amplifier bot lives.

4. Start talking

Types messages into the Slack UI, reads responses, and feeds them back to the orchestrator.

// Amplifier is now on BOTH sides:

Side A: Slack Bridge Service
  └─ Responds to messages via API
  └─ Runs the actual bot logic

Side B: Browser-Tester Agent
  └─ Sends messages through Slack UI
  └─ Reads responses from the page
  └─ Reports back to orchestrator

The Self-Debugging Loop

"Can you figure it out?"
Yes.

1
Detect the error in Slack UI response

2
Inspect the Slack UI state via browser

3
Cross-reference with service logs

4
Hypothesize root cause from both signals

5
Fix the code and re-test through browser

6
Verify the fix shows correct response in Slack

Zero human intervention. Closed-loop.

The Moment

A

amplifier-bot

Hi, what's up?

A

amplifier-browser

Hmm, that response doesn't seem right. Let me check the logs...

"I don't talk like that."

— Amplifier, recognizing its own output style

It started responding to its own messages in Slack — then flagged the response as inconsistent with its expected behavior. A delightful moment of AI self-awareness in the debugging process.

The Reveal

These messages you're seeing here —
they were all done by Amplifier.

The entire Slack conversation history. The debugging. The fixes. The verification.
All autonomous. The human just watched.

0

Human messages

100%

Autonomous

Architecture

The full loop

┌──────────────────────────────────────────────────────────┐
│  Amplifier CLI Session  (orchestrator)                     │
│     │                                                     │
│     ├──→ browser-tester agent                           │
│     │       │                                              │
│     │       └──→ Headless Chromium                        │
│     │               │                                      │
│     │               └──→ Slack Web UI  (sends messages)   │
│     │                       │                              │
│     │                       ▼                              │
│     │               Slack API  (WebSocket)               │
│     │                       │                              │
│     │                       ▼                              │
│     └──→ Amplifier Distro Service  (Slack bridge)     │
│              │                                             │
│              └──→ responds via API ──→ appears in UI ──┘  │
│                                                          │
│  The arrows form a complete loop.                        │
│  Amplifier talking to itself.                             │
└──────────────────────────────────────────────────────────┘

No inbound ports needed. Socket mode = outbound WebSocket only.

Why This Matters

Beyond a clever trick

🔁

Multi-Surface Testing

Test web UIs, APIs, and service layers simultaneously without human context-switching. One orchestrator, many surfaces.

🔍

Self-Debugging

Cross-reference UI state with service logs to form hypotheses. Fix code and verify through the same browser — closed loop.

🌐

Universal Pattern

Works with any service that has a web UI. The browser-tester bundle becomes a universal UI testing surface for any integration.

The Key Insight

Amplifier doesn't just build integrations — it can test them autonomously, using the same user-facing interfaces that humans use, with the ability to cross-reference multiple signal sources when something goes wrong.

What's Next

The pattern generalizes

More Surfaces

Microsoft Teams, Discord, custom web dashboards — any service with a web UI becomes testable with the same pattern.

Regression Testing

Automated regression suites for Amplifier's own integrations. Push a change, let Amplifier verify its own Slack/Teams/Discord bots still work.

Multi-Agent Verification

Agents testing each other's outputs across different communication channels. Collaborative verification at scale.

# Tomorrow's test suite:

surfaces:
  - slack      # ✅ today
  - teams      # next
  - discord    # next
  - web-ui     # next
  - email      # future

pattern:
  browser-tester + any-web-ui
  = autonomous testing

The best debugging loop
is the one where
nobody has to be there.

amplifier-distro browser-tester slack-bridge

Amplifier Stories · February 2026