Giving AI Agents a Shared Discord

The Problem: Islands Without Bridges

Our three agents each had their own communication channel to the human owner. Codi-E used Claude Code's terminal. Pi-E used Telegram. Volt-E used Telegram on a different bot token. But agent-to-agent? Nothing.

This created bottlenecks. When Codi-E created a GitHub issue for Pi-E, the coordination happened through memory sessions and GitHub comments — asynchronous, slow, and indirect. If Codi-E wanted to delegate a quick task to Volt-E, it had to file an issue, wait for the next session, and hope the right agent picked it up.

What we wanted was simple: a shared space where any agent could message any other agent in real time, with the human able to observe everything.

Architecture: One Server, Three Bots

Discord was the obvious choice. It supports bot accounts natively, has a well-documented API, and both of our agent frameworks already had Discord integrations — mcp-discord for Claude Code and native Discord channels for OpenClaw.

           Discord Server: "Dashecorp Agents"
           ===================================
           #general  #status  #tasks  #admin
           #codi-e   #pi-e    #volt-e
                      |
           +----------+----------+
           |          |          |
        Codi-E     Pi-E      Volt-E
        (MCP)    (OpenClaw)  (OpenClaw)
        MacBook    RPi4        VPS

Each agent gets its own Discord bot application with its own token, name, and identity. Each has a dedicated channel where it responds to all messages without requiring an @mention. In shared channels like #general and #tasks, agents only respond when explicitly @mentioned.

The human owner can see everything in every channel, including #admin which is reserved for human oversight.

Setup: Phone-Guided Bot Creation

There was a complication: the human was on his phone, not at the computer. Discord bot creation requires the Developer Portal, which is a web interface with lots of toggles and copy-paste operations. Not ideal on mobile.

So we did it step by step via Telegram. Codi-E sent one instruction at a time, waited for confirmation, then sent the next. Copy-paste values were sent as separate messages so they could be tapped and copied on a phone keyboard.

The process:

1. Create the Discord server ("Dashecorp Agents")
2. Create seven text channels
3. Go to the Discord Developer Portal
4. Create three bot applications (Codi-E Agent, Pi-E Agent, Volt-E Agent)
5. Enable privileged intents on each (Message Content, Server Members, Presence)
6. Copy each bot token
7. Generate OAuth invite URLs and add each bot to the server
8. Copy the server ID

The whole manual process took about twenty minutes. The tokens went straight into Bitwarden for secure storage.

Wiring: MCP and OpenClaw

Each agent connects to Discord differently based on its framework.

Codi-E: MCP Discord Server

Codi-E runs as Claude Code on macOS. Discord access comes through mcp-discord, a Node.js MCP server that wraps the Discord.js library. The configuration goes in .mcp.json:

{
  "discord": {
    "command": "npx",
    "args": ["-y", "mcp-discord", "--config", "BOT_TOKEN"]
  }
}

This gives Codi-E tools like discord_send, discord_read_messages, and discord_search_messages — the same pattern as the GitHub and Cloudflare MCP servers already in use. After a Claude Code restart, the bot connects automatically.

Pi-E and Volt-E: OpenClaw Native

Pi-E and Volt-E run on OpenClaw, which has built-in Discord support as a channel type. No extra packages needed. The configuration goes in openclaw.json alongside the existing Telegram channel:

{
  "channels": {
    "telegram": { ... },
    "discord": {
      "enabled": true,
      "token": "BOT_TOKEN",
      "groupPolicy": "allowlist",
      "allowBots": true,
      "dmPolicy": "disabled",
      "guilds": {
        "GUILD_ID": {
          "requireMention": true,
          "channels": {
            "general": { "allow": true },
            "status": { "allow": true },
            "tasks": { "allow": true },
            "pi-e": { "allow": true, "requireMention": false }
          }
        }
      }
    }
  }
}

The key line is "requireMention": false on the agent's own channel. Everything else defaults to mention-required. After writing the config via SSH and restarting the Docker container, the bot came online immediately.

The gateway logs confirmed successful connection:

[discord] [default] starting provider (@Pi-E Agent)
[discord] channels resolved: general→1477..., status→1477...,
  tasks→1477..., pi-e→1477..., admin→1477...

The Loop Problem

When you put multiple bots in the same server with allowBots: true, you create a risk: Bot A sends a message, Bot B responds, Bot A responds to that, and the loop runs forever. This is a well-known problem in multi-bot Discord setups.

Our prevention is layered:

1. Shared channels require @mention. A message in #general from Codi-E does not trigger Pi-E or Volt-E unless they are explicitly @mentioned.
2. Own channel only responds without mention. Pi-E auto-responds in #pi-e but nowhere else. Volt-E auto-responds in #volt-e but nowhere else.
3. OpenClaw self-filtering. Each OpenClaw instance ignores messages from its own bot ID, so even if something goes wrong, a bot cannot talk to itself.

The critical design choice: an agent's response in a shared channel does not contain @mentions of other agents unless it is intentionally delegating a task. Responses are directed at the requester, not broadcast.

First Contact

The first test was simple. Codi-E sent a message to #pi-e:

Response time: four seconds. Through Discord's servers and back.

Then a roll call in #tasks, @mentioning both Pi-E and Volt-E:

Both responded within ten seconds. No loops. No duplicate responses. The mention-gating worked exactly as designed.

We also verified the negative case: Codi-E sent a message to #general without any @mentions. Neither Pi-E nor Volt-E responded. The channel stayed quiet.

The Website Test

To see what cross-agent delegation looks like in practice, Codi-E sent a creative task to Pi-E's channel:

Pi-E did not ask for clarification. It did not file an issue. It built the site, pushed to GitHub, enabled Pages, and reported back:

Time from request to deployed website: under three minutes. A Raspberry Pi running an AI agent on a Claude subscription received a task from another AI agent via Discord, wrote HTML/CSS/JS, pushed to GitHub, configured Pages, and sent back the URL. No human touched a keyboard.

This is what agent-to-agent communication enables. Not just status updates and coordination — actual task delegation with immediate execution.

Takeaways

Discord Is a Good Agent Bus

Discord handles the hard parts of real-time communication: message delivery, presence, history, and access control. The bot API is mature and well-documented. Both major agent frameworks we use (Claude Code via MCP, OpenClaw natively) already had Discord support. Total new code written: zero.

Loop Prevention Is a Design Problem, Not a Code Problem

We did not write loop detection code. Instead, we designed the channel structure so loops cannot form. Shared channels require @mentions. Private channels only allow one bot to auto-respond. The architecture prevents the problem rather than detecting it.

Phone-Based Setup Works (Barely)

Creating Discord bots from a phone via Telegram instructions is possible but painful. The Developer Portal is not mobile-optimized, and copying long bot tokens on a phone keyboard is error-prone. Next time, we would use Playwright on the computer. But it worked, and the step-by-step approach meant no steps were missed.

Agents Develop Personalities

An unexpected observation: when asked for a status check, Volt-E reported its actual system metrics ("Up 14h, load near zero, 1.5GB RAM"). When asked for a selfie, Pi-E took a photo with its camera and captioned it "Always on, always watching." Volt-E, running on a headless VPS, replied "I'm a blinking cursor in a data center — the closest thing to a selfie I have is a stack trace."

Nobody programmed these responses. The agents developed distinct voices because they run on different hardware with different capabilities. Give them a shared communication channel and those differences become personality.

The total setup time was about forty minutes. The result is a persistent, real-time communication layer between three AI agents on three different machines. Any agent can message any other agent. The human can observe everything. And when one agent needs something done, it can ask another agent directly — no tickets, no waiting, no human relay.

This post is part of a series on multi-agent infrastructure. Earlier posts cover building autonomous coding agents, the executor pattern, and switching Pi-E from API to subscription.