What is WikiSkill? Google's persistent-memory framework for AI agents

What WikiSkill actually is

Most AI agents have amnesia. You give one a task, it works through it, and whatever it figured out along the way, the clever workaround, the dead end it wasted ten steps on, disappears the moment the run ends. The next task starts from scratch. That is fine for a one-off, but it is a terrible way to get better at a job you do thousands of times.

WikiSkill is Google Research's answer to that. Published on arXiv on 27 August 2026 by Liyan Tang, Cyrus Rashtchian, and four colleagues, it is a framework that co-evolves an agent's skills alongside a persistent knowledge base, a "wiki", that accumulates across runs. The central question the authors pose is blunt: can an agent's experience be compiled into persistent knowledge that supports long-term skill evolution?

A quick definition first, because "skill" has a specific meaning here. An agent skill is a reusable, file-based module, an organized folder with a SKILL.md that carries procedural instructions and the conditions for when to apply them. It extends what an agent can do without touching the model's weights. Prior research already tried to discover these skills automatically from agent runs. WikiSkill's contribution is what sits between the raw experience and those skills: a structured, growing wiki.

The idea has a well-known lineage. The paper credits Andrej Karpathy's 2026 "LLM Wiki" perspective, the argument that we should be compiling model experience into persistent, compounding knowledge rather than letting it scatter. elvis (@omarsar0), founder of DAIR.AI, made the same connection when the paper landed:

"This WikiSkill paper from Google is a must-read. At a high level, it shows the effectiveness of persistent agents, knowledge bases, and skills. @karpathy popularized LLM Wikis. But this paper provides an actual framework for how agents can tap into a wiki of skills that evolve."

elvis (@omarsar0), X

The three layers: raw, wiki, and skill

The whole design comes down to keeping three things separate that most systems mush together: what happened, what you learned, and what you do next. WikiSkill gives each its own layer.

The Raw Layer (raw/) is the diary. It stores complete execution traces from each run: the agent's reasoning, every tool call, every result, the final answer. It is immutable, so nothing gets rewritten after the fact. It is the raw material everything else is built from.

The Wiki Layer (wiki/) is where experience becomes knowledge, and it is the heart of the framework. It holds a directory of pattern pages, each documenting one failure mode or one successful strategy with a concrete workaround, plus an evolution log and a skill-impact tracker. The load-bearing rule: the wiki never resets and is never rolled back. It only accumulates. Even when a skill experiment fails, the lesson from it stays written down.

The Skill Layer (skills/) is the part the agent actually reads at work. Each skill folder has a SKILL.md with the instructions and a PURPOSE.md that maps the skill back to the wiki patterns that motivated it. Unlike the wiki, skills here are reversible. A change that hurts performance gets reverted.

That split, permanent memory versus reversible action, is the clever bit, and it is easy to miss. Here is the same idea as a picture.

How the evolution loop works

Each round of learning runs a four-step loop, and one of the steps is properly counterintuitive.

1. Inference Agent. It runs the current skills on training tasks and produces the raw traces. Notably, the paper deliberately blocks this agent from reading the wiki during training. An ablation showed that letting it peek at the wiki here actually hurts final skill quality, dropping the average from 63.7% to 60.9%. The hypothesis: if the agent gets its answers from the wiki instead of the skills, its traces stop being useful evidence for improving the skills.
2. Wiki Maintainer. It reads a sample of successful and failed traces, does root-cause analysis on the failures, pulls strategies out of the wins, and writes all of it into the wiki as pattern pages.
3. Skill Proposer. A multi-turn agent that starts from the wiki index and the running history, then reads specific pattern pages on demand. It proposes exactly one atomic change, either a new skill or an edit to an existing one.
4. Gating and rollback. The proposed skill set is scored on a separate validation split. If it beats the running best, it is accepted; if not, it is reverted. Either way, the wiki keeps the record of what was tried.

The Google team's own case study makes this concrete. On the ALFWorld benchmark, the proposer's first attempt at a "goal-directed-action" skill was rejected for being too abstract. Because the rejection and its reasoning were preserved in the wiki, the next iteration wrote a sharper, accepted skill with a specific rule ("Never return an item to its origin location"), then refined it further several iterations later as new failure variants showed up.

An ablation in the paper backs up why the wiki earns its keep: giving the Skill Proposer access to the persistent wiki lifted average benchmark performance from 48.7% to 63.7%, a 15-point jump. The memory is not decoration; it is where most of the gain comes from.

Does it actually work? The numbers

Yes, and consistently, which is the part that separates this from the usual research-demo caveat. The team tested five models across five benchmarks (math, web search, spreadsheets, long-context document QA, and interactive tasks), each averaged over three full runs.

Source: Tang et al., 2026. Some single-benchmark jumps were larger still: Gemini-3.5-Flash on the math benchmark went from 33.0% to 72.6%, and Qwen-3.6-27B on spreadsheets climbed from 40.8% to 81.7%.

WikiSkill also beat every competing skill-evolution method (Trace2Skill, EvoSkill, and SkillOpt) on average for all five models, and unlike those methods it rarely made any single benchmark worse. That reliability is the quiet headline. A method that helps on average but tanks one task in three is hard to trust in production, which is the same reason support teams care so much about AI ticket resolution rates holding up across every query type, not just the easy ones.

The finding I keep coming back to: skills can substitute for scale. Qwen-3.5-9B with WikiSkill (47.4%) beat the much larger Qwen-3.6-27B with no skills (39.4%). Procedural knowledge and raw model size turn out to be complementary, not interchangeable.

Skills that move between models

Here is the result that got the most attention. Skills evolved by one model transfer to other models and families, and transferred skills frequently beat both no skills and a model's own self-evolved skills. On ALFWorld, Qwen-3.5-9B reached 70.2% using a skill that Qwen-3.6-27B had evolved, versus 63.4% with its own skill. Small-to-large works too: skills from the tiny Qwen-3.5-4B lifted the much larger Gemma-4-31B on the math and interactive benchmarks.

Mark Kretschmann (@mark_k) flagged this as the most interesting part:

"'WikiSkill' lets agents turn their own experience into persistent knowledge that compounds over time... Even more interesting: skills transfer between models. In some cases, a model performed better using skills learned by another model than skills it developed itself."

Mark Kretschmann (@mark_k), X

The authors' read is that discovering a good skill and executing it are two different abilities, and self-evolution normally conflates them. It is a useful reframe if you are choosing an LLM for support work: the best model at running a playbook is not automatically the best at writing one.

Transfer is not free, though. Skills that bake in model-specific workarounds can backfire. The tiny Qwen-3.5-4B's spreadsheet skills, full of low-level Python hacks, actually cut Gemini-3.5-Flash from 50.5% to 18.1%, because they constrained a stronger model from writing cleaner end-to-end code. So "skills transfer" is a real property, but one to test case by case rather than assume.

The honest catch: it is a workaround, not real learning

This is the part most coverage soft-pedals, and it is the part worth being clear-eyed about. WikiSkill does not make the underlying model learn. The weights never change. THE DECODER put it plainly: the agent "doesn't truly learn in a continuous sense, which remains an unsolved problem." Instead, "it writes better instructions for itself after each run and can pull them up the next time around." Their verdict on the approach was that it is "not elegant, and it's probably more error-prone than real learning, but the study shows it's an effective workaround."

That framing is the right one to carry into any buying decision. A system like this is only as good as the knowledge it writes down and the gate that filters it. The paper is upfront about the limits, too:

• No wiki pruning. The wiki only grows, so over very long runs it will need a way to forget stale patterns, which does not exist yet.
• Strict gating. A proposed skill has to improve the validation score to be kept, which throws away neutral changes that might have paid off later.
• No skill retrieval tested. To isolate skill quality, the study injected all skills directly into the prompt rather than retrieving the relevant ones, which matters once you have a lot of them.
• No official code. As of September 2026, Google has not released WikiSkill code. An independent developer reimplemented it from the paper, and even noted the validation gate caught two harmful skills in his run, corroborating that the safety check does real work.

None of this makes WikiSkill less interesting. It makes it honest, and an honest description of what an AI system does and does not do is exactly what I look for before trusting one with real work, which is the same bar I would apply when weighing AI against human agents.

What this means for AI support agents

Strip away the benchmarks and WikiSkill is describing a shape that support and CX teams should recognize immediately: an agent that gets measurably better at a repeated job by compiling its own experience into reusable, checkable knowledge. It is a pattern the companies already using AI for support lean on, not a lab curiosity. It is the whole point.

elvis made the same jump from research to practice:

"The practical takeaway here is that we should all be thinking about how to build persistent knowledge bases across our companies and projects. And how to use that to upgrade and evolve our skills."

elvis (@omarsar0), X

A support queue is the ideal home for this pattern. Your past tickets are the raw layer. Your macros, help center, and resolved threads are the wiki. And the "gate before you accept a change" idea is the one thing most AI support rollouts skip and later regret, because they flip a bot live and hope. This is where the research and the reality of customer support automation meet: the teams that win are the ones that measure before they trust, the same way WikiSkill's gate checks a skill before keeping it. It is also why the honest cost comparison of AI and human agents keeps landing on "measure the resolution rate first."

Try eesel for support that learns from your tickets

The reason WikiSkill reads as familiar to me is that eesel's AI helpdesk teammate already works on this principle. It is not a generic chatbot bolted onto your site; it trains on your existing knowledge, past tickets, help center, and docs, and joins the queue inside the helpdesk you already run, whether that is Zendesk, Freshdesk, Gorgias, or Help Scout, across 1000+ integrations.

The differentiator that maps most directly to WikiSkill's gate is simulation. Before an eesel teammate answers a single live customer, you can run it against your historical tickets and see how it would have handled them, so the resolution rate is a number you check, not a promise you take on faith. It is the "validate before you accept" discipline, applied to your own support history. You can try eesel free, no sales call required, and one customer, Global Pay, reported up to 80% time savings once it was live.