Problem or Use Case

Hermes currently runs its self-improvement loop on the main agent. But the main agent's task distribution is too broad — it writes code, researches, analyzes logs, writes articles. Experience drifts laterally and never converges. Self-evolution signal is noisy.

Proposed Solution

Why Self-Evolution Belongs to Subagents, Not the Main Agent

Posted to the Hermes Agent community: Hermes has built the closest thing to this vision so far — a self-improving agent with a real learning loop. This post is a proposal for one specific direction: what happens if we move that logic down from the main agent layer into specialized subagents? Is that where it truly belongs?

The Problem Is Not Whether Subagents Have Skills

Modern agent frameworks are already beginning to support equipping subagents with their own skills, memory, and tools. In other words, simply claiming that "subagents need their own skill libraries" is no longer a particularly fresh insight.

The real question is not:

Can a subagent possess skills?

But rather:

Can a subagent, anchored to a stable professional identity, continuously distill its execution experience into progressively better skills?

This is what truly matters.

A subagent that only loads skill files is nothing more than a temp worker carrying an operations manual.
A subagent that keeps refining, compressing, validating, and updating its own skills is what a genuinely maturing professional role looks like.

Current Subagents Still Feel Too Much Like Temporary Workers

After using subagents at scale, one obvious pattern emerges: they keep turning on and off.

A task arrives, the subagent spins up, executes, and shuts down. The next task comes, and it restarts all over again. Even if it can load a skill, it remains fundamentally task-driven and disposable.

This is not a bug. It is the default organizational pattern of today's mainstream agent architectures: the orchestrator assigns tasks, subagents handle localized work, and tools execute specific actions.

The structure closely resembles a bureaucracy.

AI Is Automating Work That Has Already Been Sliced by Bureaucracy

The orchestrator maps to upper management, subagents map to functional departments, and tools map to execution-level roles. Instructions flow downward, results flow upward, and each layer is only responsible for its own interface.

This is not because designers love bureaucracy. It is because modern work has already been pre-processed by bureaucratic structures. Organizations have spent over a century breaking down ambiguous human intent into defined positions, processes, permissions, tickets, documents, standards, interfaces, and deliverables. When AI takes over, it usually receives tasks that have already been shaped by organizational structure. That is why multi-agent systems naturally grow to resemble bureaucratic hierarchies.

Yet while AI has replicated the division of labor, it has missed the single most important element that makes bureaucracy effective at developing expertise: stable positions.

What Really Allows Experts to Grow in a Bureaucracy Is Not Division of Labor, but the Persistence of Positions

Bureaucracy enables experts to get better not merely because it splits tasks apart, but because it grants each expert a persistent identity.

A position does not disappear when a task ends. Tasks come and go, but the position remains. It is this persistence that gives experience a place to accumulate and allows genuine growth to occur.

Human organizations discovered long ago that enduring positions are the essential infrastructure for professional development.

Current subagents, however, are purely task-driven: they exist only when a task arrives and vanish the moment it ends. That is not a position — it is a work order.

Work orders have no craft history. Positions do.

Without persistence, self-iteration has no subject. If a subagent is shut down after every task, where does its accumulated experience live? Who is the entity updating its skills? Is the instance that starts next time even the same one as before?

This is not an engineering optimization. It is a logical prerequisite. A subagent must first persist before self-evolution can even be discussed.

An Expert's Real Value Is Not "Knowing the Process," but Knowing Where Things Break

Someone who has done the same thing for a long time is valuable not because they know the standard procedure. Standard procedures can be written into documents, turned into checklists, or compressed into skill files.

An expert's true value lies in:

• Knowing where this kind of work typically goes wrong.
• Knowing which anomalies can be safely ignored and which faint signals must be acted on immediately.
• Knowing the pitfalls that are never written in the documentation but always appear in real situations.
• Sometimes not even being able to articulate exactly why — they simply look at something and know "this feels off."

This is not knowledge. It is craft intuition forged through long-term, repeated practice.

This is exactly where today's subagents fall short. They can read skills, but they do not behave like a craftsperson who gets better the longer they stay in the role. They feel more like a smart contractor who is called in for each job.

They can perform the work, but they do not grow.

The Main Agent Is Actually Not Well-Suited to Carry the Burden of Self-Evolution

Many self-evolution designs today default to centering on the main agent: after completing a complex task, the main agent summarizes lessons, updates skills, and reuses them next time.

This direction is not wrong, but it has a structural flaw: the main agent's task distribution is far too broad.

Today it writes code, tomorrow it researches information, the day after it analyzes logs, and the day after that it writes articles. Every experience may be genuine, yet none of them accumulate in the same direction.

The main agent's experience drifts laterally. Because it does everything, it touches every kind of experience only lightly. This makes the self-evolution signal extremely noisy: Is this skill a general capability or just a one-off patch from a particular task? Should this process be hardened into a permanent rule, or was it merely a temporary workaround?

The main agent's problem is not lack of intelligence. It is that its task distribution is too wide. When tasks are too diverse, self-iteration struggles to converge.

Subagents Have a Natural Advantage: Narrower Task Distributions

Specialized subagents are different.

A subagent responsible only for reading PDF tables repeatedly encounters PDFs, scanned documents, broken tables, headers and footers, cross-page structures, OCR errors, and formatting pollution.

A subagent responsible only for log analysis repeatedly encounters timestamps, stack traces, distributed tracing, anomaly patterns, noise filtering, and root-cause localization.

Their task distributions are narrow, so experience accumulates in the same direction. This is why specialized subagents have a greater need — and greater potential — for self-evolution than the main agent. Not because they are "smarter," but because they are narrower, making compounding improvement far more likely.

Skill Is Not a Knowledge Package — It Is Accumulated Craft

We must distinguish between memory and skill.

Memory records "what happened in the past."
Skill records "what I should do differently next time."

Memory is like a log. Skill is like a craft procedure.

A subagent should not merely remember "the PDF table parsing failed last time." It should convert that failure into more precise skills:

• When encountering a cross-page table, first check whether the header is duplicated.
• When encountering a scanned PDF, first determine whether OCR is required.
• After extracting amount fields, always perform a total verification.
• When table column counts are unstable, do not blindly trust markdown conversion results.

Only then does experience become capability.

Therefore, what truly matters is not "whether the subagent has its own skills," but:

Can the subagent continuously transform its own failures, corrections, and validation results into its own skills?

The Difference Between a Pin Factory Worker and a Brilliant Generalist

Adam Smith described the pin factory. A single person making an entire pin from start to finish is inefficient. But when each person specializes in one step for a long time, overall productivity explodes.

The key is not just division of labor, but the local optimization that comes from sustained specialization.

A person who has spent years making pins is fundamentally different from a very smart person who has temporarily read a document titled "How to Make Pins."

The latter knows the process. The former knows the feel.
The latter follows steps. The former knows which step is most likely to go wrong, and which small error that looks harmless now will definitely cause problems later.

Subagents face the same issue.

A subagent that has loaded skills is merely a smart person who has read the manual.
A subagent that continuously iterates on its own skills is like someone who has been doing this craft for years.

But there is a prerequisite: the worker must actually stay in the role. If you replace them with a new person after every task, no amount of intelligence will ever develop real craft intuition.

The Real Architecture: Persistent Specialized Subagents + Private Skill Lifecycle

So what I am really saying is not "subagents need skills."

A more accurate statement is:

Persistent, specialized subagents need self-iterating private skill libraries.

Each subagent should have its own task boundaries, its own memory, its own skills, its own validation methods, its own failure samples, and its own update mechanisms.

The main agent should not manage all the experiential knowledge for them. The main agent is better suited for orchestration, coordination, decomposition, and final sign-off. The actual craft expertise should live inside the subagents.

The PDF-reading subagent evolves its own PDF-reading skills.
The log-analysis subagent evolves its own log-analysis skills.
The test-writing subagent evolves its own test-writing skills.
The code-review subagent evolves its own code-review skills.

Because only their experience is converging.

Conclusion

A subagent possessing skills does not mean the subagent is growing.

Two conditions are essential and non-negotiable:

First, the subagent must persist. Without persistence, self-iteration has no subject.
Second, the subagent must be sufficiently specialized. Without narrow task distribution, experience cannot converge.

The main agent's experience drifts laterally.
The subagent's experience accumulates vertically.

What self-evolution truly needs is not a larger, more powerful agent, but more stable, narrower, and more repetitive task distributions — combined with an identity that will not be arbitrarily shut down.

Therefore, persistent specialized subagents are the most natural hosts for skill self-evolution.

This is not simply handing a temporary worker a manual.
This is allowing a professional position to begin developing its own craft history.

Note: This is a hypothesis, not a validated solution. The reasoning comes from real usage experience and logical deduction, not from implemented code. I have not tested this architecture, and it may encounter unforeseen issues during implementation. If anyone builds this, I would love to hear the results.

Alternatives Considered

No response

Feature Type

Other

Scope

Large (new module or significant refactor)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)