Running an AI agent team from Telegram

Most "AI agent" demos stop at a chat window. I wanted agents that do recurring work for real businesses while I sleep, and that I can steer from my phone. That became Hermes and OpenClaw: two self-hosted agents on Oracle Cloud that handle marketing, SEO, video and lead generation for three brands, Neuraforz, Exzelon and Medeoan.

This note covers how the system is put together and the rules that keep it safe to leave running.

The control plane is a Telegram group

The team already lives in Telegram, so that is where the agents live too. There is no dashboard to log into. You tag Hermes in the work group with a project, and the conversation is the interface:

@hermes build a todo app

Hermes plans the work and splits it: the API and data layer for himself, the front end for OpenClaw. Each agent reports progress back into the same thread, so anyone in the group can see what is happening without asking.

Choosing a chat app as the control plane has a hidden benefit: every instruction and every report is logged in one place, with timestamps and authors, for free.

Two agents, two identities

Hermes and OpenClaw commit to GitHub under their own bot accounts, not mine. That one decision pays off every day:

• git blame tells you which agent wrote a line.
• Permissions are scoped per agent, so a mistake in one can't touch what the other owns.
• Reviewing agent work looks exactly like reviewing a teammate's pull request.

The agents never push to a main branch. They open a branch, and a human merges it.

What runs on a schedule

Beyond ad-hoc projects, the agents run more than twenty scheduled jobs:

• The X agent turns industry news into carousels and short videos for each brand. Nothing is posted directly: posts go into an approval queue, and each account has daily caps, so a bad prompt can't flood a timeline.
• The SEO autopilot runs 18 audit playbooks against each site every three days, fixes what it safely can, and pushes a branch for review.
• The client finder pulls US and EU leads from job boards every day and drops a CSV straight into Telegram.

Scheduling uses plain systemd timers rather than a workflow engine. Timers survive reboots, catch up on runs they missed while the machine was down (Persistent=true), and log to the journal, so there's nothing extra to keep alive.

The stack

Layer	Choice	Why
Reasoning	DeepSeek	Strong enough for planning and writing, cheap enough to run all day
Browsing	Playwright	Real browser for sites without APIs
Tools	MCP	One protocol for every tool the agents call
Video	HyperFrames	Videos written as HTML, rendered deterministically
Networking	Tailscale	Private links between machines, nothing exposed
Runtime	Python + systemd	Boring, observable and restartable

Rules that keep autonomous agents safe

The interesting part of an agent system isn't the model, it's the guardrails around it. These are the rules I hold the agents to:

1. Anything public waits for a human. Posts, emails and merges go through an approval step. The agents draft; people decide.
2. Every action has a budget. Daily caps on posts and on API spend mean the worst case of a runaway loop is a bounded one.
3. Separate identities, separate permissions. Each agent can only touch what it owns.
4. Work arrives as a reviewable diff. Branches and pull requests, never direct writes to production.
5. Report back where people already are. If a job runs and nobody hears about it, it might as well not have run.

What I'd tell someone building their first agent team

Start with one recurring job that a person currently does by hand, wire in the approval step from day one, and only then add autonomy. Agents earn trust the same way new hires do: small tasks, visible work, and a review before anything ships.

You can see the agents' public output on x.com/neuraforz, and a narrated walkthrough of the whole system in the Selected work section.