Case Study: Automating a Company with Self-Hosted Hermes Agents
How we automate our own company with a fleet of self-hosted AI agents: one per function, reachable from Telegram, running scheduled briefs and skills on cheap private boxes, with our data and keys never leaving.
Most AI is something you open. You go to a tab, type a prompt, read an answer, and close it. That is useful, but it is not leverage, because the work only happens while you are sitting there driving it. We wanted the opposite: agents that run parts of the business on their own, that we can reach the way we reach a colleague, and that keep working when we are asleep. So we built it for ourselves first, a fleet of self-hosted Hermes agents, each owning a slice of the company.
This is not a story about a productivity number; it is a story about how the setup is built and why we built it the way we did. The idea is simple to say and specific to engineer: give each business function its own always-on agent, talk to all of them from Telegram, let them run scheduled work without being asked, and keep the whole thing on infrastructure we own.
The problem we set out to solve
The problem was not a lack of AI. It was that AI sat in a tab, waiting to be driven, instead of running anything on its own.
So the brief, set by us for us, was to make each agent feel like a teammate: it has a job, you can message it any time, it does scheduled work without being asked, and it lives somewhere private.
One pipeline: how work gets done
Whether a task is triggered by a message you send or by a schedule that fires at dawn, it runs through the same path. The agent receives the trigger, reasons with a language model, calls a skill to actually do something, and delivers the result back to where you already are.
One agent per function
The setup is a fleet, not a single assistant. Each agent owns a function and has only the skills and context that function needs: one watches the markets and writes a trading brief, another handles business operations, another focuses on marketing. Keeping them separate is deliberate. A narrow agent with the right tools and a clear job is more reliable and easier to trust than one sprawling assistant trying to do everything, and if one needs different access or a different cadence, it does not affect the others.
Always-on, not on-demand
The thing that makes these agents feel like teammates rather than tools is that they work without being asked. Each agent has a scheduler, so it can run a job at a fixed time and deliver the result before anyone is awake. Our trading agent, for example, compiles and sends a market brief every morning at seven, straight to Telegram, with no one opening anything. That single shift, from "ask and receive" to "scheduled and delivered," is what turns an assistant into an operator.
Talk to it like a teammate
Reaching the agents had to be effortless, or they would not get used, so the interface is the one we already live in: Telegram. You message an agent like you would message a person, and it answers, runs the skill, or reports back. There is also a private web dashboard for each agent for the times you want a fuller view, but the day-to-day is a chat thread on a phone. Putting the agents where work already happens is what made them stick.
Under the hood
The Hermes setup is real infrastructure, not a prompt in a chat window.
- One self-hosted agent per function, each a small Docker stack on its own inexpensive box, so a single agent failing or restarting never touches the others.
- A gateway that handles both inbound Telegram messages and a cron scheduler, so the same agent responds to you and runs jobs on a timetable.
- A language model reached over an API (OpenRouter), chosen for fast, non-reasoning responses that keep a chat feeling instant.
- Skills, the tools that let an agent actually do work, from compiling a market brief to logging a record into another system, rather than only talking about it.
- A private dashboard per agent, exposed through a secure tunnel with authentication, for the moments a chat thread is not enough.
- Data and secrets that live on the host, never on someone else's platform, because automating a company means trusting these agents with real keys.
Why weeks, not quarters
Standing up a fleet like this sounds like a big infrastructure project. It is not, because the build follows the same process we use on every project: a tight scope, an agent-assisted build, and a deployment that is monitored from day one. We break the method down in how we ship custom apps in weeks, and the build-versus-buy logic in build vs buy: when a custom app wins.
What we would tell anyone considering this
A few honest lessons from building it for ourselves.
- Schedule beats prompt. The leverage is not a smarter answer when you ask; it is useful work that arrives when you did not. Put the agents on a timetable.
- Narrow agents are trustworthy agents. One agent per function, with only the tools that function needs, is far easier to rely on than one assistant that does everything adequately.
- Own the box. When agents hold real keys and act on the business, self-hosting is not a preference, it is the difference between automating your company and renting that ability from someone else.
If you want your business functions run by agents instead of operated by hand, talk to us. We will look at where your time actually goes and show you which functions an always-on agent could take over before we build anything.