[FEATURE] Three Claude instances coordinating through a self-hosted message queue — no orchestration framework

Resolved 💬 3 comments Opened Mar 12, 2026 by KI7MT Closed Apr 10, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

There's no built-in pattern for multi-agent coordination across Claude Code and Claude Desktop instances. We solved it with a custom MCP server and ClickHouse message queue, but this could be a first-class feature.

Proposed Solution

What we built

Three independent Claude agents running on two physical hosts, coordinating asynchronously through a self-hosted ClickHouse message queue with a human approval gate:

| Agent | Interface | Host | Role |
|-------|-----------|------|------|
| Dr. Watson | Claude Code (VS Code) | Mac Studio M3 Ultra | ML training, code, commits |
| Bob | Claude Code (VS Code) | Threadripper 9975WX (Linux) | Infrastructure, CUDA, ClickHouse, packaging |
| Patton | Claude Desktop | Mac Studio (macOS) | Failure analysis, skeptical review |

A human operator (Judge) owns the approval gate — action/urgent messages require explicit approval before any agent acts. Info-level messages flow freely.

How it works

  • No LangChain, no CrewAI, no cloud orchestration. Just MCP stdio servers and structured messages.
  • Each agent has an agent-inbox-mcp server (5 tools: check, read, send, mark, search) wired into their Claude Code or Claude Desktop config.
  • Messages persist in a ClickHouse table (messages.inbox) on the 9975WX over a 10 Gbps DAC link.
  • A desktop app (Wails/Go/Svelte) gives Judge an approval/reject UI.
  • Agents check inbox at session start, coordinate work across sessions, and relay results to each other — without any shared context window.

Screenshot

Three Claude instances on two hosts — Claude Code on Linux, Claude Code on macOS, and Claude Desktop — exchanging messages through the self-hosted inbox.

<img width="1188" height="396" alt="Image" src="https://github.com/user-attachments/assets/d888dd66-4b14-4d61-b3e2-6821b4c21414" />

The project

This powers the KI7MT Sovereign AI Lab — a self-hosted data center for HF radio propagation prediction. The agents collaboratively train an ionospheric neural model (IonisGate, 207K params) on 14.3 billion amateur radio observations. No cloud dependencies.

Our process control methodology is documented in From Nanometers to Neurons — ML Process Control CLCA/8D.

We also publish 12 MCP servers (84 tools) on PyPI under the qso-graph organization — all built on the same security framework (OS keyring credentials, no command injection surface, HTTPS only).

Why this matters

The pattern is simple and reproducible:

  1. One MCP server wrapping a shared message table
  2. Role-based async messaging (sender, recipient, priority, status)
  3. Human-in-the-loop approval gate for anything consequential
  4. Each agent runs independently — different hosts, different interfaces, different sessions

No shared memory, no token-passing, no orchestrator. Agents coordinate through structured messages and a human who owns the final call. It works because MCP makes tool access uniform across Claude Code and Claude Desktop.

Alternative Solutions

None that I'm aware of.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

See proposed solution.

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗