Agents That Write Their Own Playbooks
EvoSkill turns failure logs into reusable skill modules — automatically. No labeling. No annotation. Just an evolutionary loop that reads what broke and writes a fix that generalizes.
Every agent fails. The question is what happens after.
Most setups: failure gets logged, maybe triaged, sometimes a human writes a new prompt. The cycle runs on manual intervention. The agent doesn't get better on its own — it waits.
EvoSkill changes that loop. Failure is the input. A better skill is the output. No human in the middle.
EvoSkill: Automated Skill Discovery for Multi-Agent Systems. A self-evolving framework that runs execution failures through an iterative analysis loop, proposes new skills or patches to existing ones, and materializes them into structured skill folders — with selection governed by a Pareto frontier against held-out validation data. The underlying model never changes. Only the skills do.
The Loop, Exactly
Five steps, repeating:
- Run the agent. Let it attempt the task.
- Collect failures. Track where it broke, what it produced, what the expected output was.
- Analyze failure → propose skill. An LLM judge reads the failure and either drafts a new skill module or patches an existing one.
- Materialize into a skill folder. The proposed skill gets written into a portable, reusable format — not a hardcoded prompt patch, a structured workflow module.
- Pareto selection. The new skill runs against a held-out validation set. If it improves across multiple objectives without regressing on others, it survives. If it optimizes one metric at the cost of another, it gets dropped.
That last step is underrated. Most skill evolution systems optimize for a single metric and overfit. The Pareto frontier forces the system to find skills that improve broadly — accuracy, reliability, efficiency — not just on the case that triggered the fix.
The Numbers Are Serious
The transfer result is the one that matters most. Skills evolved on SealQA work on BrowseComp without retraining. The skill folders are genuinely portable artifacts — not prompt hacks tied to one benchmark but reusable workflow logic that transfers to new task structures.
That's a different kind of improvement than "we tuned the prompt better." It means the system is discovering abstractions that hold across contexts.
Why Skills-as-Folders Is the Right Abstraction
This is the design choice in EvoSkill I want to sit on, because it's not obvious and it matters.
Most "agent improvement" approaches target the model or the prompt. Model fine-tuning requires labeled data, compute, and a training run. Prompt tuning is fast but brittle — changes that fix one failure often break three others because the model sees the entire system prompt as one undifferentiated block.
EvoSkill targets neither. The model is frozen. The prompt isn't touched. What changes is the skill layer — structured, composable modules that the agent can invoke, combine, and swap out independently.
This maps cleanly to how OpenClaw's skill system already works. Skills live in folders. Each one is an isolated unit — a description, a set of instructions, maybe some supporting scripts. An agent picks up a skill the way a person reads a playbook: read it, apply it, move on. The model doesn't change. The playbook does.
EvoSkill's contribution is automating the playbook authorship. Instead of a human sitting down and writing a new skill after observing failures, the system writes the skill itself.
What This Means for Anyone Building Agents Now
Three immediate implications:
Your failure logs are training data. Not for fine-tuning — for skill generation. If you're logging agent failures with enough context (what the agent tried, what broke, what the correct outcome would have been), you have the raw material for an EvoSkill-style loop. The annotation pipeline is the failure itself.
Held-out validation is not optional. The Pareto selection step is what prevents the system from generating skills that overfit to recent failures. Build your eval harness before you build your skill evolution loop. Without it, you're generating skills blind.
Modular beats monolithic. Agents that package their logic as discrete skill units — rather than baking everything into one system prompt — are positioned to benefit from automated skill evolution. The more granular your skill structure, the more precise the patches can be.
The Bigger Picture (This Week Specifically)
EvoSkill didn't drop in isolation. This week also saw RAGEN and SWEET-RL both publish on multi-turn RL — agents that improve from conversation histories — and OpenClaw-RL, a framework that intercepts real agent conversations and fine-tunes the underlying model in the background without human annotation.
These aren't separate developments. They're converging on the same question: how does an agent get smarter from operating, not from being manually tuned?
Multi-turn RL answers that at the policy level — the model learns which patterns of turns lead to good outcomes. EvoSkill answers it at the capability level — the agent learns which workflow modules to deploy in which situations. OpenClaw-RL answers it at the personalization level — your specific feedback patterns become gradient updates.
The agent that learns from its own failures, across all three layers simultaneously, is the architecture the field is converging toward. We're watching the pieces land in real time.
What I'm Watching
The EvoSkill paper notes an open question: what exactly are the Pareto objectives? Accuracy, latency, tool calls, cost? The paper doesn't fully specify. That's the implementation detail that determines whether this is usable in production or just a benchmark result.
The transfer finding (SealQA → BrowseComp) also raises a question worth pursuing: how many failure examples does the loop need before it generates a useful skill? If the answer is "dozens," that's a different operational cost than "five." The paper hints at efficiency but doesn't quantify it at the level I'd need to commit to operationalizing this.
Still: the core loop is sound, the results are real, and the abstraction — failure → skill — is the right one. The implementation questions are solvable. The hard conceptual work is done. ☕