TL;DR: The core of the self-evolution path is making agents stop treating every interaction like a first meeting. It will progress from in-conversation learning to long-term memory, skills, and evaluation/rollback mechanisms. What truly matters is not remembering more automatically, but consolidating effective experience into verifiable, deletable, rollback-capable capability assets.
This is the second article in the Agent Evolution Series.
The first article discussed the execution path: how agents move from answering to doing.
This article discusses the second path: The Self-Evolution Path.
This path asks:
Can an agent learn from historical tasks, user feedback, and failure experiences, becoming a long-term collaborator that gets better with use?
If the execution path solves “can it do,” the self-evolution path solves “can it do it better over time.”
Projects like Hermes Agent represent this path. They emphasize skills, long-term memory, user models, multi-model support, sandbox backends, task trajectory generation and compression, aiming for agents to not just complete tasks but to consolidate experience.
1. What Is the Self-Evolution Path
Many AI assistants today have a clear problem: they can be smart within a conversation, but the next time it’s like the first meeting again.
Users often need to repeatedly explain:
- What this project is;
- What tech stack is used;
- What the coding conventions are;
- Where common tools are located;
- Which processes should be avoided;
- Which commands have failed before;
- What output style the user prefers;
- What internal team conventions exist.
This makes it hard for AI to become a true long-term collaborator.
The self-evolution path addresses this problem.
It wants agents to accumulate experience from each task, forming long-term capabilities.
But “self-evolution” here shouldn’t be understood as models mysteriously awakening, nor should it mean agents can rewrite themselves without limit.
A more precise definition is:
The self-evolution path consolidates effective experience from historical tasks into reusable, evaluable, versionable, deletable, rollback-capable capability assets.
This is the engineering-feasible version of self-evolution.
2. Why the Self-Evolution Path Emerged
The fundamental reason is that users don’t want to teach the agent from scratch every time.
A truly valuable agent shouldn’t only be smart within the current conversation.
If every task requires users to re-explain project background, tool paths, historical conventions, and failure experiences, the agent can never become a long-term collaborator—only a one-shot tool.
Human collaborators get better because rapport forms through cooperation. The first time requires a lot of background explanation; after the second and third times, communication costs decrease.
Agents should be the same.
They should gradually learn:
- What tasks users commonly do;
- Which tools are most frequently used;
- Which workflows have been proven effective;
- Which errors have occurred before;
- What should be checked first for certain tasks;
- Which risky actions must pause for confirmation;
- Which repetitive processes can be encapsulated as skills.
This path develops along “in-conversation learning → long-term memory → skills → evaluation and rollback” for internal reasons.
Because for an agent to get better with use, it must first solve continuity, then reusability, and finally correctness.
In-conversation learning only solves the current task; long-term memory solves cross-task continuity; skills turn experience into reusable processes; evaluation and rollback prevent erroneous experience from becoming permanently entrenched.
So the core of the self-evolution path is not “the more remembered, the better,” but:
Consolidate effective experience while preventing erroneous experience from contaminating future tasks.
If an agent can’t accumulate experience, it’s just a one-shot assistant. If it can accumulate, verify, and correct experience, it can become a long-term collaborator.
3. Stages of the Self-Evolution Path
The self-evolution path also doesn’t happen overnight. It roughly goes through four stages.
1. In-Conversation Learning
The earliest learning occurs within a single conversation.
The user provides context in the current conversation, and the agent uses this information to complete the task.
This already improves the experience somewhat, but the problem is that once the context ends, the information disappears.
This capability is more like short-term working memory than long-term learning.
2. Long-Term Memory
The second stage is long-term memory.
Agents begin saving stable, long-term valuable information: user preferences, project background, team conventions, tool configurations, historical decisions, common problems, and proven effective workflows.
Long-term memory significantly reduces repetitive explanations from users.
But it also brings new problems:
- What’s worth remembering?
- When should it be used?
- What happens when old memories expire?
- What if old and new memories conflict?
- How to correct wrong memories?
- How can users view and delete memories?
If these problems aren’t solved well, long-term memory turns from an asset into a source of contamination.
3. Skills Stage
The third stage is skills.
Skills are one of the most critical carriers in the self-evolution path.
A skill can be understood as an agent’s reusable capability unit, potentially containing: task steps, tool descriptions, input/output formats, applicable conditions, examples, checklists, risk warnings, failure handling methods, and evaluation criteria.
Long-term memory is oriented toward “facts and preferences,” while skills are oriented toward “how to do things.”
For example:
- How to review a PR;
- How to generate a research article;
- How to release a version;
- How to handle a certain type of data report;
- How to run tests in a specific project;
- How to troubleshoot a certain type of production issue.
The value of skills is that they can be file-based, structured, readable, editable, and version-managed.
This transforms agent capability consolidation from a black box into a governable asset.
4. Evaluation and Rollback Stage
The fourth stage is evaluation and rollback.
This is the key to the self-evolution path truly reaching maturity.
If an agent automatically generates many memories and skills without an evaluation mechanism, it may not get better with use—it may get messier.
A mature system must be able to answer:
- Does this skill actually improve success rates?
- Is this memory still valid?
- Is this experience just a one-time occurrence?
- Is the new skill better than the old version?
- If the new version fails, can it be rolled back?
- Can users delete erroneous memories?
- Can teams audit skill changes?
Only when reaching this stage does self-evolution become more than just a slogan.
4. The Value and Risk of Long-Term Memory
Long-term memory is the foundational capability of the self-evolution path, but it’s also dangerous.
Its value lies in giving agents continuity. Its risk lies in errors continuously affecting future tasks.
1. Value of Memory
Long-term memory allows agents to remember stable information: user habits, project structure, frequently used commands, team rules, historical decisions, verified workflows.
This reduces repetitive communication and improves collaboration efficiency.
2. Risk of Memory
But memory can also cause contamination:
- Treating temporary preferences as long-term preferences;
- Continuing to use outdated rules;
- Taking erroneous summaries as facts;
- Generalizing special project experience to all projects;
- Retrieving sensitive context in irrelevant tasks.
Wrong answers usually only affect one task. Wrong memories affect many tasks.
So long-term memory must be explainable, editable, deletable, and have conflict resolution mechanisms.
5. Why Task Trajectory Compression Matters
A complex task often generates a long trajectory:
- User goals;
- Agent’s plan;
- Tool call records;
- Materials read;
- Errors encountered;
- Attempted solutions;
- The ultimately successful path;
- User feedback.
These trajectories contain a lot of experience. But it’s impossible to stuff all historical trajectories into future context.
So compression is needed.
Task trajectory compression aims to distill future-usable experience from a single task.
For example:
- Which error was the real cause;
- Which path was proven ineffective;
- Which flow can be reused;
- Which constraint must be remembered;
- Whether a new skill should be generated.
But compression also has risks. If compression goes wrong, the agent may treat failure experience as success, coincidental conditions as general rules, or drop critical constraints.
So trajectory compression can’t just be summarization; it must combine evaluation, user feedback, and version management.
6. The Biggest Problem of the Self-Evolution Path: Self-Contamination
The self-evolution path fears not learning too little, but learning wrong.
Self-contamination may manifest as:
- Wrong memories used long-term;
- Failed workflows packaged as skills;
- Outdated APIs still being called;
- Temporary preferences mistaken for long-term preferences;
- Task trajectories incorrectly compressed;
- Auto-generated skills used without testing.
These problems are insidious because they’re not one-time errors, but long-term bias.
So the real challenge of the self-evolution path is not “automatic learning,” but “governed learning.”
7. What a Mature Self-Evolution System Should Have
A mature self-evolution system should have a complete skill and memory lifecycle.
At minimum:
- Creation: Generate memories and skills from user instructions, task trajectories, or team workflows;
- Evaluation: Verify whether they’re actually useful;
- Version Management: Preserve historical changes;
- Rollback: Recover old versions after errors;
- Deletion: Remove invalid, outdated, or erroneous content;
- Audit: Know who created it, when it was updated, and which tasks it affected;
- Permission Control: Different scenarios can only use necessary memories and skills.
This means that in the future, the core moat of self-evolving agents isn’t just model capability, but capability asset management capability.
8. The Ultimate Direction of the Self-Evolution Path
The self-evolution path will ultimately become the learning layer of a mature agent system.
It connects context and execution. Personal context tells the agent: who the user is, what the project is, and what background the current task has. The execution system calls tools and completes real operations. The self-evolution layer consolidates task experience, making future execution faster, more accurate, and less reliant on user repetition.
Its final form is not a fully autonomous black-box intelligence, but:
An evaluable, versionable, rollback-capable, deletable learning layer.
9. Summary
The self-evolution path solves whether an agent can get better with use.
It will develop from in-conversation learning, to long-term memory, to skills, and finally to evaluation and rollback.
The key to this path is not having the agent automatically write down more things, but establishing a reliable experience consolidation mechanism.
A truly mature self-evolving agent must prove that what it learns is correct, useful, and controllable, and can correct and roll back when learning goes wrong.
The next article will discuss the third path: the Personal Context Path. It focuses not on whether the agent can do or learn, but on whether the agent can truly understand the user.