Three things I’d do differently
You’ve built the thing. Hetzner box, Tailscale, SSH bound to the tailnet, Telegram bot wired, Hermes installed, a persona that sounds like a person, a model chosen for the workload. It works.
So here’s what I’d change if I were standing it up today. Not regrets, not “you should have done it my way.” Three specific things that, knowing what I know now about how this build actually behaves in daily use, I’d do differently. One concrete action per lesson.
Lesson 1: Generate a persistent Tailscale auth key before the first reboot
The tailscale up command finishes and your box is on the tailnet. You move on. Six weeks later there is a power blip, a provider maintenance window, or you manually run tailscale down to test something. When the box comes back, Tailscale is up but not connected. The one-time auth key from the initial tailscale up does not persist across restarts. You are at the Hetzner console, or SSHing from a specific IP you have since rotated off, to run tailscale up again and re-authenticate via the browser link.
I made this mistake once. The action is to generate a persistent auth key from the Tailscale admin panel before the box goes to sleep for the first time. In the admin console, go to Devices, find your machine, and generate an auth key with reuse enabled. Store that key in a startup script that fires on boot:
sudo tailscale up --authkey=<your-authkey-here>The box reconnects to the tailnet automatically after any restart. No manual tailscale up, no browser link, no console. This is the operational difference between a box you manage and a box that manages itself.
Lesson 2: Decide on the model strategy before the first token is spent
When I first set this up I treated the model choice as a tuning step. Something I’d refine after seeing how the agent behaved. That meant I spent real money on heavier models before I understood what I was actually asking the agent to do. The back-and-forth chat models, the ones tuned for conversational turns, are expensive at agent volumes. The workload I have is not a chat workload.
The action: before you send your first message to the bot, decide what the agent is actually doing. If it is answering questions and summarising things, a lighter chat-tuned model is fine. If it is running tools in sequence, calling subagents, holding state across long sessions, and producing structured output, that is a different workload. Shop for that workload, not for the general-purpose leaderboard.
I ended up on MiniMax M3 as the default, with a lighter fallback and OpenRouter still in the chain. The model fits the agentic shape of the work. Cost followed from fit, not the other way around. Decide the workload first.
Lesson 3: Wire the calendar integration on day one instead of three months later
The most useful thing this agent does, the one I reach for multiple times a day, is answer “what’s on my calendar today.” I knew this was coming. I kept telling myself I’d add Microsoft Graph or the Google Calendar integration “later.”
Later was three months.
The action is straightforward. Add the calendar credentials to the profile’s .env on the day you set up the Telegram bot, not at some future point you are not yet motivated to reach. If the calendar integration does not exist in your version of Hermes yet, the configuration block still goes in the .env with placeholder values. It is a one-line addition and it means the moment the feature ships, you are done. No retrofitting, no “I should have.”
The calendar question is the one I ask most often. Everything else follows from having it working.
What this build became
The headline feature, the one I reach for ten times a day, is the calendar check. “What’s on my calendar today?” answered in under two seconds, from Telegram, from anywhere, without a browser.
The second layer is quick answers. A fact I need, a conversion I forgot, a command I could have run in a terminal but did not want to switch windows for. The agent replaces a search engine for a specific class of query, the kind where I already know what I am looking for.
The shape that surprised me is the background-agent pattern. Most interactions are not synchronous. I send a message, the agent acts, I hear back later. “Check my calendar every morning at 7:30 and text me if there is anything before 9am” runs without me thinking about it. The agent is not a chatbot. It is a person I am delegating to.
That is what the build became. Not a demo, not a proof of concept, but a piece of infrastructure I stop noticing and start trusting.
Where this leaves you
The cluster is complete. You have a working personal Hermes agent, a Telegram bot you can message from anywhere, a persona that reflects how you actually work, and a model chosen for the workload in front of it. The box will stay on the tailnet after reboots. The SSH port is not exposed to the public internet. The gateway starts clean.
Future pieces in this publication will cover scheduled jobs and cron triggers, the Starter Kit (a one-install personal briefing agent that emails weather and priorities on weekday mornings), and growing a single profile into a team of subagents. None of those are in this cluster. This one was about standing the thing up and getting it real.
Michael Short is the founder of The Agent Files.