Hermes should learn from the corpus, not just remember the chat

This is a submission for the Hermes Agent Challenge.

I usually have too many agent loops open at once.

A coding agent in one terminal. A research worker in another. A browser worker. Some half-finished website pass. A notes file that is supposed to be the source of truth but is already stale by the time I remember it exists.

That is the real problem Hermes makes me think about.

Not "can an agent remember me?"

More like: can an agent learn from the whole working corpus, extract the useful signal, and turn it into better behavior without turning my machine into a pile of invisible mutated habits?

Not a diary. Not a giant pile of old chats. Not another place where context goes to die.

A compiler for prompts, sessions, workflows, corrections, and mistakes.

The corpus is the asset

Most agent memory systems aim too low.

They remember facts:

"The user likes short answers."

"The project uses Vercel."

"The repo is over here."

That is useful, but it is not the main prize.

The thing worth preserving is the signal inside the corpus:

• what the user keeps trying to build,
• what they correct repeatedly,
• what their writing actually sounds like,
• which checks are cheap and should always run,
• which decisions belong to the human,
• which mistakes happened twice and should become a guardrail.

That is where an agent starts to feel less like a prompt box and more like a working system.

Every prompt, session, correction, draft, failure, and weird half-finished thought is training data for your own operating system.

Not training data in the "upload it to some company and hope" sense.

Local corpus. User-owned. Searchable. Versioned. Private by default.

The raw corpus is ore. Hermes should be the refinery.

The simple version

Here is the pattern in normal words:

1. You correct an agent three times.
2. Hermes notices the repeated correction.
3. It proposes a small workflow rule.
4. You review it before it becomes default behavior.
5. The rule gets a human-readable version.
6. If it makes things worse, you roll it back.

That is the whole idea.

Not "the agent has a bigger memory."

"The agent turns repeated work into reviewable, reversible behavior."

Bad memory says:

"Improve the workflow later."

Good memory says:

"Before publishing a technical post, check the sources, remove private notes, verify the screenshots, and only then hit publish."

One is a reminder. The other is a runnable process.

That difference sounds small until you have the same agent making the same mistake in three different terminals.

Why Hermes fits

Hermes Agent is interesting because it is already pointed at the long-running agent shape: tool use, multi-step work, local infrastructure, model choice, and a memory loop that improves over time.

That changes the normal developer workflow.

With a stateless assistant, every session starts from prompt archaeology. You reload the repo, restate the rules, remind it what matters, and hope the model keeps the important parts in context.

With a workflow-learning agent, the successful workflow can become a skill. The repeated correction can become a guardrail. The writing samples can become a voice profile. The next run can spend less time rediscovering the shape of the work and more time doing it.

This is useful for messy real-world work:

• building websites,
• checking tool installs,
• maintaining project state,
• preparing public writing,
• reconciling trackers,
• turning rough ideas into buildable specs.

These are not one-prompt tasks. They are loops. They have taste, order, failure modes, and local rules.

That is exactly what Hermes should learn.

Negative memory matters

Wait, there is one trap though.

If Hermes only learns what worked, it can preserve bad habits too.

A good agent should remember:

• this shortcut created rework,
• this output sounded too AI-written,
• this tool install asked for too much authority,
• this task looked important but was stale waiting,
• this class of decision needs human approval.

The memory should not only say "do this again."

Sometimes it should say "never repeat this shape without a check."

That is the difference between compounding and just accumulating residue.

Versioned skills are the safety layer

This is the part normal users will actually understand, because it maps to undo.

The agent says:

"I made a mistake here. I learned something important. I propose changing these three skills."

Then the user sees:

• Website SOP v4 -> v5
• Tool-install review v1 -> v2
• Voice profile v2 -> v3

Each version should say what changed, why it changed, what behavior it preserves, and how to roll it back.

Small changelog. Clear version. Backup. One-command rollback.

That turns self-improvement from a weird hidden mutation into something closer to software releases.

Git is good infrastructure. It is not the user interface for agent memory.

Nobody wants to say:

"Revert commit 8f41c9a from that one folder where the agent stores its habits."

They want to say:

"Revert the writing skill to version 2."

That is the product shape.

Many agents make this urgent

This gets serious when the user is not running one cute agent in one window.

Some developers already have multiple CLIs open at once: coding agents, local agent sessions, browser workers, website builders, background jobs, random one-off terminals.

In that world, "the agent learned something, so it edited a skill" is not safe enough.

If twenty streams run in a day and each stream rewrites three skills, the system did not improve. It created a governance problem.

So the control plane needs a rule:

Workers do the work.

Hermes learns from the work.

The control plane releases the learning.

The backup preserves the released state.

By control plane, I just mean the local place that can see active agent loops, their proposed memory changes, and the current skill versions. It does not need to be fancy. It can start as files and a small dashboard.

The important part is that worker agents do not silently mutate shared identity.

They submit proposals.

The control plane reviews, groups, tests, releases, rejects, or rolls them back.

That is where skills start to become an identity layer.

Not identity in the mystical sense. Identity as in: what the agent reliably does across models, terminals, and time.

Example: installing agent tools

Tool installation is a clean example because memory, trust, and execution collide.

You add a tool. The tool asks for filesystem access, shell access, browser access, or an API token. The README includes install instructions. The config includes env keys. The tool descriptions get fed into the model. The agent now has more authority than it had five minutes ago.

None of that has to be malicious to be dangerous.

So I would want Hermes to turn tool installation into a reusable ritual:

1. What authority does this tool ask for?
2. What files, commands, browser profiles, or credentials does it touch?
3. Which parts are deterministic evidence, and which parts are model judgment?
4. What constraints should be copied into the final install plan?

The output should not be "safe" or "unsafe." That is fake certainty.

The output should be a posture:

• Add carefully.
• Sandbox first.
• Do not add.

Then the final step is boring and mechanical: compare the proposed config against the posture before writing it.

If the review says "sandbox first" and the final config mounts the whole home directory, the agent should stop.

That is not a grand theory. It is just workflow memory with teeth.

What I would build

I built a static local mockup only to make the workflow concrete. The submission is the pattern, not a claim that the full product already exists.

The v1 demo is intentionally small:

• paste or import a local sample corpus,
• match repeated patterns,
• show source-line excerpts,
• generate proposed skill/doctrine changes,
• show redaction and spend warnings,
• write a release note,
• show a version ledger,
• show rollback text.

No backend. No model call. No real file mutation. No fake autonomy.

The full product still needs the hard boring parts: connectors for real agent tools, model-backed extraction, stronger redaction, source-grounded evidence, proposal dedupe, A/B tests for skill changes, git-backed releases, and rollback tested on real workflows.

But that is also why the idea is interesting.

The demo is not "look, the agent remembers me."

The demo is:

"Look, the agent learned something from the work, proposed a bounded change, and made it reversible."

The point

I do not think the future of agent development is "trust the agent more."

I think it is closer to:

Give the agent better local context.

Give it tools.

Let it learn.

Then make the learning inspectable enough that developers can delete, correct, and constrain it.

Hermes points in that direction because it treats the agent as a long-running system, not a single answer.

The real memory is not the chat log.

The real memory is the workflow becoming reusable.

The safe memory is the workflow becoming reversible.

And the agent that grows with you should also learn where not to grow.