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. 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 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.
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 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 can perform the work, but they do not grow.
The Main Agent Is Not Well-Suited to Carry Self-Evolution
Many self-evolution designs today center 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? 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
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. 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 Pin Factory Worker vs. the 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.
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.
The Real Architecture
A more accurate statement of what I am really arguing 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.