WikiSkill Found That Agent Skills Transfer Better Than the Models That Wrote Them
Google Research evolved agent skill files against five benchmarks and five models, then swapped the files between model families. A 9B model did better with a 27B model's skill than with the one it wrote for itself.
A 9-billion-parameter model, handed a skill file written by a 27-billion-parameter model, scored 70.2% on ALFWorld. The same 9B model running the skill it evolved for itself scored 63.4%.
That number sits in the introduction of WikiSkill, posted to arXiv on August 27 by six researchers at Google Research. It is one sentence in a paper that spends most of its pages on something else, and it is the sentence worth arguing about, because it suggests the competence your agent stack accumulates over a year of use may not belong to the model you accumulated it on.
If that holds, a lot of procurement anxiety in this industry is pointed at the wrong object.
What the paper is actually building
Agent skills are reusable files. Instructions, procedures, sometimes code, sitting on disk, read at inference time, changing what an agent does without changing a single weight. Anthropic ships them, Cursor reads them, Codex reads them, and the research community has spent the last year trying to generate them automatically from an agent's own execution history rather than having humans write them.
The generation part mostly works. The accumulation part does not. WikiSkill's authors put the failure precisely: the insights that guide skill development "typically remain scattered across optimization histories, limiting their systematic reuse across iterations." A system runs a task, fails, learns something, writes a better skill, and then the reasoning that produced the improvement evaporates. Next round it rediscovers the same lesson from scratch.
So WikiSkill separates three things most systems mash together. Raw execution experience is the trace of what happened. Accumulated knowledge is what those traces taught, consolidated into a persistent wiki. Executable skills are the files an agent actually reads. Experience flows into the wiki continuously, and every subsequent skill update builds on the wiki instead of on the raw history.
The wiki is the part doing the work. Ablations confirm it, and one of the paper's own section headings makes a point I did not expect: giving the inference agent access to the wiki during evolution degrades the final skill quality. The knowledge base is for the thing writing skills, not the thing running them.
The numbers
Five benchmarks, chosen to be unalike: LiveMathematicianBench for math, SealQA for web search, SpreadsheetBench for spreadsheet manipulation, OfficeQA for long-context document questions, ALFWorld for embodied interactive tasks. Five models: Gemini-3.5-Flash as the closed one, plus Qwen-3.5-4B-Instruct, Qwen-3.5-9B-Instruct, Qwen-3.6-27B and Gemma-4-31B-It served through vLLM. Three prior skill-evolution methods as baselines (Trace2Skill, EvoSkill, SkillOpt), plus each model with no skills at all. Test accuracy averaged over three runs.
Average across all five benchmarks:
| Model | No skill | Trace2Skill | EvoSkill | SkillOpt | WikiSkill |
|---|---|---|---|---|---|
| Qwen-3.5-4B | 26.2 | 32.1 | 33.7 | 35.2 | 38.5 |
| Qwen-3.5-9B | 29.9 | 36.7 | 42.3 | 40.2 | 47.4 |
| Qwen-3.6-27B | 39.4 | 47.3 | 53.3 | 50.7 | 63.3 |
| Gemma-4-31B | 41.3 | 45.8 | 43.4 | 49.1 | 54.9 |
| Gemini-3.5-Flash | 49.5 | 55.6 | 56.1 | 55.9 | 68.1 |
Read the second and third rows together. Qwen-3.5-9B with skills lands at 47.4. Qwen-3.6-27B without skills lands at 39.4. A model roughly a third the size, given a good enough procedure file, walks past a model three times larger running bare.
Then the transfer result on top of it. Skills the 27B evolved, dropped into the 9B, beat what the 9B produced for itself by 6.8 points on ALFWorld.
The position I will take
The skill directory is the durable asset. The model is increasingly the substrate you run it on.
That is a stronger claim than the paper makes, and I want to be honest that I am extending it. But look at what has to be true for the transfer result to work at all. A skill written by one model, in one family, at one size, encoded something general enough about the task that a differently trained model could execute it and gain. Not vibes. Procedure. "Check the inventory before opening the container." "Normalize the column headers before the join." Knowledge that was always about the world rather than about the weights.
Every piece of infrastructure advice follows from that. If skills are portable, then the year of accumulated operational knowledge sitting in your agent's skills directory survives a model migration. It survives a price change. It survives a vendor doing something you dislike. That is a very different asset profile than a fine-tune, which dies with the checkpoint it was trained onto.
It also reframes what open-weight models are for. If a 9B model with a mature skill library performs like something several times its size, the interesting question stops being "which frontier model" and becomes "how good is our procedure library, and can we run it somewhere cheap."
The result that argues against me
I would be selling you something if I stopped there. The paper's scaling finding cuts the other direction, and it is stated plainly: within the Qwen family, WikiSkill improved average performance by 12.3, 17.5 and 23.9 points for the 4B, 9B and 27B models, "with gains increasing with model scale."
Bigger models got more out of skills, not less. The 4B gained half what the 27B did.
So the honest version of the story is not "skills rescue small models." It is that skills and scale multiply, and a model needs enough capability to execute a good procedure before a good procedure helps it much. The 9B-beats-27B comparison is real, but it is a small model with skills against a larger model with none, which is not a configuration anyone would deliberately ship.
Putting this into practice
You do not need WikiSkill's machinery to act on the finding. Three things, in order of how little they cost.
Version your skills separately from everything else. If your agent's skill files live inside an application repo, pull them into their own directory with their own history. The claim you are betting on is that these files outlive the model choice. Store them like you believe it.
Write procedures, not workarounds. The paper notes that transferability depends on whether a skill captured a general procedure or a model-specific patch. A skill that says "this model forgets to close the file handle, so remind it" will not survive a model swap and will actively mislead the next one. A skill that says "close the handle before the assertion, because a failed assertion skips the cleanup block" is about the code. Audit your existing skills with that distinction in hand and you will find more of the first kind than you expect.
Run the cheapest possible transfer test before you standardize. Take one skill file you rely on. Run the task it covers against a second model from a different family, unchanged. Ten minutes. If it holds, you have evidence your library is an asset rather than a habit. If it collapses, you have found the model-specific coupling that would have surprised you during a migration instead.
And if you are choosing between spending the next quarter on model evaluation or on skill hygiene, this paper is a mild argument for the second.
Honest limitations
This is a preprint from August 27, one day old at the time of writing, with no listed venue and no code repository I could find in the retrieved text. Treat every number as unreplicated.
The sweep is 25 model-benchmark cells, and WikiSkill beats its own no-skill baseline in 23 of them. That is genuinely strong, and the two exceptions are worth naming since the abstract compresses them into "most." Qwen-3.5-4B on OfficeQA got worse with skills, 28.5 against 30.2 with none. Gemini-3.5-Flash on ALFWorld tied at 85.9, and every baseline method also scored exactly 85.9 on that cell, which looks like a ceiling rather than a result.
A separate caveat, and one the averages hide: beating no-skill is not the same as beating the other skill-evolution methods cell by cell. WikiSkill takes the best average for every model, but on individual benchmarks it loses several. EvoSkill tops it on LiveMath and SpreadsheetBench for Qwen-3.5-9B, and SkillOpt tops it on OfficeQA for Qwen-3.6-27B. The paper applies a paired bootstrap with 1,000 iterations at p<0.05 and bolds statistical ties, so some of those gaps may not be meaningful. The headline is an average, and averages have structure underneath them.
The transfer claim, which is the part I have built an argument on, rests in the publicly readable portion of the paper on a single model pair on a single benchmark. The full transfer matrix is in Table 2, which I was not able to retrieve. One data point in the direction of a surprising conclusion is a reason to run your own test, not a reason to reorganize your stack.
ALFWorld, SpreadsheetBench and their neighbors are also benchmarks, with the tidiness benchmarks have. Nobody in this literature has shown that a skill evolved against a clean evaluation harness survives contact with a codebase where half the procedures are wrong, three are load-bearing, and nobody remembers who wrote them.
One more thing, and it is the risk this whole research direction is not pricing. A skill file is durable, self-authored, machine-trusted instruction. If it transfers across models as well as this paper suggests, then so does anything else written into it. A poisoned procedure is portable for exactly the same reason a good one is. Put the review gate on your skills directory that you already have on production code, because that directory now behaves like production code.
What I would actually do this week
Open your skills directory. Pick the file your agents hit most often. Read it and ask one question: is this a description of the work, or a description of a model's quirks?
That answer tells you whether you have been building an asset or a dependency, and you can get it in about fifteen minutes without reading a single paper.
Sources: WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution (arXiv:2608.27454v1, Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, Andrew Tomkins, Da-Cheng Juan and Tu Vu, submitted 27 August 2026, CC BY 4.0). Table figures and quoted phrases read from the paper's abstract page and HTML rendering; Table 2 and the appendices were not retrievable at the time of writing and are flagged as such above.