{"slug": "coding-agents-over-telegram-part-1-topics-are-agents", "title": "Coding Agents over Telegram, Part 1: Topics Are Agents", "summary": "A developer introduces OpenClaw, a gateway that maps Telegram supergroup topics to individual coding agents running on a remote machine. The design allows users to dispatch and supervise agents from a phone by assigning each agent its own topic, with one bot fronting all topics per machine. The approach enforces a topology of one supergroup per machine to avoid routing conflicts.", "body_md": "You already run coding agents (opencode, Codex, Claude Code) in tmux on some remote box: a dev server, a cloud instance, a GPU node. They work. The problem is *you*: you're chained to a terminal to drive them. Start a task, wait, answer the agent's mid-run question, read the result. If you step away from the desk, the agent stalls on its next question until you SSH back in.\n\nFrom my phone, I wanted to dispatch and **supervise** that work without opening a terminal: kick off a task from a coffee queue, get pinged when it finishes, answer its questions, redirect it.\n\nThe first instinct is \"a Telegram bot that runs shell commands.\" That's a relay, and it's a trap: a single chat thread, no isolation, no notion of *which* agent or *which* project, and zero judgment about whether the agent's answer is any good. This series is about something better.\n\nThe tool that makes it work is **OpenClaw**, a gateway that maps Telegram topics to agents running on your machine and drives your coding-agent panes for you. You'll stand up your own in Part 2. This post is just the mental model; you don't type a single command here.\n\nTelegram supergroups support **forum topics**: separate threads inside one group. The whole design rests on one move:\n\nMap each\n\ntopicto its ownagent.\n\nOne topic drives your opencode pane on project A. A second topic drives a different pane on project B. A third is an *ops* agent with shell access to the whole machine. You switch agents by switching topics, much like switching channels in a chat app, and each keeps its own isolated session and memory.\n\nCrucially, **one bot fronts all of them**. You do not add a bot per agent. You add a *topic* per agent.\n\n```\n                    ┌───────────────  your phone (Telegram)  ───────────────┐\n                    │                                                        │\n                    │   #project-a        #project-b           #ops          │\n                    │      │                  │                  │           │\n                    └──────┼──────────────────┼──────────────────┼───────────┘\n                           │   one front-door bot (one token)     │\n                           ▼                  ▼                  ▼\n                      ┌─────────────────── the box ───────────────────┐\n                      │  agent A          agent B            ops agent │\n                      │    │                 │              (no pane,  │\n                      │    ▼                 ▼            whole box)    │\n                      │ tmux pane         tmux pane                    │\n                      │  opencode          opencode                    │\n                      └────────────────────────────────────────────────┘\n```\n\nType in `#project-a`\n\n, agent A thinks, drives its pane, and replies *into that topic*. The reply always exits through the one bot in the group; the topic only decides **which agent thinks**, not which bot speaks.\n\nAnd yes, this is Telegram wired to a shell on your box. That objection is correct, and the design takes it seriously: access is locked to you alone with an owner-only allowlist, and the riskier actions are gated by the supervisor we'll meet in a moment. The security model is a thread that runs through the whole series.\n\nThis is the part worth internalizing, because every scaling decision falls out of it. Four constraints, all verified against the gateway source and not guessed, force the topology:\n\n`409 Conflict`\n\n. That means one token can't span two machines.Put 1–3 together and the clean topology is unavoidable:\n\nOne supergroup per machine, with its own front-door bot. Topics inside it route to that machine's agents.\n\nTwo boxes? Two supergroups, two bots. It feels redundant the first time, but constraints 2 and 3 mean any \"one mega-group for everything\" design is fragile; you'd be fighting the routing model the whole way. Accept the invariant and the rest falls into place.\n\nWithin a machine, agents come in two flavors, and the distinction matters for safety:\n\nKeeping these separate is deliberate: a courier that can only nudge one pane is a small blast radius; the box-wide operator is the one you guard.\n\nA pinned courier is useful but dumb. The reason this is a *control plane* and not a glorified `ssh`\n\nmacro is the supervisor layer sitting above the agents.\n\nA relay asks: *\"Did the agent answer?\"* The supervisor asks the question that actually matters:\n\n\"Is the answer grounded enough to trust the next step?\"\n\nThat shift is the whole point. The supervisor picks the right tool for a request, checks whether the agent consulted the **correct source of truth** (live cluster state vs. a stale backup; the actual failing test vs. a confident guess), challenges weak or stale evidence, and **blocks** an unsafe or unverified next step before it reaches you. It treats a coding agent's polished paragraph as a *claim to be audited*, not a fact. Concretely, it grades each answer and routes it one of four ways: pass it through, ask a focused follow-up, demand a second review, or block it outright.\n\nIf you rely on agents to move fast in an unfamiliar codebase, this is the layer that keeps their confident mistakes from becoming *your* mistakes. We go deep on it in the live session; it's the difference between a chatbot and a skeptical senior reviewer that never sleeps.\n\n| Part | What | When |\n|---|---|---|\n1: Topics Are Agents (this post) |\nThe mental model and the one-supergroup-per-machine invariant | Read before the session |\n2: From Zero to an Agent That Answers |\nStand up your own instance: bot, supergroup, gateway, one pane-driving agent |\nDo before the session |\n3: The Day-to-Day Operating Contract |\nWhat to type, what not to type, and how to supervise safely |\nRead before the session |\n| 4: Making Agents Useful | Skills, tool servers, per-topic memory | Live in the session |\n| 5: The Skeptical Supervisor | Evidence-before-trust, and how it blocks bad answers | Live in the session |\n\n**Your pre-work:** read Parts 1 and 3, and actually *do* Part 2 so you arrive with a working setup: a topic where you type a message and a coding agent answers and drives a pane. The session then spends its time on how to *use* this well, not on fixing installs.\n\nPart 2 is next: zero to an agent that answers you, on your own box, in about half an hour.", "url": "https://wpnews.pro/news/coding-agents-over-telegram-part-1-topics-are-agents", "canonical_source": "https://dev.to/jerilk/coding-agents-over-telegram-part-1-topics-are-agents-5f75", "published_at": "2026-06-13 19:18:09+00:00", "updated_at": "2026-06-13 19:44:56.204180+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["OpenClaw", "Telegram", "opencode", "Codex", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/coding-agents-over-telegram-part-1-topics-are-agents", "markdown": "https://wpnews.pro/news/coding-agents-over-telegram-part-1-topics-are-agents.md", "text": "https://wpnews.pro/news/coding-agents-over-telegram-part-1-topics-are-agents.txt", "jsonld": "https://wpnews.pro/news/coding-agents-over-telegram-part-1-topics-are-agents.jsonld"}}