Why Memdoor Runs Agents as Daemons: Reproducing Cross-Agent Diamond Communication Locally

When running multiple agents simultaneously, the first problem you hit is communication. If agents call each other directly, the call graph becomes a web, and if one responds slowly, everything stops. guregodevo released memdoor on October 31. A tool that creates a daemon for relaying messages between agents, as a CLI binary without Docker or Python. This article is a record of reading the original text and repository documentation, then reproducing the daemon relay structure with a small Node.js example. We did not build memdoor itself or connect models to run it.

What "a binary, no Docker, no Python" means

The original text introduces memdoor as a "daemon agents CLI binary, multi-agent harness." It does not isolate in Docker containers, nor does it depend on a Python runtime. Instead, it runs a daemon as a single executable file, and agents communicate by sending messages to and receiving from that daemon.

Image: Screenshot from guregodevo/memdoor official repository.

This design means two things. First, fewer environment dependencies. The daemon can run on servers or embedded devices without Python installed. Second, agents only need to know the daemon, so call relationships change from a web to a star topology. Instead of N agents making N² calls to each other, all agents send to one place—the daemon.

Why message relay is necessary

Direct agent-to-agent calls create three problems.

First, connectivity management. When agent A calls B, A must know B's address, and if B goes down, A also fails. With a daemon, agents only need to know one address, and the daemon manages other agents' states.

Second, message loss. Direct calls easily disappear due to network errors or timeouts. If the daemon stores messages in a queue, agents can receive previous messages when they reconnect.

Third, observation points. Since all messages pass through the daemon, logging, applying policies, and debugging become easier.

A small example reproduced in Node.js

CodeBridge implemented a small daemon relay example in Node.js. This is not a reproduction of memdoor's actual implementation, but only shows the core principle of daemon relay.

import { spawn } from "node:child_process";
import net from "node:net";

class MessageDaemon {
  constructor(port) {
    this.port = port;
    this.clients = new Map();
    this.queue = [];
  }

  async start() {
    const server = net.createServer((socket) => {
      const id = `agent-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`;
      this.clients.set(id, socket);
      socket.write(`connected:${id}\n`);

      socket.on("data", (data) => {
        const [to, message] = data.toString().trim().split(" ", 2);
        this.queue.push({ to, message, from: id });

        if (this.clients.has(to)) {
          this.clients.get(to).write(`from-${id}:${message}\n`);
        } else {
          console.log(`[queue] ${to} not found, queued: ${message}`);
        }
      });

      socket.on("close", () => {
        this.clients.delete(id);
      });
    });

    await new Promise((resolve) => server.listen(this.port, resolve));
    console.log(`daemon listening on port ${this.port}`);
  }

  async send(port, agentId, target, message) {
    return new Promise((resolve, reject) => {
      const client = net.connect(port, "127.0.0.1", () => {
        client.write(`${target} ${message}\n`);
        client.on("data", (data) => {
          resolve(data.toString().trim());
          client.end();
        });
      });
      client.on("error", reject);
    });
  }
}

export { MessageDaemon };

This example does not copy memdoor's implementation verbatim. It only shows the principle: the daemon manages client IDs, stores messages in a queue, and delivers immediately when the target agent is connected. The actual memdoor uses a binary executable with different protocols and message formats.

Questions to check before adopting daemon relay

Summarizing the checklist from memdoor's documentation:

Constraints before adoption

memdoor does not include a model provider by default. Users must implement their own agent protocol. The original text emphasizes the advantage of no Docker or Python dependencies, but that means the protocol design responsibility falls on the user.

Message queue size limits, daemon single point of failure (SPOF), and agent authentication methods are not measured in this article. In particular, "single binary" does not guarantee performance, and until independent benchmarks on message throughput appear, it is safest to read the design claims as directional guidance.

What to learn from memdoor is not binary size or daemon implementation method. It is changing call relationships from a web to a center, and preventing message loss with queues. When connecting multiple agents next time, check relay structure and queue policies before model lists.

The paid course below covers verification and constraint design of AI coding harnesses including Claude Code. It is not a course providing memdoor usage or reproduction of this experiment; the link is a promotional link.