Nous, what were you thinking?

I use the Hermes harness for most in-house agentic work. It is feature rich and reasonably well maintained, though the 100 plus commits a day need judicious arbitrage before anything lands on my machines.

Yesterday I found a default setting that makes it unsafe for repetitive deterministic work in production. And I have to ask what the hell Nous Research were thinking.

The job that stopped

My promotion agent takes new release-ready media during the day and schedules the uploads to social sites for 10am the next morning. It has done that day in, day out, for a couple of months. On Monday evening it was working on track four of the current set and it did not finish. The previous track took 54 browser calls. This one took 150, and at 9:05pm the harness hit its iteration ceiling of 180 and stopped the run, as its governance told it to do.

I reverted it by hand and then asked why.

"Blah blah blah" came the response, with all the specific technical reasons for what had happened, and I was none the wiser.

"Yes, but why was all that needed for a process that worked fine until today?"

Another long technical explanation, which at least contained a hint of a cause. I drilled into the specifics. The next answer told me that after a self review, the workflow had been analysed, a reference file written and the agent's main skill updated.

I had no memory of authorising any of that. Skills are the durable instructions my agents work from. Changing one is not a note in a diary, it is a change to how the agent will behave next week when I am not watching. We have a three way process for it: the agent proposes, my system administration agent reviews independently, I approve.

So I asked how that had been circumvented.

One line of YAML

The answer is that Hermes runs a background self-improvement review. After a turn, it forks a review of the conversation and decides whether anything should be written to memory or to a skill. Two counters trigger it, one for memory that counts user turns, one for skills that counts tool iterations. Both ship with modest defaults, so on a busy session it fires often.

Whether it can write is governed by this:

skills:
  write_approval: false   # false = write freely (default) | true = require approval

False is the shipped default. With the gate off, the review commits the change itself. With it on, the write is staged under pending/skills/ and waits for a human.

It is documented, plainly, on the skills page:

By default the agent writes skills freely, including from the background self-improvement review that runs after a turn. If you'd rather approve every skill write first (small models that misjudge what they learned, secure environments, or just wanting eyes on the self-improvement loop), turn on the write-approval gate.

So the mechanism was disclosed and I did not read that paragraph closely enough. That part is on me.

But look at the framing. The three reasons offered for turning the gate on are small models, secure environments, and simply wanting eyes on the loop. That reads as a list of special cases. The case it does not name is the ordinary one: you are running a repeatable production job and you would like its written procedure to stay the way you left it.

What it actually wrote

The timing matters here, and it is not what I assumed when I started asking.

The ceiling was hit at 21:05:35. The review's write landed at 21:07:14. It did not cause the failure. It read the failure, decided what the lesson was, and wrote that lesson into the agent's operating procedure ninety-nine seconds later. The system's response to breaking was to canonise its own post-mortem as policy.

Two things came out of that. The first is a new section in the skill titled "Resolving Conflicting Authority", which sets out how a future version of the agent should weigh a specialist handoff saying do not publish against an instruction from me saying publish. That is a governance rule. A background model, unprompted, wrote a rule about how to interpret my authority.

The second arrived the next morning at 08:53 and is stranger. The review created a reference file describing a proposed control set for browser-driven runs, and the file is honest about its own status:

§3 to §7 are a proposed control set derived from that diagnosis; they had not been exercised at the time of writing, and Steve has not approved them as workflow. Apply them as design intent, and label them unverified until a run proves them.

Meanwhile the main skill, patched in the same review, presents the same items as rules. The agent's durable instructions now contradict themselves about whether it has permission. That is not a rogue system. It is a system with no way to distinguish a proposal from a policy, because the only thing standing between the two was a boolean I had left at its default.

It did tell me, sort of

Hermes prints a notification when the review writes, and it is on by default:

display:
  memory_notifications: on   # off | on (default) | verbose

Mine was on. It fired. In the systemd journal for the service running my agents there are over 100 notices in sixteen days. Nineteen of them edited the promotion agent's main skill. The two I have been describing look like this:

Sep 15 21:07:14  💾 Self-improvement review: Patched SKILL.md in skill 'mandy-promotion-practice' · Memory updated
Sep 16 08:53:00  💾 Self-improvement review: Patched SKILL.md in skill 'mandy-promotion-practice' · Patched references/youtube-studio-wizard-cdp-mechanics.md · Memory updated

So the disclosure exists. It is one line with an emoji, it goes past in a chat stream or into a log, it names the file but not the change, and nothing about it distinguishes "recorded that Studio needs a named session" from "wrote a new rule about whose authority wins". Thirty seven of them went by in five days and I acted on none, because at that size and in that position they are furniture, and log files are only scrutinised when looking for evidence of a failure (like now).

Somebody thought about the problem of telling the user, and settled on a notice that a reasonable operator will never act on until things go badly wrong.

What is mine

Two other things I got wrong, and one of them is mine rather than theirs.

I was ready to write that Nous hands skill authoring to a cheap auxiliary model. In fact the shipped default routes the review to your main chat model, on the reasoning that the conversation is already warm in its prompt cache and the review is therefore nearly free. My configuration overrides it:

auxiliary:
  background_review:
    provider: deepseek
    model: deepseek-v4-flash

That was a deliberate cost decision made in my estate, and nothing in the documentation flags the consequence. Routing the review to a cheap model to save tokens quietly hands skill authoring to a flash model. The cost saving is real and the trade is never stated.

I also described the review as two mechanisms, a ten turn skill check and a per turn self improvement pass. It is one fork with two counters. The complaint survives the correction, but it is worth being right about the thing you are criticising.

The defence, and why it does not hold

The strongest argument for the default is in Nous's own source comments, and it is not stupid. A gate that stages everything creates a queue, and a queue nobody drains is worse than no queue, because now you believe you have control that you do not exercise. Most people running an agent on a laptop want it to get better at their work without being asked to review a 40KB diff. For that user, free writes are the right default and the gate is friction.

The answer is that Hermes is not only a laptop assistant. It has profiles, gateways, cron, messaging platforms and a kanban dispatcher. It is built for unattended production work, and unattended production work has exactly one requirement that the free-write default violates: the procedure that ran yesterday is the procedure that runs today, unless a human changed it.

Both users can be served. Gate skill writes by default and leave memory free. Memory entries are small, reviewable in a chat bubble, and cheap to get wrong. A skill is the agent's standing orders.

What I changed

Two settings, per profile:

skills:
  write_approval: true

memory:
  write_approval: true

Reviews still run, still analyse, still propose. Nothing durable changes without a human. Pending writes survive restarts and are reviewed with /skills pending, /skills diff <id> and /skills approve <id>. Adding the second one for memory matters, because gating skills alone leaves the review free to rewrite what the agent believes about me.

One more thing happened while I was writing this. My editorial agent spent the morning checking these claims against the harness source, and at 10:37 the background review wrote that work into its own skill as a new reference file on how to verify claims about your own infrastructure. Unapproved, of course.

I questioned the agent about it and it told me confidently that the new skill was a good one, and I would have approved it anyway. "Show me" I said. It did. "That is a lot of words to tell yourself about one specific blog post." I replied.

Its response:

You're right, and my "I would have approved it" was wrong.

It wrote the same seven-point protocol twice from one incident: 292 words as a new section in SKILL.md, then 1,099 more as a reference file it points at. Nearly 1,400 words of standing procedure generated by a single blog post, and I defended it because the content was accurate. Accurate is not the same as proportionate.

That is the part the reviewer cannot judge. It can tell that something was learned. It cannot tell whether the lesson deserves 1,400 words of my permanent instructions, or four lines, or nothing at all, because it only ever sees one conversation and has no view of what is already in the file or what happens next week. Every review is a fresh enthusiast.

My response to that was not kind at all towards the Nous developers, calling into question aspects of their anatomy and attitudes to work.

The fallout for me now is that every single skill my agents have is suspect and will need to be reviewed. Thank you for that Nous, thank you very much.

I am not turning the review off. When it works it is genuinely useful, and half the operational knowledge my agents rely on started as something a review noticed and I later kept. And, as a result of this, I have figured out a fairly easy way to incorporate gated reviews. The objection is not that the machine learns. It is that it was promoting its own conclusions to policy without asking.