How Self-Evolving Agents Actually Work: Claude Code, Open Claw, and Hermes

The phrase self-evolving agent sounds like a lab research project, but the practical difference shows up in the first two weeks

The phrase "self-evolving agent" sounds like a lab research project, but the practical difference between an agent that learns and one that does not shows up in the first two weeks of real use. An agent that does not learn corrects the same mistakes every session. You tell it that your pricing structure works a certain way, and next week you tell it again. You show it that the business uses a specific format for customer quotes, and the following Monday you show it again. The correction loop is the cost, and it compounds invisibly across every session until the tool that was supposed to save time is reliably creating more of it.

The agents that actually evolve, Claude Code, Open Claw, and Hermes being the three worth understanding right now, break that loop through different architectural choices. Each one takes a different approach to the same core problem: how do you make knowledge persist across sessions in a way that the agent can actually use, rather than just dumping everything into a context window that overflows and loses structure over time? Understanding the architectural differences helps you choose the right one for your situation and helps you configure whichever one you pick in a way that actually compounds.

Memory for facts and skills for know-how are not the same thing, and mixing them up breaks both

The single most important architectural distinction in self-evolving agents is between memory and skills, and most introductions to these tools collapse them into a single concept that makes both harder to implement correctly. Memory stores facts: your client's name is Sophie, the job is in Englewood, the standard quote includes three revision rounds. Skills store know-how: how to structure a quote for a plastic surgery client, how to handle a pricing objection from a medical spa, how to escalate a support issue through the right internal channel.

These two types of knowledge need to be stored differently because they are used differently. Facts are retrieved by lookup: you need to know Sophie's contact details when you are sending an invoice, and you need exactly those details, not a general approach for how to contact clients. Know-how is retrieved by pattern: when the agent is drafting a follow-up to a sales inquiry, it needs to apply the right tone, the right structure, and the right call to action, which means it needs to load the relevant process knowledge, not a specific fact.

When memory and skills are mixed together, retrieval degrades because the system cannot distinguish between looking up a specific piece of information and loading a process for how to handle a type of situation. The result is agents that are inconsistently helpful: sometimes they apply the right approach, sometimes they surface an irrelevant fact, and the inconsistency makes them harder to trust. Separating the two clearly, in your configuration and in how you instruct the agent to store new knowledge, is the first thing to get right before optimizing anything else.

Hot memory loads every session, warm memory loads on demand, and the distinction cuts your token bill

Within the memory category, there is a second distinction that matters for both performance and cost: hot memory versus warm memory. Hot memory is the information loaded at the start of every session regardless of what the session is about. Warm memory is information loaded only when the agent determines it is relevant to the current task.

Hot memory should contain only what is true and relevant every single time the agent is used. The business name, the owner's communication preferences, the three or four rules that govern every interaction regardless of topic. That list is usually short, five to fifteen facts, and keeping it short is important. Every token in hot memory is a token that loads on every session, which means it costs money every session and occupies context that could be used for the actual task.

Warm memory should contain everything else: client-specific details, project history, category-specific knowledge that is only needed for certain types of work. The agent decides at the start of each session, based on the task prompt, which warm memory files to load. A session about a specific client loads that client's warm memory file. A session about writing ad copy loads the ad copy style guide from warm memory. A session about routine administrative work loads neither.

The practical cost reduction from this separation is significant for businesses running the agent frequently. An agent that loads 8,000 tokens of context per session across 50 sessions per month is consuming 400,000 tokens in overhead before a single productive token is generated. A well-structured hot memory of 500 tokens with warm memory loaded on demand might bring that overhead to 50,000 tokens per month on the same usage pattern. The task quality is higher because the context is cleaner, and the bill is lower because less is loaded indiscriminately.

The async background process is the piece most builds skip and then wonder why the agent forgets

When people build agents and then complain that the agent does not seem to be getting smarter over time, the missing piece is almost always the async background process. The conversational loop, you ask, the agent responds, is not where learning happens. Learning happens in a separate process that runs between sessions, reviewing what was generated, identifying what worked and what did not, promoting useful patterns to the skill store, deprecating patterns that consistently needed correction, and trimming memory files of information that has become stale or irrelevant.

Without this process, the agent has no mechanism for incorporating what happened in yesterday's sessions into how it behaves in today's sessions. It starts each session with the same configuration it had when you first set it up, plus whatever corrections you made in the last session that happened to be stored explicitly. The implicit learning, the patterns that emerged from how the work actually went, are lost.

Implementing the background process is not complicated, but it requires deliberate setup. The process needs to run on a schedule, typically at the end of each working day or after each session, and it needs access to the session logs. It reads the logs, applies the evaluation criteria you have defined for what constitutes a useful output versus an output that needed correction, and updates the relevant memory and skill files accordingly. The session logs are the raw material. The background process is the refinery.

Claude Code's auto-trim step solves the stale-context problem that prompt-based memory always creates

Claude Code includes an auto-trim step in its memory management that addresses one of the most persistent problems with agent memory systems: stale context. Memory files that are never pruned accumulate outdated information that contradicts current reality. The client's name was the same last year and this year, but the project status, the contact preference, and the pricing tier may have changed. An agent that reads old memory without knowing it is old will apply outdated context to current situations.

Claude Code's auto-trim evaluates memory contents against the recency and frequency of use. Information that has not been referenced in recent sessions and that has not been updated recently is flagged for review or deprecation. Information that is referenced frequently and that remains consistent over time is retained and ranked higher in retrieval priority. The effect is that the agent's working memory stays current without requiring the operator to manually audit and prune memory files on a regular schedule.

The practical implication for a business owner using Claude Code is that the agent's knowledge of your business stays accurate without you needing to remember to update it every time something changes. The system observes what information is being used, what information is being corrected, and what information seems to have become irrelevant, and adjusts the memory accordingly. This is not a substitute for deliberate updates when something important changes, but it catches the gradual drift that happens when businesses evolve faster than their agent configurations do.

Open Claw's built-in search across files and raw history is what makes it feel like total recall

Open Claw takes a different architectural approach to memory than Claude Code. Rather than maintaining structured memory files that are explicitly managed, Open Claw keeps a searchable index of the agent's full history, including every file it has interacted with, every conversation it has had, and every decision it has logged. When the agent needs to recall something, it searches this index in real time rather than loading a pre-compiled memory file.

The experience from the user side is what people sometimes describe as total recall. Ask the agent something it encountered six months ago and it finds the relevant exchange. Ask it about a decision that was made three projects back and it surfaces the reasoning that was logged at the time. The retrieval is by relevance rather than by recency, which means the agent does not forget useful information just because it was a long time ago.

The tradeoff is that this approach is more computationally intensive than structured memory files, and the search quality depends on the quality of the historical content. If the agent's history is full of low-quality exchanges that were never cleaned up, the search has more noise to sort through. The businesses that get the most from Open Claw are the ones that use it consistently for the same categories of work over time, so the history accumulates depth in the areas where retrieval is most valuable. An agent used inconsistently for diverse tasks builds a history that is broad but shallow, and the recall quality reflects that.

Hermes keeps its memory files under 4,000 characters deliberately to push knowledge into skills

Hermes takes the most opinionated approach of the three systems, and the opinion is worth understanding rather than treating as an arbitrary constraint. Hermes limits memory files to 4,000 characters, which is short enough that it forces a discipline around what actually belongs in memory versus what belongs in skills.

The reasoning is that memory files that grow without limit become retrieval problems. A 20,000-character memory file covering a client relationship is not a structured memory, it is a document dump that the agent has to read in its entirety to extract a fact that could have been organized in a hundred characters. By keeping memory files short, Hermes forces the operator to do the organizational work that makes retrieval fast and reliable: facts in memory, processes in skills, and nothing in either that belongs in the other.

The secondary effect is that it drives knowledge into skills, which is the higher-leverage storage type. A skill that encodes how to handle a certain category of client situation is reusable across all clients of that type. A memory note about how a specific situation was handled is useful only when that specific situation recurs. Over time, an agent whose knowledge is well-organized into skills and concise memory is more capable and more consistent than an agent whose accumulated knowledge is stored in sprawling memory files that mix facts, processes, and context without distinction.

The skill guard that rejects bad patterns before they are stored is where quality compounds

The most underappreciated feature across all three systems is the skill guard: a validation layer that evaluates proposed patterns before they are promoted to the skill store. Without a skill guard, any pattern that appears in the session history is a candidate for promotion, including patterns that represent mistakes, edge cases that do not generalize, and workarounds for situations that are not representative of the business's typical work.

A skill guard applies criteria to proposed patterns before promotion. The criteria vary by implementation, but the most effective versions check for four things: does the pattern generalize beyond the specific session it came from, has the pattern been reinforced by multiple sessions rather than appearing once, does the pattern contradict any existing skill in a way that needs to be resolved before promotion, and does the pattern represent desired behavior or a compensating behavior for a situation that should not recur.

The cumulative effect of a skill guard is that the agent's skills stay high quality over time rather than accumulating noise. An agent without a skill guard after six months of use has promoted a mix of good patterns and context-specific workarounds, and the quality of its outputs reflects that mix. An agent with a consistent skill guard has a skill library that represents only the patterns that reliably produce good outcomes, and the quality compounds accordingly.

For a business like an auto detailing shop that I want to make concrete here, this showed up within four weeks. Week one: the agent was being corrected on every quote, the right add-on upsells, the correct pricing tier language, the tone the owner used for premium clients. Week four: the agent was quoting jobs correctly, applying the right upsell language, and using the right pricing tier without correction. The background process had promoted the patterns that were consistently applied after correction and rejected the initial patterns that were being overridden. The time to produce each quote with corrections dropped from 8 to 10 minutes in week one to under 2 minutes in week four with no corrections. The skill guard ensured that what got promoted was the corrected behavior, not the original behavior that was being overridden. That distinction is where the quality actually compounds rather than just accumulates.