WikiSkill Paper Explained: Why a 4B Small Model Can Be a Great Teacher for a 27B Large Model
WikiSkill shows a 4B model writes better skills for a 27B executor via layered isolation architecture.
The WikiSkill paper introduces a three-layer architecture—Raw, Wiki, and Skill layers—that decouples skill discovery from skill execution in self-improving agents. Its most striking finding: a 4B model writing explicit, step-by-step skills outperforms the 27B model writing its own by ~5%. The paper also shows that hiding the Wiki layer from the execution agent prevents shortcut-taking. These insights offer practical guidance for Agent developers on separation of concerns, persistent failure logging, and cost-effective model pairing.
The Architectural Dilemma of Self-Improving Agents
When building multi-agent systems or custom Agent loops, one fundamental question is inescapable: how do you enable agents to continuously learn from their own mistakes?
The vast majority of self-improvement frameworks today use a monolithic process—run the task, observe errors, update prompts, all within a single loop. While seemingly efficient, this approach harbors hidden risks: errors cross-contaminate within a single loop, making it difficult to pinpoint root causes.
The recently discussed WikiSkill paper proposes a radically different approach: fully decoupling "skill discovery" from "skill execution." Even more striking, the paper validates a counterintuitive conclusion—a smaller 4B model can actually serve as an excellent "teacher" for a 27B large model. This finding is worth deep examination for any developer building Agent workflows.
Three-Layer Architecture: From Raw Traces to Executable Skills
WikiSkill's core innovation lies in splitting the agent's memory and skill system into three independent layers, each with clearly defined responsibilities.
Raw Layer
This layer stores immutable execution traces, including tool calls, reasoning processes, and outputs. It serves as a complete "black box" record upon which all subsequent analysis is built.
Immutability is key—it guarantees audit trustworthiness.
Wiki Layer
This is the most elegant design in the entire architecture. The Wiki Layer is a persistent, never-deleted memory store that specifically records:
- Root-cause analysis
- Recurring error patterns
- A rigorous audit trail documenting all rejected skill updates
This "list of rejected updates" deserves special attention—it prevents the agent from repeating the same mistakes. Traditional frameworks typically retain only successful experiences, but WikiSkill archives failed attempts as well, forming a complete knowledge loop.
Skill Layer
The top layer contains the skill files (.md format) that the agent actually reads during inference. These files are distilled, directly executable operational specifications. The agent interacts only with this layer during actual work, avoiding interference from the massive volume of raw data underneath.
Key Finding 1: Skill Discovery ≠ Skill Execution
The most paradigm-shifting conclusion from the WikiSkill paper is: the ability to write skills and the ability to execute skills are two entirely different things.
The researchers designed an elegant experiment: they had Qwen-3.5-4B read the Wiki layer and author programmatic skills, then handed those skills to the larger Qwen-3.6-27B for execution. The results were surprising:
| Skill Author Model | 27B Model Score on LiveMath |
|---|---|
| Written by 4B model | 61.0% |
| Written by 27B model itself | 56.3% |
A gap of nearly 5 percentage points reveals a deep underlying mechanism.
Why Are "Lesson Plans" Written by Smaller Models More Effective?
The answer is: smaller models are forced to write highly explicit, step-by-step operational guides.
A 4B model cannot rely on powerful implicit reasoning to "skip steps"—it must spell out every single step clearly. And this happens to be exactly the input format that a 27B large model excels at executing. Large models are outstanding "executors" but tend to omit critical steps when writing skills because they take things for granted.
This finding has direct implications for engineering practice: when designing teacher-student architectures, there's no need to blindly pursue "bigger is better." Using small models for knowledge distillation and skill refinement, and large models for actual execution, may be the superior cost-performance combination.
Key Finding 2: The Wiki Layer Should Not Be Visible to the Execution Agent
The second key finding comes from ablation studies. Researchers tested what happens when the Inference Agent is allowed to read the Wiki layer during training.
The result was a drop in win rate.
The reason is that the agent "cheats": it grabs answers directly from the Wiki layer's raw analysis, bypassing the programmatic skills it should be following, thereby contaminating the execution traces.
In other words, when the agent can see "the derivation process of the standard answer," it loses the motivation to learn and follow structured skills. The paper thus establishes a clear architectural principle:
The Wiki layer should be visible only to the agent responsible for proposing skills, and invisible to the execution agent.
This is a classic information isolation design. It ensures the purity of the execution layer and makes skills genuinely reusable and verifiable assets, rather than one-off temporary memories.
Practical Implications for Agent Development
The patterns validated by WikiSkill are essentially a victory for observability-driven development. They offer Agent developers several immediately actionable ideas:
1. Separation of Concerns Brings Robustness
Decoupling discovery, documentation, and execution prevents error cross-contamination within a single loop. Each layer can be independently audited and optimized, enabling rapid problem localization.
2. Persistent Failure Records Are Equally Valuable
That "audit trail of rejected updates" is the key to preventing agents from falling into the same traps repeatedly. Many teams focus only on success paths, but WikiSkill demonstrates the long-term value of systematically recording failures.
3. Model Size Isn't the Only Answer
The division of labor—small models as "skill authors" and large models as "skill executors"—offers a fresh perspective on cost optimization for multi-agent systems. Not every component needs to run on the largest model available.
4. Information Isolation Prevents Shortcut Dependency
What information each agent gets to see requires careful design. Providing too much information can actually lure agents into taking shortcuts, ultimately harming overall performance.
Conclusion
WikiSkill's value lies not in proposing a single technical breakthrough, but in systematically validating a transferable architectural pattern: layering, isolation, persistence, and leveraging the complementary strengths of models at different scales.
For developers building custom Agent loops, this persistent cross-iteration state graph design may be exactly the critical step from "it works" to "it continuously improves."
As agent systems grow increasingly complex, enabling them to truly learn from experience—rather than falling into repetitive error loops—will become a core competitive advantage. WikiSkill offers a clear and powerful answer: let small models be teachers, let large models be executors, and safeguard quality through rigorous layered isolation in between.
Related articles
From Backend to AI Agent Engineer: A Practical Path That Survived Big Tech P7 Interviews
How can a backend engineer with 6 years of experience transition to AI Agent engineering and pass big tech P7 interviews? A practical guide covering engineering stability, semantic caching, Anthropic's ecosystem, and MCP protocol.
Free Claude Code: Real-World Testing of the 48K-Star Open Source Agent — Saves Money, But Don't Expect a Free Replacement
Deep dive into Free Claude Code (FCC), a 48K-star open-source project that routes Claude Code requests to free or cheaper models via proxy. Covers setup, tiered routing, real coding tests, and cost savings.
Claude Code Weekly Limit Cut by 17%: How Should Developers Respond?
Claude Code recently cut its weekly usage limit by ~17%, sparking developer debate. This article analyzes the reasons, real-world impact, and strategies to adapt.