In February, Nous Research launched Hermes Agent. It reached 100,000 GitHub stars in seven weeks. As of May 2026, it processes 224 billion tokens per day on OpenRouter, making it one of the most actively used agent frameworks available.
The core of its growth: a self-improving mechanism. After completing any task involving five or more tool calls, the agent analyzes the workflow and saves it as a skill file automatically. No prompt required. Existing skills update themselves based on new context. The more you use it, the more it learns your way of working. That experience gap drove the word of mouth.
As more people began using Hermes Agent as a personal assistant, a natural question followed. What happens when it is deployed across the whole team?
When Self-Improvement Becomes an Enterprise Risk
According to McKinsey's State of AI 2025 report, only 23% of organizations have successfully scaled agentic AI into live production environments. The most common failure point: governance. Organizations deployed agents before building the structures to control them.
The more an agent self-improves, the sharper this problem becomes. The target of control keeps shifting. Hermes Agent is powerful for individual use. At the team layer, that same capability becomes a source of risk. That is the conclusion one Enhans engineer reached after running Hermes Agent directly in a production context.
The Agent's Evolution Is Unpredictable
Hermes' self-improvement almost always moves in a better direction. The problem is that "better" is defined by the agent's own judgment.
In a shared team environment, one person's usage context can influence the skills that others rely on. If non-technical team members use auto-generated skills without understanding how they work, tracking where the agent is evolving becomes nearly impossible.
The deeper issue: Hermes Agent does not currently include Role-Based Access Control (RBAC) designed for enterprise environments. Basic controls like allowlists and admin/user distinctions exist. These operate at the command level. Granular, role-based control over skill creation, memory storage, and tool execution across the organization is not there.
The self-improvement loop makes this worse. When the agent creates and updates skills automatically, those changes are not tracked at the team layer. There is no way to see who created which skill, or what was stored in memory and when. For an organization, it becomes a black box. Uncontrolled change is a risk on its own.
Costs Are Unpredictable
Hermes' self-improvement process runs additional computation in the background. Every time the agent analyzes a workflow, creates a skill, or updates one, it consumes tokens.
When one person uses it, they feel the cost and can adjust. When the same system is deployed to a team, multiple people run sessions simultaneously. Each person's self-improvement loop runs in parallel. With external API keys, there is no reliable way to forecast spend.
Infrastructure with unpredictable costs is difficult to get approved by any budget owner. Several organizations that encouraged maximum token usage found unexpected invoices at the end of the month and pulled back.
Audit Trails Are Missing
Which tasks did the agent perform? Which tools did it call? Where did the results go? Can any of that be verified after the fact?
For an individual user, those questions matter less. They ran the session and can check it themselves. At the organizational level, the stakes change. Without audit logs, tracing the cause of a problem is impossible. If there is no record of who gave which instruction and how the agent executed it, that agent operates outside the organization's accountability structure.
Hermes vs. OpenClaw: A Different Question
The comparison that comes up naturally at this point: Hermes Agent and OpenClaw.
Both are open-source agent frameworks active in the same communities. Both are used in real work environments. The question of which to use is a reasonable one.
They are designed around different philosophies and optimized for different environments. Neither is a better version of the other. One Enhans engineer ran both in parallel and drew clear conclusions about where each one fits.
How to Use Them Together
One engineering team at Enhans runs both agents on separate layers.
OpenClaw (team agent). This engineer's team uses OpenClaw for internal onboarding Q&A and development operations support. It answers based on approved internal guides, policies, and FAQs, producing consistent responses. Non-technical team members in PM, QA, and CS can query infrastructure status and data conditions in natural language, reducing the bottleneck on individual engineers. It is predictable. It does not drift. Access permissions are managed by the organization.
Hermes Agent (individual agent). At the individual layer, Hermes handles personal tasks that do not belong in a shared system. Debugging hypothesis mapping, identifying failure candidates, and personal work log management are the primary use cases. A common workflow: Hermes organizes the problem and possible causes, then hands the diagnosed issue to Codex or Claude for the code writing step. Even when skills are auto-generated, the engineer reviews and understands them before use. That is what keeps the risk manageable.
Three Checks Before Team Deployment
Can the team track and approve every change the agent makes to itself? Non-technical team members need to be able to follow how auto-generated skills are evolving. If they cannot, the organization is running an agent it cannot observe.
Can token costs be forecasted and capped? If there is no self-hosted model or usage limit in place, team-wide deployment creates budget exposure.
Can the agent's action history be verified after the fact? If there is no way to trace what a shared agent did, that agent sits outside the organization's accountability structure.
All three need a clear yes before team deployment is worth considering.
Deployment Design Comes Before the Deployment Decision
Hermes Agent is powerful at the individual layer. Moving that strength to the team layer requires answering several structural questions first.
The deciding factor for AI agent adoption comes down to one question: can the organization control this? Building the structure to answer that question comes first. Which agents belong at the team layer. Which belong at the individual layer. Where the boundary sits.
in solving your problems with Enhans!
We'll contact you shortly!