Before I open my computer, useful work is already waiting in Telegram. I find
summaries, notes, drafts, and the result of jobs that ran overnight. They are
not notifications asking me to open another app.
The important part is not that an AI model stays online. It is that a small,
ordinary system can prepare work, put it somewhere I already look, and stop
before an action becomes risky.
Telegram is the front door: the request goes in from my phone, the work happens on the server, and the result comes back to the same conversation. One server, one front door
Hermes is an open-source agent running on a rented Linux server. Telegram is
the interface; the gateway, memory, scheduled jobs, and tools live behind it.
The models do not run on the server. Hermes calls an online provider, so I can
change the model without rebuilding the rest of the system.
The whole loop: Telegram to one agent on one server, then out to summaries, watched sources, and a workout bridge The machine itself is deliberately unremarkable:
No GPU is needed. The server's job is to keep the agent, its tools, and its
state available. The provider does the model inference.
Useful work, not autonomous busyness
The agent does not invent a mission while I sleep. It runs jobs I created on
purpose, with an expected result and a place for that result to land.
Three jobs worth keeping: morning summaries, readable Git-backed memory, and a workout that can leave the chat Morning summaries
Timed jobs watch sources, prepare short reports, and send the useful part to
Telegram. The value is not automation by itself. It is starting the day with
something ready to review instead of opening ten tabs and reconstructing the
same context again.
Memory I can read
My personal wiki lives in Git and is backed up to GitHub every six hours. When
Hermes remembers a topic, the memory is not trapped in an old conversation or
a database I cannot inspect. It is also a page I can open, edit, diff, and
restore.
Work that leaves the chat
External tools connect through MCP. One example is a small Workout Bridge: my
AI coach can prepare a workout and send it to Apple Watch. The assistant is
useful because the conversation can end in a real system, not because the
answer sounds complete.
Staying online is a reliability problem
A terminal process that works while SSH is open is not a 24/7 assistant. The
gateway needs to survive disconnects and restarts, expose its state, and leave
logs that explain a failure.
The small proof that matters first: the gateway is active and Telegram is connected I run the gateway as a user-level systemd service and enable linger so it keeps
running after I log out. Three commands cover most first checks:
bash hermes gateway status hermes doctor hermes status --all Timed work introduces a second problem: replay. A delayed delivery or server
restart can cause the same job to run twice. Any job that changes another
system should be safe to repeat and should record what it already changed.
Keeping the process alive is only the first reliability layer.
Control is part of the system
An agent with tools is closer to a remote work computer than a chat app. The
permissions and approval boundaries matter as much as the model.
My operating rules are simple:
I want the agent to prepare the work. I want to stay in control of actions
that are expensive, public, or difficult to undo.
Build the smallest useful loop
Copying the full setup on day one creates more maintenance than value. The
first version should prove one complete loop: a request from the phone, useful
work on the server, and a result back in Telegram.
Step 1. Prepare one ordinary server Use a recent Ubuntu VPS and a non-root user with sudo access. Install Hermes,
then verify the executable before configuring anything else:
Step 2. Prove the agent locally Connect one model provider and make a request that produces an observable
result, such as reading disk space or creating a small file. Do not add
Telegram until the local loop works.
Step 3. Make Telegram survive SSH Create the bot with BotFather, keep its token secret, and install the gateway
as a background service. Enable linger so the user service remains active
after logout:
bash hermes gateway setup hermes gateway install hermes gateway status sudo loginctl enable-linger $USER Leave SSH, wait a minute, and message the bot. If it does not answer, inspect
the service and logs before reinstalling the system.
Step 4. Add one job worth waking up to Start with a read-only scheduled job whose result is easy to check. Add
Git-backed memory and external tools only after that first job is reliable.
The boring costs are the real costs
There are two direct costs: the VPS and the model provider. Token usage grows
with the choice of model and the frequency of scheduled jobs. The less visible
cost is maintenance — updates, expiring logins, logs, permissions, and jobs
that need to be checked when an outside service changes.
The useful version is not the assistant with the most tools. It is the one
that does a small number of jobs reliably, shows its work, and knows when to
wait for a person.