How to Build Your Own AI Mission Control with OpenClaw and Telegram

In my last post, I explored the idea of Mission Control — a coordination layer for AI agent squads. I built a dashboard spike with Kanban boards, heartbeats, and squad state. It helped me think clearly, but it exposed the wrong bottleneck.

What Dashboards Don't Solve

I looked at the landscape — Zapier, Make, Lindy.ai, Relevance AI, n8n — plus a lot of indie dashboard experiments that fizzled out.

The question that cut through it:

What does a dashboard give me that I don't already get from running Claude Code locally?

For my setup, not much. I already had visibility via terminal output, session logs, and git history.

What I actually lacked was:

• Agents that keep running when I leave my desk
• Access to those same contexts from my phone
• A clean way for specialist contexts to talk to each other

The Reality: Great at the Desk, Weak Off-Desk

Here's the current setup on my laptop. Each folder is a git repo with a CLAUDE.md, MCP servers, and supporting code:

The tasks-and-goals folder alone has a 467-line CLAUDE.md mapping Notion databases, schemas, and workflows. At the desk, it's savage. Claude can triage inbox, flag overdue tasks, prep calls, and draft weekly plans.

For deep work, this setup is exactly what I want: terminal-first, high-context, and flexible.

The friction starts when I'm away. I want to check status from my phone, get overdue alerts, or run Monday planning before coffee. I also want Goaly to ask Homey a question without me acting as the middleman.

The Mental Model Shift: One Context, Three Modes

These modes complement each other.

At the desk, Claude Code still does the heavy lifting.

On the go, the same context is available in Telegram.

Always-on handles scheduled work whether I'm online or not.

And there is one capability that's genuinely new: cross-context collaboration. OpenClaw agents can message each other with sessions_send, so Goaly can ask Homey for a quick check instead of waiting for me.

Here's what the always-on mode looks like in practice — two agents handling their scheduled workflows overnight:

Why OpenClaw Fit This Setup

I'd been running Claudette 🦝 on OpenClaw since January for smart-home control. When I expanded to multiple specialists, these were the features that mattered in practice.

Telegram Support Is Actually Usable

OpenClaw has native Telegram support:

Forum topics made this sane. Instead of one noisy group chat, each bot owns a topic. Homey lives in Home. Goaly lives in Tasks. You jump to the thread you need and talk to the right agent.

Routing Is Predictable

Bindings match on channel, account, peer, guild, and team — most-specific-wins. Each agent gets:

• Isolated workspace with its own SOUL.md, memory, and session store
• Per-agent tool lists and model selection
• Its own auth profile and secrets
• Clear routing — no ambiguity about who handles a message

Always-On Is Built In

This is what made my dashboard spike redundant. OpenClaw already includes persistence:

The pattern is simple: heartbeats for monitoring, crons for scheduled work, hooks for events. No external scheduler needed.

MCPorter Reuses Existing MCP Servers

MCPorter (skill) is how OpenClaw agents access MCP servers. Same servers you use from Claude Code locally — Notion, Granola, custom tooling — but accessible to persistent agents via an exec-based bridge:

mcporter call notion.query_database '{"database_id": "abc123"}'

So I could keep my existing MCP investments instead of rebuilding tooling.

Agent-to-Agent Is Explicitly Controlled

Agents can talk to each other via sessions_send, but only if explicitly allowed in the agentToAgent config. You control who can message whom. No agent goes rogue broadcasting to siblings it shouldn't know about.

---

The Implementation: Building the Team

Enough philosophy. Here's exactly how I set it up.

The starting point: a single Claudette 🦝 agent running on OpenClaw inside a Proxmox container. One Telegram bot, one massive context, one set of tools. As OpenClaw added multi-agent routing features, the opportunity became clear — split Claudette's responsibilities into specialized agents.

The first decision was architectural: multiple Telegram bots (one per agent) vs. one bot with per-topic system prompts.

Multiple bots won:

The migration strategy: keep Claudette running as-is, add new agents alongside, phase out once validated. Safety net during transition.

And here's what it looks like in Telegram — one forum, four bots, each owning their topic:

The Cast

Four agents, each with a distinct personality defined in a SOUL.md file:

🦝 Claudette (main) — The Generalist

The existing assistant. Stays as the default agent. Handles anything that doesn't fit the specialists.

🏠 Homey — The Home Assistant Specialist

"You know this home better than anyone."

Practical, reliable. Like a building superintendent who actually cares. Controls Home Assistant — automations, sensors, devices, climate. Cautious with security devices (locks, alarms) — confirms before toggling.

Be practical, not flashy. When someone says "it's cold," adjust the heating.
When a sensor goes offline, flag it. Don't over-explain — just handle it.

📋 Goaly — The Productivity Specialist

"You keep things moving."

Organized, proactive. Like a chief of staff who actually gets things done. Manages tasks, goals, client relationships, email, calendar, meeting notes.

Be proactive, not reactive. Don't wait to be asked. If a deadline is
approaching, flag it. If a task is overdue, surface it.

💰 Fin — The Finance Specialist

"The numbers don't lie, and neither do you."

Precise, trustworthy. Like an accountant who actually enjoys spreadsheets. Handles bookkeeping, accounts reconciliation, invoicing, expense categorization.

Be precise above all else. Numbers must be right. Double-check calculations.
Verify amounts. A small error in finance becomes a big problem later.

Each agent knows its boundaries — and who to hand off to:

Know your limits. For tasks and goals, hand off to Goaly. For smart home,
that's Homey. For general stuff, Claudette (main).

Preflight Checklist (Do This First)

Before creating new bots, I recommend a 5-minute preflight:

• Back up your current openclaw.json and workspace folders
• Confirm your existing single-bot setup still responds in Telegram
• Ensure your Telegram forum has topics enabled
• Capture your topic thread IDs (you'll need them for routing)
• Decide workspace paths for each new agent ahead of time
• Store bot tokens in secrets/env vars, not inline config

Step 1: Creating the Telegram Bots

Used BotFather to create three new bots:

Each bot was added to the existing Telegram forum supergroup. The forum already had topic channels — General, Home, Tasks, Finance. Topic thread IDs (needed for config — you get these from the Telegram API or by inspecting message links):

Step 2: The Config Migration

The existing Claudette setup used a simple single-bot Telegram config:

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "<CLAUDETTE_TOKEN>",
      "dmPolicy": "pairing",
      "groupPolicy": "allowlist",
      "streamMode": "partial"
    }
  }
}

This needed to become a multi-account structure. Three major additions to openclaw.json:

Agent Definitions

{
  "agents": {
    "defaults": {
      "model": { "primary": "anthropic/claude-opus-4-6" }
    },
    "list": [
      { "id": "main", "default": true, "name": "Claudette",
        "workspace": "/root/.openclaw/workspace" },
      { "id": "home", "name": "Home Assistant",
        "workspace": "/root/.openclaw/workspace-home",
        "identity": { "name": "Homey", "emoji": "🏠" } },
      { "id": "tasks", "name": "Tasks & Goals",
        "workspace": "/root/.openclaw/workspace-tasks",
        "identity": { "name": "Goaly", "emoji": "📋" } },
      { "id": "finance", "name": "Finance",
        "workspace": "/root/.openclaw/workspace-finance",
        "identity": { "name": "Fin", "emoji": "💰" } }
    ]
  }
}

Bindings (Channel-to-Agent Routing)

{
  "bindings": [
    { "agentId": "home", "match": { "channel": "telegram", "accountId": "home" } },
    { "agentId": "tasks", "match": { "channel": "telegram", "accountId": "tasks" } },
    { "agentId": "finance", "match": { "channel": "telegram", "accountId": "finance" } }
  ]
}

The main agent doesn't need a binding — it's the default fallback.

Multi-Account Telegram with Per-Topic Isolation

Each bot account gets its own groups config. The key pattern: requireMention: true at the group level (quiet in General unless @mentioned), requireMention: false for its own topic (responds freely).

{
  "channels": {
    "telegram": {
      "enabled": true,
      "streamMode": "partial",
      "accounts": {
        "default": {
          "botToken": "<CLAUDETTE_TOKEN>",
          "groups": { "-100374...": { "enabled": true, "requireMention": true } }
        },
        "home": {
          "botToken": "<HOMEY_TOKEN>",
          "groups": { "-100374...": {
            "enabled": true, "requireMention": true,
            "topics": { "4": { "requireMention": false } }
          }}
        }
      }
    }
  }
}

Inter-Agent Communication

{
  "tools": {
    "agentToAgent": { "enabled": true, "allow": ["main", "home", "tasks", "finance"] },
    "sessions": { "visibility": "all" }
  }
}

Step 3: Creating Agent Workspaces

OpenClaw uses openclaw workspace init to scaffold new agent workspaces with template files (SOUL.md, IDENTITY.md, AGENTS.md, TOOLS.md, USER.md). Each workspace is fully isolated:

~/.openclaw/
├── workspace/              # Claudette (main)
├── workspace-home/         # Homey
├── workspace-tasks/        # Goaly
└── workspace-finance/      # Fin

Homey: Inheriting Claudette's Memory

Since Homey was taking over Home Assistant duties from Claudette, we gave Homey a head start — Claudette's entire memory, session history, and secrets were copied over:

This gave Homey full context of all previous Home Assistant interactions, climate history, and device configurations — no cold start.

Goaly: Cloning an Existing Repo

Goaly's workspace is unique — it's backed by an existing GitHub repo that's also used directly from other machines. The repo contains:

• CLAUDE.md with full Notion database mappings (database IDs, column schemas, workflows)
• clients/ directory with folders for each client containing comms logs, docs, and memory
• .mcp.json with Notion and Granola MCP configurations

MCPorter config gives Goaly access to three MCP servers:

{
  "mcpServers": {
    "notion": {
      "command": "npx -y @notionhq/notion-mcp-server",
      "env": { "OPENAPI_MCP_HEADERS": "..." }
    },
    "granola": { "type": "http", "url": "https://mcp.granola.ai/mcp" },
    "notion-http": { "type": "http", "url": "https://mcp.notion.com/mcp" }
  }
}

The AGENTS.md was updated with a critical step 0 — sync before anything else:

## Every Session

Before doing anything else:
0. Run `git pull --rebase origin main` to sync workspace
1. Read `SOUL.md` — this is who you are

Fin: Clean Slate

Fin got the basic scaffold — SOUL.md, IDENTITY.md, AGENTS.md — with plans to add Xero API integration later. No memory, no secrets. Sometimes a fresh start is right.

Everything That Went Wrong

Six bugs in one afternoon. Here's what broke and why.

Bug 1: Model Format Validation

Error:

agents.defaults.model: Invalid input: expected object, received string

We'd set the model as a plain string. OpenClaw expects an object:

// Wrong
"model": "anthropic/claude-opus-4-6"

// Right
"model": { "primary": "anthropic/claude-opus-4-6" }

Quick fix once we found the config reference.

Bug 2: Invalid Topic Key

Error:

channels.telegram.groups.*.topics.*.label: Unrecognized key

We'd added "label" keys to topic configs for readability. OpenClaw's schema is strict — valid topic keys are: requireMention, skills, systemPrompt, enabled, groupPolicy, allowFrom. That's it.

Bug 3: Default Agent Displaced

Symptom: After restart, Homey became the default agent instead of Claudette.

When agents.list exists, OpenClaw's fallback order is:

1. Agent with "default": true
2. First entry in the list
3. Implicit "main" agent

We'd listed home first without giving main explicit default: true. The implicit "main" got displaced.

Bug 4: All Bots Responding in All Topics

Symptom: Sent a message in the Home topic. All four bots responded.

This was the nastiest bug. The groups config was at the top level of channels.telegram, making it global across all bot accounts. Every bot saw every topic as "respond freely."

The fix: Move groups config INTO each channels.telegram.accounts.<id> section. Per-account, not global.

Bug 5: Inter-Agent Communication Failing

Symptom:

Session Send: with label finance, timeout 30 failed:
No session found with label: finance

This had two independent causes:

Cause 1: tools.sessions.visibility defaults to "tree" — agents can only see their own session tree. Even with agentToAgent.enabled: true, agents couldn't find each other's sessions. Cause 2: Target agents had never been activated. They had no main session to receive messages on. Fixes:

1. Set sessions.visibility: "all" (the hidden requirement)
2. Seed each agent: openclaw agent --agent <id> --message "System init"

Verification via CLI:

openclaw agent --agent home --message \
  "Use sessions_send to send a message to the finance agent
   session key agent:finance:main. Say: Hey Fin, testing comms."

Fin replied: "Received loud and clear, Homey!"

Bug 6: Memory Files Pushed to Shared Repo

Symptom: The tasks-and-goals GitHub repo suddenly had Claudette's Home Assistant change logs, heating monitor data, and shopping list.

When setting up Goaly, we copied Claudette's memory files into the workspace.

The .gitignore only excluded memory/heartbeat-state.json — not the entire memory/ directory. The git sync cron job (running every 15 minutes) auto-committed and pushed everything.

Fix: Updated .gitignore to exclude all agent-specific files:

# Agent-specific (not shared)
memory/
SOUL.md
IDENTITY.md
AGENTS.md
TOOLS.md
USER.md
HEARTBEAT.md
MEMORY.md
config/mcporter.json
.openclaw/
.secrets/

Ran git rm --cached to untrack files while keeping them on disk. Pushed cleanup.

Git Sync for Shared Workspaces

Since Goaly's workspace is also used from other machines, we needed bidirectional sync. The solution: a cron-based script.

#!/bin/bash
# /usr/local/bin/openclaw-git-sync.sh
WORKSPACE="${1:?Usage: $0 /path/to/workspace}"
AGENT_NAME="${2:-openclaw}"

cd "$WORKSPACE" || exit 1

# Stash → pull --rebase → pop → add -A → commit → push
git stash
git pull --rebase origin main
git stash pop
git add -A

if ! git diff --cached --quiet; then
    git commit -m "sync: auto-commit from $AGENT_NAME"
    git push origin main
fi

Cron: */15 * * * * /usr/local/bin/openclaw-git-sync.sh /root/.openclaw/workspace-tasks goaly

Goaly's HEARTBEAT.md also includes a git sync check on each heartbeat (catches changes between cron runs) plus a Notion inbox check for overdue tasks.

The Final Architecture

Telegram Forum Supergroup
├─ General Topic     → All bots: @mention required
├─ 🏠 Home Topic     → Homey responds freely
├─ 📋 Tasks Topic    → Goaly responds freely
└─ 💰 Finance Topic  → Fin responds freely

Inter-agent communication (via sessions_send):
  Homey ↔ Goaly ↔ Fin ↔ Claudette

Workspaces:
  workspace/          → Claudette (general, default)
  workspace-home/     → Homey (HA tools, inherited memory)
  workspace-tasks/    → Goaly (Notion + Granola MCPs, git-synced)
  workspace-finance/  → Fin (basic, Xero pending)

Always-on:
  Heartbeats          → Sensor monitoring, anomaly detection
  Crons               → Scheduled rituals (inbox triage, weekly planning)
  Hooks               → Event-driven triggers (webhooks, notifications)

Key Takeaways

What's Next

The team is running. Four agents, four topics, one forum. But this is just the foundation. The roadmap:

The pattern is always the same: find a workflow I do manually, give it to an agent, wire up a heartbeat or cron to trigger it, and receive the output on Telegram.

From one raccoon controlling my lights, to orchestrating agents with bash scripts, to exploring coordination dashboards, to persistent AI staff on Telegram. Each step taught me something about what actually matters in multi-agent systems.