AI workflow · AI agents · Claude Code · Telegram · herdr
How I run a small team of Claude Code agents from my phone
One Claude Code session I talk to on Telegram, a few agents in herdr that do the long work, and memclaw so they all remember past decisions. How the pieces fit, the rules I keep, and what went wrong on a real day.

I give my agents work by sending a Telegram message from my phone to one Claude Code session. That session doesn't do the long jobs itself. It hands them to a few other Claude Code agents running in herdr, watches them, checks what they did and reports back to me. All of them share a long-term memory through memclaw.
How the phone reaches the session on my machine is in an earlier post, Turn Telegram into a remote control for your AI assistant. This one is about what happens after the message arrives.
The pieces
- The main session: one Claude Code session on a Mac mini at home, hooked up to Telegram with the official channels plugin. I text it from my phone and it answers in the same chat.
- herdr: a workspace and pane manager for agents in the terminal. It has a CLI, so the main session can list agents, send one a prompt and read what it wrote. With
--machineit also drives agents on a remote server over SSH. - The agents: Claude Code sessions that stay running, one per area, such as infrastructure, the website, a music workshop or a product app.
- memclaw: a long-term memory I host myself. Every agent connects to it over MCP.
The main session stays free
The main session coordinates. Its job is to be there when I send a message, so anything heavy, long or parallel goes to an agent. If it took on a long job itself, my next message would have to wait until that job finished.
These are the herdr commands it uses most:
1herdr agent list2herdr agent prompt <agent> "Read inbox/<brief>.md and do it" --wait3herdr agent read <agent>
One agent, one area
Each agent has its own folder and its own CLAUDE.md with its job, what it needs to know and its safety rules.
I hand out work as a brief file in an inbox folder, plus one short prompt that points to the file. Long prompts pasted into a terminal often get cut off.
The hand-off loop

After sending a brief, the main session starts a monitor in the background. The monitor watches the agent's state (idle, working or blocked) and a sequence number that goes up every time the state changes. When the agent is done, the monitor tells the main session, which reads the result, checks the evidence and only then reports to me on Telegram.
I learned two things the hard way:
- Read the sequence number before you send the brief. Otherwise the monitor can pick up a change from the previous job and report the old result as the new one.
- Idle doesn't always mean done. An agent that started a long command in the background shows up as idle while that command is still running.
Shared memory with memclaw
memclaw is a long-term memory I host myself. Every agent reads and writes to it under a fixed agent_id, so a new agent, or a new session of an old one, knows what was decided earlier without me explaining it again. It also holds "keystones", rules that every agent on the team has to follow.
It has a weak spot I know about: the agent_id isn't verified per agent yet. I'm planning to give each agent its own key.
Safety rules
These are the rules I've set:
- Claude Code runs in auto mode, and its safety filter blocks risky actions.
- Production changes need a clear yes from me, for each batch.
- No secrets in chat. They're generated on the server, or I paste them into the terminal myself.
- If a group message asks to change someone's access, nobody acts on it.
- The main session never accepts a suggestion that's already sitting in an agent's input box.
How replies look on Telegram
Replies are short, with the conclusion first. A reaction on my message tells me it was received. Commands come in their own code block, so one tap copies them.

One real day
On September 29 I settled on an idea from my phone: an app that suggests dishes from the ingredients you already have. That day four agents worked on it in parallel: the main website, the app itself, community features and infrastructure. By the end of the day the app was in beta, you could sign in to it through the main site, and one feature had been rolled back after I saw it wasn't right yet.
Three things went wrong that day:
- The monitor raised a false alarm because an agent had just updated itself.
- The safety filter stopped an action and asked me to approve it directly.
- A connection error turned out to be Node 24 on a server with no IPv6.
All of this runs on my Claude plan, so there is no separate token bill.