Experiencing Multi-Agent Workflow

We have all been there. You have a perfectly configured home lab, Mac Mini, Raspberry Pi, Synology NAS, and you want effortless access to it from anywhere. For years, ttyd was my go-to solution. It’s a brilliant tool that shares your terminal over the web using WebSockets and it was fast since it was written in C and its frontend is not polluted with unnecessary fancy features.

But then you run into "The Wall."

Many strict network environments, whether it's a corporate guest network, a restrictive public Wi-Fi, or an aggressive antivirus proxy often drop WebSocket upgrade requests. The connection handshake fails, and your terminal access is dead. For years, I scoured the web for workarounds like "SSH over HTTPS" or "ttyd without WebSockets," but I came up empty.

Recently, however, I solved this "unsolvable" problem not by writing the code myself, but by orchestrating a team of AI agents to do it for me.

The Expensive Failure

My first attempt was a brute-force approach. I fired up Claude Code, pointed it at the ttyd repository, and simply asked it to "refactor this to use pure HTTP."

It was a disaster. I spent five hours babysitting the session, answering endless questions, and watching my credits drain as I upgraded to the expensive "Claude Code Max 20x" plan,. The result? A broken implementation where inputs reached the backend, but the shell refused to respond. I was out of time and patience.

The "Aha!" Moment

The breakthrough came when I discovered VibeTunnel, an open-source project that had successfully implemented a browser-based terminal using Server-Sent Events (SSE) and HTTP, completely bypassing the need for WebSockets.

I gave it a try, and voila ! It was exactly what I was looking for. My longtime problem has been solved. However, this led me to one question:

"What if I somehow tell my claude code agent to look at this project (vibetunnel) and learn from it, how they implemented a working solution and then fix our bug in ttyd about not responding to pty commands"

I first thought adding all vibetunnel project folder under ttyd folder and simply pointing that directory, ask claude to fix bug in ttyd by looking that directory.

However, there should be more sophisticated way of doing this.

Turns out, there was, and it was named as "Multi-Agent Collaboration". Meaning one agent (Agent A) studies VibeTunnel's architecture while the other agent implements and fixes the bugs at project B by asking related questions to Agent A. It was a good chance to experince this concept. Hence, I started digging.

I found that Claude Code actually has a built-in support for creating Subagents. You simply type /agents and then it directs you to create sub agents.

The Solution: A Multi-Agent Workflow

Step 1: The Setup First, I needed both codebases in my workspace. I cloned VibeTunnel locally to serve as the "textbook" for the AI.

# In the ttyd repository
/add-dir /path/to/vibetunnel

This command gave Claude Code access to the reference material.

Step 2: creating the "Reference Expert" I didn't want the AI to hallucinate or guess. I used Claude's /agents command to create a specialized subagent,. I defined its role strictly as a Read-Only Expert:

Role: Read-only expert on the reference repository (/path/to/vibetunnel). Instructions: Invoke when implementing features that need to mirror patterns, understand architecture, or reference existing implementations from the reference codebase.

This ensured that one part of the AI "brain" was focused on understanding how VibeTunnel implemented web based terminal without employing a persistent connection (websockets).

Step 3: The "Ralph Wiggum" Loop For the actual coding, I used the Ralph Wiggum plugin. This tool turns a single prompt into a persistent loop, allowing the agent to try, fail, fix, and retry until a specific success criteria is met.

I issued this command to kick off the process:

/ralph-loop "Fix the HTTP response issue. You can ask the reference-expert agent
about how VibeTunnel implemented HTTP methods instead of WebSockets.
Run tests to verify the bash shell gives a proper response." \
--completion-promise "DONE" \
--max-iterations 10

The Magic

This was the game-changer. I watched the logs as my main agent paused, invoked the reference-expert subagent, and asked: "How does VibeTunnel handle terminal output without WebSockets?".

The expert agent analyzed the VibeTunnel repo, explained its architecture and related implementation details, and passed that knowledge back. The main agent then applied that logic to ttyd.

I didn't have to intervene. I just watched them "vibe" until the terminal finally printed: DONE.

              ┌──────────────────────────────┐
              │          You (human)         │
              │  goal: "ttyd over pure HTTP" │
              └──────────────┬───────────────┘
                             │
                             │  /add-dir /path/to/vibetunnel
                             v
  ┌─────────────────────────────────────────────────────────┐
  │                  Claude Code Workspace                  │
  │                                                         │
  │   ┌──────────────────────┐        ┌──────────────────┐  │
  │   │   Project A: ttyd    │        │ Project B:       │  │
  │   │ (target to modify)   │        │ VibeTunnel       │  │
  │   └──────────┬───────────┘        │ (reference only) │  │
  │              │                    └─────────┬────────┘  │
  └──────────────┼──────────────────────────────┼───────────┘
                 │                              │
                 │ uses                         │ studied by
                 v                              v
       ┌──────────────────┐            ┌─────────────────────────┐
       │ Main Agent       │            │ Subagent: Reference-    │
       │ (implements)     │<───────────│ Expert (READ-ONLY)      │
       └───────┬──────────┘   Q/A      │ "How does VibeTunnel do │
               │                       │  SSE + HTTP IO?"        │
               │                       └─────────────────────────┘
               │
/ralph-loop     │  iterate: try → test → fix → retry
(success="DONE")v
        ┌────────────────────────────────────────────────┐
        │ Ralph Wiggum Loop / Executor                   │
        │  - runs tests / repro steps                    │
        │  - applies code edits in ttyd                  │
        │  - stops when criteria met ("DONE")            │
        └───────────────────┬────────────────────────────┘
                            │
                            v
                  ┌──────────────────────────┐
                  │ Patched ttyd (HTTP/SSE)  │
                  │ verified by tests        │
                  └──────────────────────────┘

Final Thoughts

I fired up the modified ttyd, opened my browser, and it worked perfectly, pure HTTP, no WebSockets, and fully accessible through even the strictest firewalls.

My first attempt was like hiring a junior developer and telling them to "figure it out." My second attempt was like hiring that same junior developer, but seating them next to a Senior Architect who had already built the system.

Going from a frustrating, expensive failure to a hands-off success just by changing the architecture was a huge lesson. I truly believe these multi-agent workflows are the future of software development.