Agent Architecture · Skill Lifecycle

Skills that evolve,
agents that compound.

First surfaced in Tandemly Briefing — 2026-05-28

Every agent with a skill library has the same quiet problem: the library doesn't get better on its own. ByteDance researchers built the framework that changes that. Five components handle the full lifecycle of a skill: creation after task completion, quality-gated admission, refinement from new examples, and retirement when performance falls off. The result closes most of the gap between no skills and human-written skills without a human writing anything.

Core concept
Skill lifecycle: treating agent skills not as frozen code but as managed artifacts with a full lifecycle from creation through retirement. Quality gates at admission and automatic retirement keep the library clean as it grows.
scroll to explore

Static skill libraries
set the ceiling at deploy time.

Most skill libraries for agents are written once and edited by hand. That approach works until you want the agent to improve on its own.

Skill libraries make agents faster and more consistent. Instead of reasoning from scratch on every task, an agent can retrieve a skill it has used before, adapt it, and execute. The approach works well enough that most frameworks include some form of it.

The problem is that most skill libraries are static. You write the skills, load them in, and the agent calls them. If a skill stops working, nobody knows unless a human notices and edits the file. If the agent solves a new class of problem it has never seen before, that solution disappears when the session ends. The library is exactly as good as the last time someone sat down to improve it.

There is a secondary problem: quality decay. Real skill libraries accumulate entries over time. Some skills were well-written and generalize well. Others were written under pressure and handle only one specific case. In a static library, the well-written and the poorly-written skills sit side by side with no signal distinguishing them. Agents retrieve both.

The obvious fix is to let the agent manage the library itself. But "self-improving agent" has been promised more often than it has been built. What it requires is not a single mechanism but a full lifecycle: creation, storage, evaluation, refinement, and retirement working together.

The question this paper asks

What if every successful task execution could automatically produce a skill, test it, refine it, and retire it if it starts underperforming? Can a fully autonomous skill lifecycle close most of the gap between an agent with no skills and an agent given carefully human-written ones?

Five components,
one complete lifecycle.

MUSE-Autoskill (Memory-Utilizing Skill Evolution) breaks the skill lifecycle into five distinct components, each responsible for one stage. No human writes or edits skills after the initial configuration.

Status quo
Skills as frozen code. A developer writes a library. The agent calls entries by similarity. When skills become stale or wrong, someone edits the file. Improvement rate is set by human bandwidth.
MUSE-Autoskill
Skills as managed artifacts. The agent extracts skills from its own successes, tests quality before admission, refines descriptions from new examples, and retires entries below threshold. The library grows and cleans itself.
1
Skill Creator
After a task completes successfully, the Creator extracts a generalized, reusable description of what the agent did. The description is phrased as a skill applicable beyond the specific task: not "solve this problem" but "when you encounter this pattern, do this." It goes into Skill Memory as a vector embedding.
2
Skill Memory
A vector store indexed for similarity retrieval. At inference time the agent retrieves the most relevant skills and includes them in context. Because retrieval is similarity-based, a skill that solved one instance of a problem generalizes to paraphrased or structurally related instances without rewriting.
3
Skill Evaluator
New skills are not admitted to the active library automatically. The Evaluator tests each candidate on held-out tasks and scores it. Skills that don't reach a quality threshold don't enter the retrieval pool. This is the admission gate that keeps low-quality entries out from the start.
4
Skill Updater
When the agent successfully solves a new instance of a problem, the Updater uses that example to refine the relevant stored skill description. A skill that was written after one example gets a better, more generalizable description after five. The library's quality compounds as the agent works.
5
Skill Retiree
Skills that fall below quality thresholds over time are removed. This is the component most skill frameworks skip entirely. Without retirement, the library fills with obsolete or incorrect entries that degrade retrieval quality for everything around them. MUSE-Autoskill treats retirement as a first-class mechanism, not an afterthought.
Skill transfer as a separate capability

Because skills are stored as vector-indexed descriptions rather than agent-specific code, they are not tied to the agent that created them. The team tested whether skills generated by one agent could improve a different agent without any additional tuning. They could. This makes the skill library a shared organizational asset, not a per-agent artifact.

Auto-generated skills
beat the human ceiling.

The benchmark compared three conditions: no skills, human-written skills (the intended ceiling), and MUSE-Autoskill's autonomous library. The auto-generated library came closer to the human ceiling than the gap implied.

Overall accuracy
68.40%
MUSE-Autoskill with auto-generated skills
Lift over no-skills baseline
+15.21
percentage points; best in 3 of 4 domains
Transfer to Hermes agent
+10.51
pp; closes 79% of gap to Hermes with human skills
Finding 1: The ceiling is breakable

On the 35 tasks where skill generation succeeded, MUSE-Autoskill reached 87.94% accuracy. The human-skill baseline sits below that number on those tasks. The agent's self-generated descriptions, tested against held-out examples before admission, outperformed what a human wrote for the same task category.

That figure comes with a caveat the paper is upfront about: it applies only to the subset of tasks where skill generation succeeded. The paper does not report what fraction of tasks produced a successful skill, so the ceiling-beating result cannot be generalized to the full task distribution without knowing the denominator.

Finding 2: Skills transfer across agents

When MUSE-Autoskill's generated skills were injected into Hermes, a different agent that had not participated in skill creation, Hermes gained 10.51 percentage points. That number closes 79% of the gap between Hermes with no skills and Hermes with human-written skills.

The practical implication: an organization running multiple agents with overlapping task coverage could use one agent to build the skill library and share it across all of them. The creation cost is paid once; the improvement distributes.

Finding 3: Retirement reduces library noise

Libraries with automatic retirement accumulated measurably fewer low-quality entries than static-library baselines over the same number of tasks. This finding is not surprising in principle, but the experiment makes it concrete: the absence of a retirement path produces compounding retrieval noise. The longer the library runs without retirement, the worse that noise gets.

Scope and limitations

The 87.94% ceiling-beating figure covers only the 35 tasks where skill generation succeeded. The distribution of success rates across the full task set is not reported, which limits what can be said about reliability in the general case. Cross-agent skill transfer was tested on one agent pair. Whether the result holds across more diverse agent architectures is an open question.

What this means
for agent builders.

The paper's most actionable contribution is not the system as a whole but the three mechanisms that make it work: the quality gate, the retirement path, and skill-level memory. Each can be adopted independently.

1
For teams running production agents
The quality gate is the first thing to implement. Every new skill entering the library should be tested on held-out examples before admission. The MUSE-Autoskill results suggest that this single mechanism is responsible for a significant share of the library's quality advantage over unfiltered accumulation. Implement admission testing before you implement anything else.
2
For teams with existing skill libraries
Audit for a retirement path. If your library has no mechanism for removing entries, it is accumulating noise silently. You don't need the full MUSE-Autoskill architecture to fix this. A periodic quality-score pass on the existing library and a threshold below which entries are marked inactive is a defensible starting point.
3
For teams running multiple agents with overlapping domains
Test skill transfer before investing in per-agent skill infrastructure. The 79% gap closure in the Hermes experiment suggests that skills generated by one well-tuned agent can meaningfully improve others without per-agent lifecycle work. Run the experiment first, then decide whether per-agent skill creation is worth the additional complexity.
4
For researchers and tooling builders
The open question the paper leaves is the skill generation success rate across the full task distribution. An agent that generates successful skills on 90% of tasks is a different tool from one that succeeds on 40%. That denominator drives everything downstream. If you build on this framework, instrument skill creation success rates from day one.

Where to go
from here.

Five concrete next steps for taking the skill lifecycle seriously in your own systems.

1
Read the paper
Lin, H., Li, P., Song, J., Jiang, F., & Zhang, T. (2026). MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation. arXiv:2605.27366.
2
Audit your current skill library for lifecycle gaps
Map your library against three questions: How are skills added (manually or automatically)? Is there an admission quality gate? Is there a retirement path? Each gap maps to one of MUSE-Autoskill's five components. Identify which gaps are causing the most retrieval noise before deciding what to build.
3
Start with unit tests as the admission gate
Before building a full Skill Evaluator, run any new skill candidate against two or three held-out examples of the task it is meant to address. If it fails those examples, don't admit it. This is the highest-leverage single mechanism in the paper and requires no new infrastructure beyond what most teams already have for testing.
4
Test cross-agent skill transfer with one experiment
Take the highest-quality skills from your best-performing agent and inject them into a second agent in the same domain. Measure the accuracy delta on a held-out task set. If the lift is meaningful, you have evidence for a shared skill library architecture. If it's negligible, per-agent lifecycle investment is probably warranted.
5
Track library quality metrics over time
The value of retirement is longitudinal. Start measuring library quality as a time series: average skill score, fraction below threshold, retrieval precision on your eval set. Without those numbers you won't see noise accumulating until it's already affecting production results. Instrument now rather than after the first degradation incident.