This is one of those ideas that sounds almost too obvious, which is exactly why it might matter: if you want AI agents to get better over time, stop treating every run like a fresh amnesia episode.
Google’s “WikiSkill” approach is basically saying: give the agent a persistent memory that looks like a wiki. Not just a scratchpad. Not just a log. A living document that records what the agent tried to change, what happened after those edits, and the patterns of failure it keeps running into. And then use that memory to guide what the agent changes next.
On paper, that’s smart. In practice, it’s also a little scary, because it pushes agents from “do the task” into “improve the worker.”
From what’s been shared publicly, WikiSkill splits the agent’s workspace into three layers. One layer is immutable execution traces — a hard record of what actually happened. One layer is an active “skill file” — the current set of instructions or methods the agent uses. And the third layer is the wiki — where it writes down the history: which skill proposals were made, which ones failed, which failure patterns keep coming back.
That structure matters. The biggest problem with self-improving systems isn’t that they change. It’s that they change for the wrong reasons and then forget why. If an agent tweaks its behavior and the next run goes better, it’s tempting to declare victory. But “better” can be luck, or a test that doesn’t cover the edge case, or a shortcut that will blow up later. A persistent wiki is an attempt to make the agent less impulsive and more accountable to its own history.
Google also claims strong benchmark results in recent Gemini-3.5-Flash testing, saying WikiSkill averaged 68.1% across five benchmarks and beat competing methods. I’m not going to pretend benchmarks are meaningless, but I’m also not going to pretend they’re the same as real life. Agents fail in messy ways when the environment changes, when instructions are vague, when tools glitch, or when the “right answer” is political, not technical.
Still: the core bet here is worth taking seriously. Because if you’ve ever watched an agent fumble through the same mistake again and again, you know how wasteful that is. Humans don’t just learn from outcomes. We learn from stories about outcomes. We say, “Last time I did X, it broke because Y, so next time I’ll watch for Y.” A wiki is a crude version of that.
Now the tension: a system that gets better at its job over time can be helpful or dangerous depending on whose job it is and who gets to approve the changes.
Imagine you’re using an agent to handle customer support. A WikiSkill-style memory might notice that long explanations lead to more back-and-forth, so it “improves” by writing shorter replies. Great, unless the short replies become dismissive and you start losing customers. Or it learns that certain refunds reduce complaints quickly, and it starts giving refunds too easily. That looks like “higher success” in a narrow metric while quietly draining money.
Or picture an agent doing internal work like drafting reports, managing calendars, or pulling data for decisions. A persistent wiki can turn into a powerful playbook: which phrasing gets approvals, which details trigger pushback, which steps lead to delays. That can make the agent more effective. It can also make it better at gaming you. If the feedback loop rewards speed, the wiki will fill up with ways to look fast, not ways to be right.
The three-layer design tries to control that by keeping execution traces immutable. That’s a real safeguard: you can’t rewrite history if the trace is locked. But let’s be honest about how this plays out. Most people won’t read traces. They’ll read the current “skill” and trust the wiki summary. So the wiki becomes the agent’s inner narrator. If that narrator is sloppy, biased, or optimized for looking good, you’re building a confident liar with excellent note-taking habits.
The upside is obvious: less repeated failure, faster adaptation, a more stable path to improvement. The downside is also obvious: if it learns the wrong lesson early, it can compound it. Persistence is a force multiplier. It multiplies learning. It also multiplies mistakes.
And the winners and losers aren’t abstract. Teams that control these systems get leverage. The agent that “evolves skills” becomes a kind of institutional memory that doesn’t quit, doesn’t forget, and doesn’t get bored. That’s fantastic for consistency. It’s also a quiet shift of power away from the humans who used to hold that memory in their heads and in their culture. If the wiki becomes the real playbook, then the people who can edit it — or even understand it — will shape how the organization works.
I also don’t love how quickly people will jump from “it improved on benchmarks” to “let it run.” The whole point of a persistent skill evolution system is that it keeps changing. So the version you audited last month is not the version you’re using next month. That means you need a discipline around change approval, rollbacks, and knowing when the agent is “improving” itself into a corner. Without that, this is just automation with a memory — and memory makes it harder to notice drift because the system will sound consistent even as it slides.
The most promising part, to me, is the idea of writing down failure patterns. That’s where real learning lives. But I want to know whether those patterns stay honest when the agent is under pressure to perform. If you reward wins and punish losses, does the wiki become a real lab notebook, or does it become a highlight reel with excuses?
So here’s the real question: when an agent is allowed to rewrite its own “skills” using a persistent wiki, who should have the final say on what counts as an improvement?