Skip to content
Back to blog

I Run a Team of Coding Agents From a Telegram Chat

I used to hand one task to one agent. Now Hermes sits in my Telegram as a manager, breaks down what I ask, and dispatches the actual coding to Claude Code and Codex. Here's how running agents like a team — from a chat app — actually works.

Jun 25, 20266 min readaihermesagentsorchestrationtelegram

A while back I wrote about letting an AI agent run my dev environment for a week. That was the single-agent version: one assistant in my terminal, doing one thing at a time. Since then I've leaned in harder, and the shift that actually changed how I work isn't that an agent can write code — I already knew that. It's that I stopped talking to a coding agent directly and started talking to a manager that talks to them for me.

That manager is Hermes, and it lives in a Telegram chat on my phone. I type what I want. It figures out the steps, hands the real coding to Claude Code or Codex, and reports back. Most days I kick off real work from the same app I use to send memes.

One manager, many workers

Here's the mental model that made it click: Hermes barely writes code itself. It's an orchestrator. The coding agents — Claude Code, Codex — are the ones in the repo writing the diff. Hermes is the layer above them: it takes a fuzzy goal, breaks it into concrete tasks, decides who does what, and stitches the results back together.

So a message like "the projects page throws a console error on load, find it and fix it" doesn't go straight to a code model. Hermes reads it, decides this is a single scoped task, spins up a coding agent on the repo, and comes back with "found it — a project image was missing a leading slash, here's the one-line fix." I approve from the chat.

Telegram is the control plane. I'm not in a terminal. I'm approving, redirecting, and asking for changes in a chat thread — on my phone, on the couch, wherever. The agents do the heavy lifting on a server somewhere; I'm just the one saying yes, no, and "try it the other way."

Why bother with a manager layer

For one task, a manager is overkill — just talk to the coding agent directly. The layer earns its place the moment work fans out.

Say I want to ship a feature and check whether it broke anything and update the docs. With a single agent that's a sequential slog: do one, then the next, then the next, babysitting each step. With Hermes I describe the whole thing once and it parallelizes the independent parts — one worker implements while another audits the surrounding code — then merges what comes back. I review one consolidated result instead of running three sessions myself.

The other reason is that I stop holding the breakdown in my head. "Add stock alerts to the inventory module, follow the existing pattern, and write a test for it" is three jobs. I used to mentally queue them and feed them in one at a time. Now I say it once and the decomposition is the manager's problem, not mine.

A real task, from a Telegram message

Here's a recent one, start to finish. The experience section on this site was a plain two-column grid of cards, and I wanted it to actually tell a story. I messaged Hermes: "redesign the experience section as a vertical timeline — no company logos, mark the role I'm still in, keep it clean."

What came back:

  1. Hermes pulled the repo and found the three components involved — the list, the card, and the detail modal.
  2. It handed the rewrite to a coding agent with my constraints: timeline layout, a pulsing node on the current role, a tech preview on each entry, no logos.
  3. A few minutes later — a diff and a one-paragraph summary. The grid was now an animated vertical timeline.

Then I caught the kind of bug an agent loves to ship: it looked right in isolation but broke in context. On mobile, the new overlay was sitting on top of the menu's close button — you could open an entry, but the X to dismiss it was stuck underneath, unclickable. I sent back one line: "the close button is covered on mobile." It traced it to a stacking-context issue, lifted the header above the overlay, and the fix held.

Reviewed, approved, shipped. The part worth noting: the first pass never touched my laptop. Request, implementation, review, one revision — all in a chat thread while I was doing something else.

The delegation patterns that actually work

A few months of this taught me some rules, mostly the hard way:

  • Scope tightly. Vague asks get vague work. "Improve the projects page" is a bad task; "remove the All filter and default to Project" is a good one. The tighter the scope, the less I have to correct.
  • One worker per concern. Letting two agents touch the same files in parallel is asking for a merge conflict. Parallelize independent work — research vs. code, frontend vs. data — not the same file twice.
  • Keep a human gate before anything irreversible. Deploys, deletes, force-pushes — I want to be the one pressing the button. The manager proposes; I dispose.
  • Review the diff, not the description. The summary Hermes sends is a convenience, not the truth. For anything beyond a one-liner I jump to GitHub and read the actual change. Telegram is great for approving, terrible for reading 200 lines of diff.

The rough edges

It's genuinely good, but I'm still figuring parts of it out, and it's not free of friction:

  • Handoff loss. Context doesn't transfer perfectly between the manager and the workers. Sometimes a coding agent does exactly what it was told and exactly not what I meant, because a constraint got flattened in the handoff.
  • Over-decomposition. Give it something simple and it'll occasionally turn a five-minute fix into a three-step plan with a project board's worth of ceremony. You learn when to say "just do it."
  • Cost adds up. Several agents working in parallel burn tokens faster than one. For trivial stuff, the orchestration overhead isn't worth it — I go direct.
  • You still review everything. None of this removes the need to understand your own codebase. The agents are fast and confident, and confident-but-wrong is the most expensive kind of wrong.

Who this is for

If you're a solo dev or on a small team and you've already got the single-agent workflow down, the manager layer is the natural next step — especially if you keep wishing you could fire off work without sitting at your desk. Running it from Telegram sounds gimmicky until the first time you ship a fix from your phone during a coffee break.

It's still early, I'm still learning the edges, and the setup isn't zero-effort. But the direction is clear: I spend less time doing the mechanical parts and more time deciding what should happen. The agents are the team. I'm just the one in the chat saying go.