Building an Enterprise-Grade Agent OS on Hermes: 200+ Automated Tasks a Day (English Translation)

Translation notice. This is an English translation of the Chinese X article by @aronhouyu, “基于 Hermes 打造企业级 Agent OS” (“Building an enterprise-grade Agent OS on Hermes”). All credit for the ideas and the original content belongs to the author. The diagrams are my own English redraws of the author’s original figures (the originals are Chinese-labelled screenshots hosted on X). Please read the original for the author’s own artwork. Two notes: the original numbers its sections inconsistently (it has two sections numbered 4, and section 7 appears before section 6); I have kept the original numbering and order. The source text I could retrieve is also cut off mid-sentence at the very end; I translate it as far as it goes.

For the past four months, our team has been running most of its automated business on a Hermes-based architecture. That covers collecting, organizing, reporting and tallying information, making decisions, passing information along, and collaborating across departments and across companies.

Even today, I still think a Hermes-based Agent is an application architecture with a very high degree of autonomy. This is where I need to thank Hermes for being open source (Hermes, throw some money my way!).

As of today, our Agent handles 200+ automated tasks every day. All of it runs on one Mac, a few external servers and Hermes Agent, which is why this article exists. Beyond Personal AI Agents, I hope you will also pick up a working understanding of the design, architecture and application layer of an enterprise Agent OS.

1. Technology choice: why Hermes?

Even now that Agents are everywhere, Hermes is still one of the most complete autonomous Agent runtime frameworks:

It ships with persistent memory in MEMORY.md and USER.md, a self-evolving skill loop built on SKILL.md, and a unified multi-platform gateway. That includes Telegram, Slack, Feishu, Discord, plus Cron scheduled tasks and parallel scheduling of sub-Agents.

In plain terms: it works out of the box, and you can deploy several cooperating Agents across platforms on the same server.

But if you take this setup, built for a personal Agent, and push it straight into a 300-person company spanning operations, procurement, inventory, warehousing, pricing, finance, sales and customer service, the system usually cannot take the load.

I have also looked at many Agent products recently. Their approach is all built on a personal Agent wrapped in a shell for different scenarios. They can carry out a few simple work tasks, but in essence they are not enterprise-grade Agent systems at all.

So my own view is that, for now, the answer is still Hermes.

2. What is a real enterprise Agent OS?

An enterprise Agent OS is, in essence, not a handful of Agents that can do small jobs.

My understanding is that it is closer to a multi-user system that manages many things centrally: multiple roles, multiple organizations, permissions, real-time business information, knowledge and memory, security, and more.

Put simply, if the purpose of a Personal Agent is how one person uses AI to be more efficient, then an enterprise Agent solves a different problem. With dozens or hundreds of people collaborating across departments, how do humans and Agents string workflows together within one shared business, and how does the organization compound its accumulated experience?

So there are several prerequisites:

• Permissions and isolation: You cannot let every Agent scan local files or read other people’s files. If Sales could read Finance’s files, that would be a real headache. Cross-department collaboration also has to complete asynchronously after verification, and prompt-level security alone is a very low bar. So Agents must be grouped and given distinct permissions at the root.
• Shared business state: Share data such as the real-time business ledger, and accept content from multiple channels, with the goal of lowering high-frequency operating costs.
• Organizational memory: In the end it is still RAG + Markdown. Human speech is sometimes forgotten, and employees also run into memory loss caused by context compression during use. So you need organizational memory, with the commonly used Skills and rules kept in one single place.
• Control panel: Every system needs people to operate it. For the company’s most critical data, such as GMV and keys, who can modify and who can view matters a great deal. We also add a sandbox layer, because external content must be isolated and cleaned in a sandbox before it enters the Agent system, to keep local data safe.
• Permission mounting: Here is a small pitfall we hit before. Permission mounting becomes something like dynamic routing: when Finance opens it they see only Finance, and when Sales opens it they see Sales. Their respective Agents also have no ability to change their own permissions on their own, cross departments, or spawn sub-Agents.
• Asset accumulation: For a company, anyone can be replaced; only the data from operations is what matters most. For example: if Claude’s risk controls are looser today, use Claude; if DeepSeek is cheaper tomorrow, switch immediately. Model providers overtake and catch up with each other within a few months, and compute itself keeps getting cheaper. They are just token suppliers, fuel. Decouple from them rather than binding yourself to any one.

Only workflows and memory are the core assets that become more valuable the more you use them.

Based on these requirements, we can lay out the corresponding transformation architecture and its contents.

3. Hermes-based enterprise transformation architecture

Once the requirements of an enterprise Agent OS are clear, the next question is how to adapt the current Hermes framework.

As everyone knows, Hermes today is still designed around single-user Profiles.

So our transformation approach is to build a shared business workspace on top of Hermes’s reasoning loop, and to lay an enterprise control panel and permission gateway underneath it.

Permission groups and cross-department asynchronous collaboration

At the bottom layer we use Hermes’s multi-Profile mechanism, splitting different Agent roles by department and function:

• Personal Agent: its permissions are tied to the individual employee; the users are different employees such as Zhang San and Li Si.
• Department Agent: Sales, Procurement and so on. Users are mostly AI plus group chats, private chats are strictly forbidden, and each has its own independent data directory.
• Cross-department collaboration: when Sales needs Finance to check on a payment received, the control panel verifies the permission request and issues an asynchronous Agent-to-Agent task to the Finance department Agent. The Finance Agent does the work in its own isolated environment and passes only a simple, desensitized status (payment received / not received) back to the Sales Agent.

The benefit: no sensitive information is exposed, and different Agents can still collaborate.

State sharing

Whether it is the email channel, product returns and exchanges or production workflows in group chats, or orders from front-end stores, an Agent extracts it implicitly and writes it into the same back-end database.

Agents on different business lines only need to read the database to wipe out WeChat documents, verbal notices and the like.

Memory layering (RAG + Markdown)

To solve the memory loss caused when short conversations are compressed by context, memory needs to be split into two parts.

Markdown holds business knowledge, for example who the suppliers are, how to handle reports, how to produce reports, how to find information, and so on. Markdown files are compact in size, highly condensed and editable by humans. An Agent can read them in a targeted way while working, and they can even be injected directly into the question, so most work-derived knowledge settles into Markdown.

RAG: once hundreds of people have been running for a few months, you simply cannot write everything into Markdown. So RAG mainly handles the following kinds of problems:

• For example: “On the 12th of last month, Procurement and Operations discussed in the group chat why Supplier A’s payment terms were suddenly changed to 30% prepayment?” The full story of one specific day and event does not go into a general SOP, but after an employee forgets it because of context compression, RAG can find it by semantic search in the chat history. (Feishu actually does this part very well.)
• For example: hundreds of historical contract PDFs, customers’ original complaint wording in customer-service tickets, the raw minutes of every weekly meeting. These files are too large and messy, so they are cut into chunks and indexed, then the relevant passages are retrieved on demand when a specific question comes up.
• For example: one day you meet a really rare, bizarre incident that a veteran employee handled once three months ago. That kind of low-frequency and thorny problem will surface in RAG through similarity matching, and you can reuse the answer directly.

4. Hands-on rollout: running an enterprise Agent OS from 0 to 1 on Hermes

Starting from the MVP principle, the biggest mistake is to lock yourself away for three months before shipping; nobody can wait that long these days.

So the deadline for execution is: get the Agent running within one week, and cover the Agent architecture of two departments first.

Step 1: Get a server or a Mac

• Hardware choice: To start light, use a cloud server with 4 cores and 8 GB of RAM or more (Alibaba Cloud / Tencent Cloud is fine), or put a Mac on the company’s internal network.
• Core principle: The server only runs the gateway, the database and sandbox scheduling. It does not run local large-model weights; inference all goes through external APIs, so there is no need to buy an expensive GPU.

Step 2: Install Hermes Agent and set up role Profiles

For the core Agent base, use Nous Research’s open-source Hermes Agent directly. It supports Linux, macOS and WSL2, is open source under the MIT license, is model-agnostic, and comes with memory, a Skills loop and Cron scheduling:

• Open-source repo: NousResearch/hermes-agent
• One-line install: curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
• Enterprise directory split (key): After installing, don’t let everyone use the default home directory. Instead, create separate Profile directories per department and per employee (/data/hermes/dept/sales, /data/hermes/dept/finance, personal/zhangsan).
• Combined with gateway routing, a department Agent is bound only to group chats and private chats are disabled in code, so Sales and Finance are fully separated right down at the physical directory level.

Step 3: Plug in the essential open-source components

Hermes alone only manages a single Agent well. To get multi-department collaboration, a shared ledger, RAG memory, hot model switching and hard permission limits, I suggest directly reusing the most mature open-source components on GitHub and assembling them:

As shown in the figure.

4. How do you actually move the business forward?

Since everything so far has been planning, the actual rollout still uses the old method.

Go and find the department heads, and ask them some very practical questions: in their daily work, what are the actions that are repeated regularly or three or more times a day, and what do they need to chase other people for repeatedly?

This is where the friction in communication and work lives. The information already exists, and the way of handling it is much the same each time. What really takes time is pulling scattered pieces of information together so that an Agent can drive things forward.

For example: Sales has a screenshot of a customer’s payment and has to ask Finance whether it has arrived; after Finance confirms, they notify the warehouse; the warehouse finds the order number is incomplete and comes back to Sales. Nobody in this process did anything wrong, yet one order still gets passed back and forth several times.

Most of this is part of a workflow, so it can be judged on four points:

• Does it happen frequently?
• Is it worth doing?
• Can it be reasoned backward from data?
• If it fails, which employee takes over (takes the blame)?

There is also some middle-management work in the enterprise. That is really decision-making, analysis, judgment, and reporting various reports to superiors every day (you know who you are).

Most of that kind of work can also be turned into Agents.

5. A demo of the concrete permission setup

Hermes’s Profiles can manage configuration, memory, sessions and so on by themselves. But if the directories are separated, some permission changes and secondary development are needed.

We generally split concrete permissions into several layers:

• Employee identity: who initiated the task, which company they belong to, what role they currently hold, whether they have temporary authorization. All of it is confirmed by the authentication and personnel systems.
• Agent identity: the Sales Agent has its own service identity, and so does the Finance Agent. They can carry out tasks on behalf of authorized processes.
• Tool permissions: tool permissions can actually be split further, but for now it is relatively simple. Most work does not read the database directly; instead it is given an interface to a business tool plus a snapshot, for example order payment status or this task’s progress. This eases the load on the database a little.
• Sub-Agents: sub-Agents are really the same: their data scope and the tools they may call are all handled through a simple dispatch middleware.

7. Task queue

When there are a few dozen tasks a day, you can still re-run them after a failure. But once the volume grows to hundreds, a problem in the automation of any one link will affect other departments.

So this part really comes from stepping in potholes: you need a complete task lifecycle.

The full lifecycle of a task is:

This is not only for humans to read; it has to be readable by Agents too, so splitting it finely is unavoidable…

States such as “Awaiting verification” exist so that the Agent knows it needs to go and verify the result.

6. Skill control and updating

We also stepped into potholes with Skills.

Most employees, whatever Skill or content is involved, just start chatting. When the chat goes wrong, or something breaks after context compression, they start complaining: “This piece of junk is useless, slow, and stupid.”

To deal with this, we came up with a simple approach: build one big Skill repository.

Every time, update and distribute automatically. For example, today Zhang San’s Sales Agent learned to calculate reports automatically from data. Then after work in the evening, a Skill Agent collects all the chat content of Zhang San, Li Si, Wang Wu and the rest, sorts it into categories, and produces different Skills. It commits them to the repository and distributes them back, so every Agent can install and update automatically.

Every update also has a version record (thanks to version records, and to the Markdown above).

So this part is really a continuous process of self-evolution, a continuous loop.

That is basically it. A relatively simple, autonomous, controllable, multi-entry and centrally managed Agent framework can be stood up this way. For the rest, just have your own Agent read this document and give you the hands-on details.

None of this is actually hard, and it closely resembles internal enterprise management before. It just has more freedom and flexibility, and it can connect to different IMs.

For example, my team has now integrated Slack, an external ERP, mini-programs, Feishu and more onto a single server.

It feels great, one…

(The source text ends here, cut off mid-sentence: “爽的一” (“it feels great, one…”).)

---

Translated from the Chinese original by @aronhouyu. Diagrams redrawn in English for this translation.