Self-Evolving Skills
in Multi-Agent Systems

"Skills are fragile, tools are expensive, and agents forget everything"

The conventional approach to agent capabilities was brute-force: stuff every tool schema, every instruction, every convention into the system prompt. This worked when agents had 5 tools and ran for 3 turns. It collapses entirely in 2026, where production systems connect 50-200 tools, run for hours, and coordinate across multiple agents. Three compounding problems make the old approach untenable:

"An open standard with no standards body"

The single most structurally important event of Q1 2026: Anthropic, OpenAI, and Google independently converged on the same skill definition format with no joint announcement and no coordinating standards body. The agentskills.io open standard, adopted by 30+ agent tools, defines a SKILL.md file with YAML frontmatter and a Markdown body — readable by humans, parseable by machines, version-controllable in git.[4]

The distinction between skills and MCP is important and frequently confused. MCP is an agent-to-tool connection protocol — one agent, many external tools. Agent Skills are an agent-to-agent interoperability layer — many agents, shared capability registry. They're complementary layers in the same stack, not competing standards.

# SKILL.md specimen with evolution metadata
---
name: api-conventions
description: >
  REST API design conventions for this project.
  Activate when creating or modifying API endpoints.
  NOT for GraphQL. NOT for internal RPC calls.       # ← negative examples reduce misfires 20%
allowed-tools: Bash(npm run test:api *) Read Grep
metadata:
  freyja:
    type: build
    triggers: [api endpoint, REST, route handler]
    confidence: verified                              # ← lifecycle: unvalidated → experimental → verified → deprecated
    retrieval_count: 23
    success_signals: 19                               # ← passive evolutionary selection pressure
    failure_signals: 2
    cold_tools: [custom_api_validator]                 # ← 3rd-tier progressive disclosure
---

# API Conventions
[Step-by-step instructions follow...]

From Birth to Retirement

Every skill has a biography. It is born from one of four distinct pathways, grows through a maturity ladder gated by statistical confidence, draws sustenance from three layers of memory, and — eventually — dies. The lifecycle is not a conveyor belt; it's a loop. Dead skills seed the traces from which new skills crystallise. Understanding this loop is the difference between a skill library that compounds and one that rots.

① Birth — four pathways to existence

Skills don't appear from nowhere. Every skill in every library we surveyed entered through one of exactly four doors:

Trace received
  │
  ├─ One-off pattern? ──────────────────── → discard
  │
  ├─ Recurring pattern detected?
  │    │
  │    ├─ Complex / stateful? ──────────── → Subagent pattern  (AutoRefine)
  │    │
  │    └─ Procedural / deterministic? ──── → Skill candidate
  │         │
  │         ├─ PPO-Gate: better than       → reject  (ProcMEM trust-region
  │         │  existing baseline?               verification)
  │         │
  │         └─ Similar skill exists?
  │              ├─ yes ────────────────── → MERGE  (version bump)
  │              └─ no ─────────────────── → NEW    (mint v0.1.0)

② Growth — the maturity ladder

A newly minted skill is unproven. It enters a maturity ladder — each rung gated by statistical evidence, not time. Young skills stay plastic; mature skills freeze like late layers in a neural network. PSN formalises this with a maturity-aware update probability:

P(update | σ) = 1 − sigmoid(V(σ) / threshold) + ε_min

Where V(σ) is the cumulative validation score. As a skill proves itself, its update probability decays toward ε_min — a small floor that keeps even verified skills open to rare, high-signal corrections. The intuition: don't fix what isn't broken, but never fully lock the door.

③ The three memory layers

Skills don't exist in a vacuum — they are the apex of a three-layer memory architecture. PlugMem (Microsoft Research / UIUC) formalises what every successful system implicitly builds: episodic memory is the raw substrate, semantic memory is the distilled index, and procedural memory is the reusable skill. Each layer compresses the one below it.

④ Death — three retirement signals

A skill library that only grows eventually drowns the agent in stale, contradictory, or redundant procedures. AutoRefine showed the cost: without maintenance, a repository grows 4.5× and utilisation degrades 8.9×. Retirement is not failure — it's hygiene. Three distinct signals trigger it:

What every major lab is shipping

The Feb–April 2026 period saw skill management go from academic concept to production infrastructure at every major lab simultaneously. Not theoretical — shipped systems, real deployments, concrete production numbers.

50+ papers in 90 days, organized by theme

The Feb–April 2026 window produced an extraordinary density of skill-related research. We tracked 50+ papers across 8 parallel investigation threads. These are the ones that matter.

Skills aren't standalone — they form networks

Every system we surveyed eventually converges on the same realisation: an individual skill is a node, not a product. Value emerges from composition — how skills chain, branch, loop, and occasionally contradict each other. The hard problem isn't writing skills; it's making them compose reliably and resolving the conflicts that inevitably arise when they do.

PSN's Programmatic Skill Networks

Programmatic Skill Networks (PSN) is the deepest treatment of composition we found.[PSN] Skills are symbolic programs — not prompt snippets — with typed preconditions and postconditions forming a directed acyclic graph. Composition happens through explicit invocation links:

The planner uses backward chaining to select skills: select_skill(goal) = argmax{σ: postcond(σ)⊇goal} V(σ) — find the skill whose postconditions cover the goal, weighted by the skill's value estimate V.

2-Phase Credit Assignment — PSN's crown jewel

When a composed skill chain fails, which skill is at fault? PSN's answer is a two-phase process that's structurally analogous to backpropagation in neural networks — but operates on symbolic programs instead of tensors.

The maturity gate is critical: P(update|σ) = 1 − sigmoid(V/threshold) + ε. A skill with a high value estimate V — meaning it reliably succeeds — is unlikely to be updated. Immature skills with low V stay plastic. The ε ensures even mature skills can be corrected if they're genuinely broken.

Knowledge Activation's Continuation Graphs

Where PSN uses top-down planning, Knowledge Activation takes a decentralised approach. Each skill has three typed continuation edges — success, failure, escalation — and the agent traverses locally with no central orchestrator. Topology validation at commit-time catches cycles, uniqueness violations, and dangling references before deployment. It's less powerful than PSN's planner but dramatically simpler to reason about at scale.

How Conflicts Are Resolved

When composed skills disagree — or when multiple skills claim authority over the same goal — the system needs a resolution hierarchy. Across the literature, we see the same four-layer pattern emerge independently in multiple frameworks:

Symbolic-MoE[SMoE] operates at Layer 3: it builds skill profiles from validation performance, selects top-k experts per query instance, and uses a task-specific aggregator LLM to synthesise conflicting outputs in a single round. PSN adds its own constraint at Layer 1: a rolling buffer of 5 recent proposals enforces consistency — contradictory edits to the same skill within the window are rejected before they enter the system.

Dependency Management — the agent.lock proposal

As skill libraries grow, the problem shifts from "how do I compose skills?" to "how do I know which version of which skill I'm composing with?" The npm parallel is no longer a metaphor — it's a direct analogy.

[skills.web_search]
name = "web_search"
version = "1.3.2"
sha256 = "a7f3c9e2d1b4..."
publisher = "acme-corp"
review_status = "audited"

[skills.code_review]
name = "code_review"
version = "0.8.1"
sha256 = "e5d2a1f8b3c6..."
publisher = "internal"
review_status = "pending"

The agent.lock proposal[GL] pins skills by name + version + SHA-256 hash + publisher + review status, enforceable via CI. pixi-skills ships skills as conda packages with run_constraints (e.g., polars>=1.38,<2.0) and pins exact versions in pixi.lock. EvoSkill uses git branches as skill versions — each evolution creates a new branch, with the Pareto frontier tracked via git tags.

"What the best systems have in common"

Across 50+ papers, every major lab release, and every production deployment we surveyed, ten patterns keep appearing. These aren't speculative — they're empirically validated by multiple independent teams.

"Improved skill" is just a hypothesis until it's measured

The evolution loop described in Section 4 has a gaping hole: how do you know a mutated skill is actually better? Without rigorous evaluation, evolution is just random walk. The fitness function IS the evaluation — and getting it right is the difference between skills that converge toward excellence and skills that drift into noise. OpenHands' recent work on skill evaluation methodology crystallises what production teams are learning the hard way.[48]

The core insight is deceptively simple: a skill can hurt. SkillsBench found that some skills produce negative deltas — the added guidance makes the model less effective. And as models improve, skills that were once essential become unnecessary or actively counterproductive. Boris Cherny on the Claude Code team put it directly: "Delete your claude.md and then, if the model gets off track, add back a little bit at a time. What you're going to find is with every model you have to add less and less."

Three ingredients of a real skill evaluation

OpenHands' evaluating-skills-tutorial formalises the minimum viable evaluation. Every evaluation requires exactly three things — if any one is missing, you're not really measuring:

Three archetypes of skill impact

OpenHands tested three tasks across five models (Claude Sonnet 4.5, Gemini 3 Pro, Gemini 3 Flash, Kimi K2, MiniMax M2.5) and discovered that skill impact falls into three distinct archetypes — each requiring a different response from the evolution loop:

Wiring evaluation into the evolution loop

This is where evaluation becomes the engine of evolution rather than a post-hoc check. The verifier is the fitness function. The trace is the diagnostic signal. Together, they close the loop:

The critical connection: each evaluation outcome maps to a specific evolution action. This is what transforms random mutation into directed improvement. Without this mapping, the evolution loop in Section 4 is just genetic drift. With it, skills converge:

Practical: how to wire this today

OpenHands' evaluating-skills-tutorial provides the concrete implementation pattern. The key design decisions that make it work as an evolution engine:

# The minimum viable evaluation loop
# (adapted from OpenHands evaluating-skills-tutorial)

tasks/
  my-task/
    task_prompt.txt          # bounded goal + output contract
    expected_report.json     # ground truth
    input/                   # local artifacts (no network)
    output/                  # where agent writes result
    skills/
      baseline/SKILL.md      # current production skill
      improved/SKILL.md      # candidate mutation
    verify.py                # deterministic pass/fail

# 1. Run no-skill baseline
uv run python scripts/run_eval.py --condition no-skill

# 2. Run with skill
uv run python scripts/run_eval.py --condition improved-skill

# 3. Compare: pass/fail first, then runtime + events
uv run python scripts/compare_runs.py

# 4. If improved-skill wins → promote (↑ confidence, ↑ Q-value)
# 5. If improved-skill loses → inspect trace → mutate → re-run
# 6. If no difference → candidate for deprecation

Beyond pass/fail: what 2026 research actually proposes

The OpenHands framework is the minimum viable evaluation. But the Feb–April 2026 research wave produced significantly more sophisticated approaches. Six techniques go beyond binary pass/fail in ways that directly improve evolution loop convergence:

The CI/CD integration pattern

Every production team surveyed — Galileo, LangChain, Mindra, Braintrust, Anthropic — independently converged on the same four-tier evaluation trigger hierarchy.[54] This is not optional infrastructure — it's how skill evaluation becomes continuous rather than episodic:

Galileo's progressive deployment gates make this concrete: 70% task success to pass dev → 85% for staging → 95% for production. Canary at 5% of traffic, monitor 24-48h, expand if stable, auto-rollback on degradation. Mindra adds a four-layer testing pyramid: tool unit tests (every PR, <2 min) → agent behaviour tests (<10 min) → pipeline integration tests (on merge, <30 min) → end-to-end regression (nightly, <2 hrs).

"Skills can fail, decay, and be weaponized — and all three are happening right now"

The skill ecosystem's growth story has a dark mirror. 40K+ skills in 20 days also means 40K+ potential failure vectors in 20 days. This section examines the full failure surface: how skills fail (taxonomy), when they actively hurt (negative transfer), how they rot (decay), and how they're being weaponized (supply-chain attacks).

Part 1: How Skills Fail — The Taxonomy

Part 2: The Security Crisis — Deep Dive

Part 3: Defense Architecture

5-Layer defense model — defense in depth

Defense in depth: each layer catches what the layer above misses. Trust tiers (T0–T4) govern which layers a skill must pass.

"Every token is either consumed or invested — the gap determines your ROI"

Skill evolution isn't free. Every mutation cycle burns tokens, every reflection step costs latency, every failed evolution attempt is sunk cost. The question isn't whether to evolve skills — it's which skills to evolve, when to stop iterating, and how fast the investment pays back. Recent work gives us concrete numbers.

The Agentic ROI Framework

The Tsinghua/Oxford Knowledge Compounding study[KC] introduces a formal ROI metric for skill investment across domains:

ROI_i = (ΔQ_i × ΔT_i) / C_i

  ΔQ_i = quality improvement from skill reuse in domain i
  ΔT_i = time savings (fewer steps, fewer tokens)
  C_i   = total cost of skill creation + evolution

The domain ranking is striking — and counterintuitive:

Concrete Token Savings

Four independent production systems quantify the returns:

The Capital Goods Reframing

The most provocative claim from the Knowledge Compounding paper: LLM tokens spent on skill evolution should be reclassified from consumables to capital goods — analogous to SFAS 86 treatment of software development costs. Four properties justify this:

The compounding dynamics follow a learning curve:

H(i+1) = H(i) + α × (1 - H(i)) × p(i)

  H(i) = knowledge harvest at step i
  α     = 0.18 (empirically fitted learning rate)
  p(i)  = probability of finding new knowledge at step i

The Marketplace at Scale

The skill marketplace ecosystem provides the clearest signal that skill evolution is not theoretical — it's a live economy with supply curves, demand curves, and market failures.[ASE]

The Cost of Not Evolving

The asymmetry is stark: the cost of skill evolution is finite and bounded; the cost of stasis compounds indefinitely.

The Breakeven Calculation

Skill evolution costs are front-loaded. EvoSkills achieves ~71% pass rate in 3+ iterations, where each iteration equals one LLM call. Assume 3 evolution calls at ~1,000 tokens each = 3,000 tokens invested. If each subsequent invocation saves 59% of an average 800-token call (~470 tokens saved), the payback schedule is fast:

The economics are unambiguous. Skill evolution is not a research curiosity — it's an arbitrage. The only question is which skills sit in the high-ROI quadrant (narrow domain, high reuse frequency, stable topic distribution) and which ones don't warrant the investment. Coding, infrastructure automation, and structured data workflows are the obvious first movers. Personal assistance, creative writing, and open-ended research are last — not because they're unimportant, but because their diffuse topic distributions can't accumulate reusable skill capital fast enough to justify the evolution cost.

What we'd build if we started from scratch

Every finding in this survey points in the same direction. Synthesising across all 50+ papers, all lab reports, and all production deployments, here is an opinionated architecture for skill management in multi-agent systems. Not a compromise — a synthesis.

The architecture has six layers. Each addresses a specific finding from the research. Here's the rationale: