In short: ByteDance’s MUSE-Autoskill treats an agent skill as a lifecycle asset that gets created, remembered, tested, patched, and migrated, instead of a throwaway prompt. On the SkillsBench benchmark, human-written skills lifted it from 53.19% to 68.40%, and on the 35 tasks where it generated its own skill, accuracy reached 87.94%.
Your coding agent spends twenty minutes working out a tricky deploy step. It works. The next day you hand it a nearly identical task, and it starts from zero: the same dead ends, the same twenty minutes. It read the docs, ran the commands, and even jotted down a lesson, but that lesson stayed trapped inside one task. When the task ended, the experience went with it.
Agents forget, and for anyone who uses them daily this is a familiar, costly habit. On May 27, 2026, the ByteDance team released MUSE-Autoskill to attack exactly that: how an agent turns the experience it builds while doing tasks into skills it can reuse over the long term.
There is more than one way to solve continual learning for agents. Some update the model weights, some optimize the outer workflow, and some externalize experience into memory and skills. This article focuses first on the two approaches most closely tied to skills.
One route is lightweight, such as self-improving-agent. It defines behavioral rules in a single Markdown document, records errors and lessons in structured logs, and then turns repeatedly validated experience into more stable rules or skills through a “record → review → promote” loop. It works like a personal note-taking system: simple, cheap, and portable.
The other route starts treating the skill itself as a system asset to be managed. MUSE-Autoskill belongs to this camp. So does Microsoft Research’s SkillOpt, which trains the skill file as if it were a model parameter; I covered that work in Stop Hand-Writing AI Agent Skills. Train Them.
The step the paper wants to push forward is this: an agent should not just call skills; it should also learn to make those skills reliable over long-term use.
A Skill Cannot Be a One-Off Artifact
First, what is the paper trying to solve?
Many automatic skill systems already let agents generate skills. Voyager accumulates reusable code skills in Minecraft, AutoSkill distills skills from interaction trajectories, EvoSkill and SkillGen improve skills based on success/failure trajectories, and Anthropic’s Agent Skills standardizes a skill into a portable folder structure.
This work all matters, but MUSE-Autoskill argues that most of it covers only part of the lifecycle.
The paper groups the gaps in existing methods into four categories.
First, creation is disconnected from use. Many systems summarize a skill after a task ends, but when they create the skill they cannot see the agent’s real runtime context. What gets generated may not slot cleanly back into the next execution.
Second, there is no skill-level memory. How many times a skill has been used, which inputs it failed on, its formatting quirks, what to watch for next time you call it: this experience usually isn’t bound to the skill itself.
Third, systematic validation is missing. Many skills look like a polished document but have no tests. An agent believing a skill works does not mean it actually does.
Fourth, long-task context handling is crude. Agent execution trajectories keep getting longer, and a flat conversation history easily blows past the context window. Compress it crudely and you lose the evidence later refinement of the skill depends on.
So MUSE-Autoskill offers a more complete view: a skill should be a long-lived, testable, maintainable, and transferable asset.
It isn’t a text snippet you “write once and toss in the library.” It behaves more like an internal tool on an engineering team: it has documentation, a usage record, tests, version evolution, and the eventual fate of being merged, updated, or deleted.
A Five-Stage Lifecycle: From Generation to Governance
MUSE-Autoskill’s full name is MUSE-AutoskillAgent, where MUSE stands for Memory-Utilizing Skill Evolution. The name runs a little long, but the meaning is clear: use memory to drive the evolution of skills.
The paper splits the skill lifecycle into five stages: creation, memory, management, evaluation, and refinement.
The point to take from the figure is that MUSE does not treat a skill as an isolated module. It wires creation, management, memory, and self-correction into a closed loop.
Creation: Spotting Gaps at Runtime
MUSE ships with a skill_create tool.
When the agent finds that its existing skills fall short, it can propose a high-level spec inside the run loop: what problem this skill should solve, what the inputs are, and what the output should look like. The system then generates a complete skill package from that spec.
The key word here is “runtime.” A skill isn’t written offline and then handed to the agent. It is generated while the agent faces real tasks, real files, and real errors. That makes it easier to capture the details a task involves that documentation never spells out.
Memory: Tie Experience to the Skill
MUSE’s memory has three layers.
Short-term memory holds the current task’s intermediate steps, observations, and temporary outputs. Long-term memory holds general experience across sessions, such as environment preferences, common pitfalls, and project conventions.
MUSE goes a step further with skill-level memory. Next to each skill sits a .memory.md that records that skill’s usage experience: known failure modes, input-format caveats, performance limits, and the traps hit on the last call.
This looks small but matters a lot.
If long-term memory is an entire team’s experience base, skill-level memory is the sticky note attached to each tool. The next time you pick up that tool, alongside the manual you also see what earlier users left behind: which inputs tend to fail, which formats must be followed strictly, which parameter ranges hold up better.
Management: A Skill Bank Needs Ongoing Governance
A skill bank that only grows and never shrinks soon turns into a junk drawer.
So MUSE designs three management actions: merge, update, and forget.
When a new skill heavily overlaps with an existing one, the system tries to merge them to avoid duplication. When a skill fails to run or produces wrong output, the system updates it. A skill that goes long unused or keeps failing gets pruned.
A skill bank does not get stronger just by getting bigger. Without merging, updating, and pruning, growth only makes retrieval noisier and calls less stable.
Evaluation: Tests Must Pass Before Registration
MUSE’s most engineering-minded step is adding a test gate to skills.
Once a new skill is created, the system runs the unit tests under tests/ in a sandbox. Only when the tests pass does the skill get registered into the Skill Bank, where it becomes a capability later tasks can reuse.
What happens when tests fail? On to the next step.
Refinement: Patch the Skill Using Failure Feedback
If a test fails, the agent reads the error trajectory, calls update_skill to patch the skill package, and then reruns the tests.
This forms a create → evaluate → register loop. More precisely, it is create → test → patch → test → register.
This is a long way from the common “write a prompt and pray it works” approach. MUSE tries to move a skill from a documentation asset to an engineering asset: one that can be described, executed, tested, and fixed. That validation-first instinct is the same one driving Microsoft’s SkillOpt, where every candidate edit has to clear a held-out validation gate before it survives.
Key Engineering Design: Skills as Filesystem Assets
The skill package structure MUSE uses is close to Anthropic’s Agent Skills.
A skill is a directory that contains at least SKILL.md, with optional subdirectories such as scripts/, tests/, resources/, and references/.
SKILL.md defines the name, description, inputs and outputs, and usage flow. scripts/ holds executable code, tests/ holds tests, and resources/ holds supporting data or templates.
This figure lays out the end-to-end flow fairly clearly: the Master Agent works in a ReAct loop, and when it needs a skill it either retrieves an existing one from the Skill Bank or hands the job to the Skill Creator to generate a new package; the Evaluator runs the tests; the Refiner patches on failure; and on success the experience is written to Memory.
Three design points here are especially worth pulling apart.
1. Progressive Disclosure: Read the Index First, Then the Full Text
If an agent has 100 skills, it can’t stuff every SKILL.md into the context on every call.
MUSE uses progressive disclosure: the system prompt injects only a lightweight index, exposing just the name and description of each skill. Once the agent decides a particular skill might be useful, it reads the full content via read_skill.
The paper estimates that for a library of 100 skills, loading only the index adds roughly 5K to 10K tokens; stuffing in every skill’s full text might run to 500K tokens.
This is in fact what determines whether a skill system can scale. Without this layer, the more skills you have, the more expensive and slower the agent gets, and the more easily it is distracted by irrelevant information.
2. Skill-Level Memory: Carry Past Experience Into Every Call
The earlier section covered where skill-level memory sits in the lifecycle; here we look at how it takes effect at runtime.
When the agent reads a skill, it loads not only SKILL.md but also the adjacent .memory.md into context. That way the next call to the same skill can inherit the previous failure modes, input boundaries, and validation habits.
This is more precise than cramming all experience into one long-term memory: the experience travels with the specific tool, recall carries less noise, and it’s easier to pin down which skill needs fixing.
3. DAG Context: Compress the Active Chain, Keep the Full History
On long tasks, an agent’s context keeps swelling. MUSE maintains the conversation history as a DAG (directed acyclic graph), where each node records one plan, action, and observation, plus the associated token usage.
It has a two-layer compression strategy.
At the first layer, if a single turn is too large, that turn gets summarized in place. At the second layer, if no single turn exceeds the limit but the whole active chain still goes over budget, a compressible stretch in the middle is merged into one synthetic turn.
The point in the figure is that MUSE compresses the current active chain, but the original history is still kept in the full DAG. That keeps the context budget under control without discarding the evidence you need to review later.
This matters for skill evolution. To patch a skill, you often need to look back at why it failed, what the input was, and where the output went wrong. If history is truncated bluntly, later refinement runs short on evidence.
Comparing It With self-improving-agent
Putting MUSE-Autoskill next to self-improving-agent makes its position easier to understand.
At its core, self-improving-agent is a lightweight closed loop: record errors, review experience, and promote repeatedly validated experience into persistent rules or standalone skills. It mainly addresses how an agent learns from its own behavior.
MUSE-Autoskill addresses a different, more engineering-heavy problem: once skills become an agent’s core capability units, how should the system create, validate, maintain, and migrate those units.
The two clearly share common ground.
Both believe externalizing knowledge is more practical than changing model weights. Model weights are hard to update frequently and run into cost, permission, and catastrophic-forgetting problems. Writing experience as Markdown, scripts, tests, and resource files lowers the bar and makes it easier to review and migrate.
Both also treat Markdown as a knowledge medium an agent can read and write. Markdown’s advantage is that it’s general enough: humans can read it and so can agents; humans can edit it and so can agents.
The difference is mostly in reliability engineering.
self-improving-agent is more like a personal note-taking system. It emphasizes triggering, recording, reviewing, and promoting, which suits adding a self-improvement habit to an agent at very low cost.
MUSE-Autoskill is more like a skill-asset management system. It isn’t satisfied with “writing the lessons down.” It uses package structure, a test gate, failure patching, and cross-agent transfer experiments to address whether a skill is reliable, reusable, and able to leave the system it was born in.
Put simply, the former answers “how does an agent remember a lesson,” while the latter answers “how does an agent turn a lesson into a reliable skill asset.”
Experimental Results: Are Self-Generated Skills Actually Useful?
MUSE-Autoskill ran its experiments on SkillsBench. SkillsBench is an agent benchmark aimed at real tool-use tasks; the paper picked 51 tasks across four domains: Science & Engineering, Data Analysis, Document Processing, and Ops & Planning.
To rule out differences in raw model ability, all three agents in the experiment use GPT-5.5 as the underlying model: Codex, Hermes, and MUSE-Autoskill. The differences come mainly from agent system design, including planning approach, tool strategy, context management, and how skills are used.
Human Skills Bring a Steady Lift
Start with the “skills or no skills” comparison.
Without skills, MUSE-Autoskill’s accuracy is 53.19%. After adding human-written skills, accuracy climbs to 68.40%, a gain of 15.21 percentage points.
Codex goes from 52.11% to 67.28%, and Hermes from 47.89% to 61.21%. In other words, skills help all three agents.
But MUSE has the highest with-skills total, which suggests that beyond simply “having a skill,” it is better at reading, interpreting, and applying skill content inside its reasoning loop.
Self-Generated Skills Are High Quality, but Coverage Is the Bottleneck
The auto-generation experiment matters more.
The paper uses a two-phase protocol.
Phase 1: MUSE-Autoskill attempts the tasks with no skills at all. As long as a task has at least one successful run, the best successful trajectory is chosen and distilled into a skill via skill_create.
Phase 2: the generated skill is injected back, and the task is re-evaluated.
The results expose the bottleneck clearly.
Across the 51 tasks, MUSE successfully generated skills for 35, or 68.6%. Overall, self-created skills brought MUSE’s accuracy to 60.35%, below the 68.40% of human skills.
But looking only at the 35 tasks where a skill was successfully generated, Phase 2 accuracy reaches 87.94%, above the human-skills reference.
This points to something important: the problem is mostly not that the generated skills are low quality, but whether Phase 1 can produce a successful trajectory in the first place.
If the agent fails completely on its first attempt, there’s no successful experience to distill. The 16 tasks with no generated skill count as 0 in the overall average, which drags the total score down.
Cross-Agent Transfer: Can a Skill Leave Its Native Agent?
The paper also ran a cross-agent transfer experiment.
They injected MUSE-generated skills into Hermes unchanged. Without skills, Hermes scores 47.89%; with the MUSE-generated skills, it rises to 58.40%, closing 79% of the gap between it and human skills.
More tellingly, when Hermes and MUSE both use the same batch of MUSE-generated skills, Hermes is at 58.40% and MUSE at 60.35%, a difference of only about 2 percentage points.
This shows the generated skills aren’t tightly bound to MUSE’s internal behavior. Once externalized as documents and scripts, they can indeed be picked up and used by another agent system.
That is what a skill means as a “knowledge asset”: not merely the residue of one reasoning run, but a capability package that can move, be reused, and be handed to another system.
Cost: Writing a Skill Is Expensive; Using One Saves Money
Seeing a skill package grow longer, many people worry token costs will rise. The paper’s findings are more nuanced than that intuition.
Across the 35 tasks where a skill was successfully generated, the one-time median cost of generating a skill is about 383K tokens and 164 seconds of agent time. That cost is indeed not low.
But on reuse, generated skills actually make execution cheaper.
Using human skills, MUSE-Autoskill’s median is 615K tokens, 656 seconds, and 19 turns; with a generated skill, it drops to 493K tokens, 411 seconds, and 15 turns. Hermes drops more sharply: from 186K tokens and 369 seconds to 97K tokens and 257 seconds.
The figure shows generated skills strike a better trade-off across reward, latency, and tokens. The reason isn’t mysterious: although the skill text is longer, it compresses a once-noisy exploration process into a clearer operating procedure.
The paper also offers an amortization calculation. For MUSE, the 383K-token cost of generating a skill, given a saving of 122K tokens per use, breaks even after roughly three reuses.
This is the part most worth watching from an engineering standpoint: a skill’s value lies not in the first generation but in later reuse.
A Few Cases: Why Generated Skills Can Beat Human Skills
The paper lists several concrete tasks that make the point well.
The first is adaptive-cruise-control, which asks for a discrete PID controller that meets validation constraints on overshoot, steady-state error, rise time, and the like. Without a skill, MUSE succeeds only 40% of the time. The generated skill wrote in the discrete PID equations, an anti-windup strategy, gain-tuning heuristics, and the JSON format the verifier requires, and Phase 2 reaches 100%.
The second is flink-query, which asks for an Apache Flink Java job that processes a gzip-compressed Google ClusterData trace and outputs an exact format. The baseline often gets stuck on details like project scaffolding, POJO conventions, and event-time sessionization. The generated skill spells out schema parsing, the AppBase extension protocol, the session trigger, and the Maven validation steps, and accuracy likewise reaches 100%.
The third is weighted-gdp-calc, which asks for conditional lookups and a weighted mean in an Excel workbook while preserving formatting and avoiding macros and VBA. The generated skill explicitly specifies openpyxl, lists the formula patterns, and adds a recalculation check on target cells, taking the baseline from 20% to 100%.
These cases show that the value of a successful trajectory is in exposing the implicit engineering conditions. When humans write a skill they often skip the “I assumed you knew that” parts; an agent distilling a skill from a trajectory instead pins down the file formats, validation steps, and edge conditions, the small but critical operating requirements.
Limitations: A Successful Trajectory Can Mislead
MUSE-Autoskill’s approach is appealing, but the paper also shows several of its boundaries.
The biggest bottleneck is Phase 1 coverage. Self-generated skills depend on successful trajectories. If the agent can’t solve a task at all without a skill, there’s no material to distill. Of the 51 tasks in the paper, 16 produced no skill, concentrated mostly in scientific computing and systems operations, where the baseline is weaker.
The second issue is the source-trajectory assumption.
Generating a skill distills experience from one successful run, but a single success isn’t a general rule. The paper’s hvac-control shows a clear regression: the task asks to control a first-order thermal simulator, and the calibration window and gain-estimation method in the source trajectory were fitted to that simulator’s noise distribution. On a fresh batch of runs, the variance in the calibration data occasionally pushed the tuned gains past the stability boundary, and accuracy dropped from 80% to 20%.
The reminder here: the biggest danger in distilling experience is mistaking an incidental condition for a general method.
Third, the test mechanism points in the right direction, but test quality sets the ceiling.
MUSE requires a new skill to pass tests before registration, which is a strong engineering constraint. In reality, though, tests for many complex tasks are hard to write. Tests that are too narrow let through skills that overfit the source trajectory; tests that are too broad can raise generation and maintenance costs.
The paper’s Figure 6 also shows that only some of the skills MUSE generates include tests/. That means “test-driven skill evolution” is still a direction rather than a fully solved problem.
The Shift Ahead: An Agent’s Unit of Capability Is Being Externalized
The most notable thing about MUSE-Autoskill isn’t any single score.
What it pushes is an abstraction change: an agent’s unit of capability is gradually moving from being part of the model weights to a readable, testable, transferable skill package.
This changes a lot of engineering judgments.
We used to ask, “Should we switch to a stronger model?”
Now we also ask, “Can this success settle into a reusable skill? Does the skill have tests? Does it have usage memory? Can another agent use it? Will it patch itself after a failure?”
self-improving-agent shows the lightweight version of the answer: use Markdown and logs to teach an agent to remember its lessons first.
MUSE-Autoskill gives a more systematic answer: make skills a first-class asset, and build a lifecycle of creation, memory, management, evaluation, and refinement around them. Read alongside Microsoft’s SkillOpt, which trains the skill file against a validation gate, the two land on the same conclusion from different angles: skills are becoming trained, versioned artifacts rather than static instructions.
The competition among future agents may come down to two things: how strong the model is, and who can settle experience into verifiable, transferable, evolvable skill assets.
Related Reading
- SkillOpt: Stop Hand-Writing AI Agent Skills. Train Them. — Microsoft Research’s approach to optimizing a skill file with rollouts, bounded edits, and a validation gate.
- 10 Claude Code Skill-Writing Patterns the Docs Don’t Teach You — how Anthropic’s engineers actually structure
SKILL.mdfiles.
References
- Huawei Lin, Peng Li, Jie Song, Fuxin Jiang, Tieying Zhang: MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation, arXiv, 2026-05-27
- Yutao Yang et al.: AutoSkill: Experience-driven Lifelong Learning via Skill Self-Evolution, arXiv, 2026
- Siru Ouyang et al.: SkillOS: Learning Skill Curation for Self-Evolving Agents, arXiv, 2026
- Anthropic: Agent Skills Documentation, 2025