Hermes skills: When does a useful workaround become a rule?

A new teammate is told to prepare a report “the same way we did last time.” One person remembers the template, another remembers a review step, and someone else recalls that the data source changed midway through the project. The agent assigned to that report faces a similar problem. It may have completed the task once, but repeating the outcome is not the same as knowing which parts of the procedure still apply. A stored conversation is evidence of past work, not necessarily a dependable operating method.

Hermes Agent is an open source agent runtime from Nous Research. It connects a model to tools and gives teams ways to keep procedures, memory and separate profiles around recurring work. One of those mechanisms is the skill: a document the agent can load when it encounters a relevant task. That sounds simple, but it raises a serious question for an organization. When a workaround succeeds once, what has to happen before it becomes a rule other agents can follow?

A skill is not a transcript in disguise

In Hermes, a skill describes when it applies and how to carry out a particular kind of work. Supporting reference files can hold details that only need to be read when relevant. This keeps every session from carrying a complete manual in its initial context. It also gives the agent a path back to a documented method instead of asking it to reconstruct yesterday’s reasoning from fragments.

None of this makes the contents automatically authoritative. Suppose an operations team writes a skill for turning incoming requests into issue records. The sequence might say to identify the request, determine the affected service, check for an existing record and then create a new one. That is useful. If the document contains an obsolete service name or assumes an API field that no longer exists, however, the agent can now make the same error consistently. Repeatable work is easier to inspect, but repetition alone does not establish correctness.

The risk becomes clearer when an agent can edit or create skills itself. A temporary fix for one incident could silently turn into the default procedure for future incidents. A better skill states its preconditions and stopping points. Instead of prescribing a command whenever an error message appears, it can say what evidence to inspect first, which conditions make the command appropriate and what observation would count as success. That turns a remembered action into a testable method.

Two runs of the same publishing task

Consider a publishing team whose agent drafts technical articles in two languages, checks internal links and pushes the result to a repository. During one run, the link checker finds a broken link. The agent corrects the path, reruns the check and delivers the article. There is a useful procedure to retain: verify that the target article exists, choose the path for the right language and run the link check before delivery.

The list of links in that day’s article is not the durable part. Posts move, new posts arrive, and a valid link can become stale. A skill that remembers yesterday’s particular links rather than the rule for checking links will decay quickly. It should distinguish drafting a file, validating it locally, sending it to the repository and checking the destination. These are separate claims. The checker returning zero does not prove that the latest version reached the remote branch, much less that the public site finished deploying.

Now imagine the next run starts in a profile without repository write access. The agent may still draft and validate the files. It cannot honestly report that publication succeeded. A skill cannot grant permission that does not exist; it can specify where to stop and how to describe the incomplete work. In an earlier Hermes article, we separated a scheduled run from a delivered result. A good skill makes that distinction part of the procedure rather than leaving it to memory or optimism.

Who gets to change the method?

Hermes documentation describes skills as files that an agent can create and modify, while profiles keep their own configuration, sessions and skills apart. These are useful boundaries for different roles. An editorial agent need not inherit the support team’s procedures. But a separate directory is not a review policy. If a support agent discovers a shortcut, it should not automatically become production guidance for every other agent with access to the same service.

Assigning ownership is more important than naming the document. Who checks a skill after an external API changes? Who decides whether a newly written step is valid for production? A team might let an agent draft improvements but require review before those improvements are used in higher risk jobs. Editing a procedure and activating that procedure broadly are different operations. Combining them can turn a minor correction into an unnoticed change in what the organization permits its agents to do.

Scope should be readable at a glance. State which tasks the skill covers, which environment it assumes and what missing information should halt execution. If several skills have similar descriptions, an agent may select a plausible but wrong procedure. Precise descriptions reduce that ambiguity. Credentials belong in controlled secret storage, not in the skill text; documenting the steps to use an integration is different from embedding the key that unlocks it.

Test the failure path first

A small, reversible task is enough to test a proposed skill. Write down an input, the expected artifact and the evidence of successful delivery. Run the task with the method available and observe which decisions it changes. Do not stop at a polished output. Remove a required input, let a validation step fail or use a profile without the necessary permission. Does the agent pause and report the gap, or improvise an unauthorized path to completion?

After the trial, check whether the skill captures a general rule or a frozen snapshot of one day’s result. Instructions that depend on moving infrastructure should include a way to inspect current state. A documented owner and a review note make later changes easier to trace. If a new version causes problems, the team can identify which assumption changed and revert that procedure instead of searching through old conversations for the moment the agent “learned” it.

Hermes skills carry operating knowledge between runs, but the questions of who may revise that knowledge, which role may apply it and who accepts the outcome sit above the runtime. To make those responsibilities explicit, agentic-organization is a self-hosted, file-based platform for managing AI agents as first-class members of the organizational chart.