Skill library evolution

TL;DR

• Skill library evolution lets an agent save successful multi-step solutions as named, retrievable "skills" so future tasks start from proven templates instead of reasoning from scratch.
• Each skill is a structured record: name, description, preconditions, action sequence, and postconditions. The description enables semantic retrieval matching.
• On new tasks, the agent searches its skill library first. A matching skill cuts token usage by 40-70% and reduces error rates because the solution has already been validated.
• Skills are versioned. When a skill fails on a new variant, the agent adapts it and saves a new version, creating an evolutionary improvement loop.
• Complex skills compose from simpler sub-skills, mirroring function composition in programming. The Voyager Minecraft agent demonstrated this by building novel behaviors from primitive skill combinations.
• Limitation: skill libraries require maintenance. Outdated skills that no longer work become "skill rot," and false-positive retrieval matches can mislead the agent into applying the wrong template.

---

The Problem It Solves

Your coding agent gets a task: "Set up a FastAPI project with JWT authentication, rate limiting, and PostgreSQL." It takes 12 minutes. It calls the LLM 47 times. It burns through 180K tokens. The output works. Your team is happy.

Two days later, a different developer asks it to "Set up a FastAPI project with OAuth2, rate limiting, and MySQL." The agent starts from zero. Another 12 minutes, another 47 LLM calls, another 180K tokens. It rediscovers the same FastAPI project structure, the same rate limiting middleware setup, the same dependency patterns. The only differences are the auth mechanism and the database driver.

This is the fundamental waste: agents have no procedural memory. Every session starts with a blank slate. The agent has a powerful reasoning engine (the LLM) and a rich context window, but no way to carry forward what it learned from solving previous tasks. It's like a senior engineer who gets amnesia every morning. Brilliant problem-solver, zero accumulated expertise.

I've watched teams burn through $2,000/month in API costs because their agents re-derive the same boilerplate patterns hundreds of times. The LLM is doing expensive reasoning work to rediscover solutions that were already validated last week. That's not an AI problem, it's a caching problem.

Human developers avoid this through experience, code templates, and shared libraries. Skill library evolution gives agents the same capability: a growing repository of proven solutions that compound over time.

What Is It?

Skill library evolution is a pattern where an agent extracts successful multi-step solutions into named, searchable "skills" and stores them in a persistent library. On future tasks, the agent searches the library before reasoning from scratch. If a relevant skill exists, the agent starts from that template and adapts it, rather than re-deriving the entire solution.

Think of it as a chef's recipe book. A chef who invents a new dish doesn't memorize every step and hope to recall it next time. They write it down: ingredients, quantities, technique, plating. Next time someone orders something similar, they pull the recipe and adjust (swap the protein, change the sauce). Over months, the recipe book grows into a comprehensive repertoire. A new chef joining the kitchen doesn't need to re-invent every dish. They inherit the book.

The skill library is the agent's recipe book. Each "recipe" is a structured skill with enough detail to reproduce and adapt the solution.

The key insight: the skill library is the locus of improvement, not the model. You don't retrain the LLM to make the agent better at recurring tasks. You build up the library. This means improvement is persistent, inspectable, and version-controlled.

How It Works

The skill data structure

A skill is more than saved code. It's a structured record that captures everything needed to reproduce the solution in a different context. The five fields are intentional: each one serves a distinct purpose in retrieval, validation, and execution.

The description field deserves extra attention. It's not a label; it's the retrieval key. When a new task arrives, the agent embeds the task description and performs similarity search against skill descriptions. A vague description like "FastAPI setup" matches too many things. A precise description like "Initialize a FastAPI project with JWT-based authentication including login, token refresh, and protected route decorators" retrieves the right skill reliably.

I've found that spending 30 extra tokens on a detailed skill description saves thousands of tokens downstream by improving retrieval accuracy.

Skill retrieval and matching

When a new task arrives, the agent doesn't go straight to the LLM for reasoning. The first step is always a library search. This is cheap (a vector similarity query) and fast (sub-100ms).

The threshold tuning matters. Set the similarity threshold too low and the agent applies irrelevant skills (skill mismatch). Set it too high and the agent ignores useful partial matches, falling back to expensive from-scratch reasoning more than necessary. In practice, 0.8-0.85 works well as the "strong match" threshold for code-related tasks.

Skill evolution through versioning

Skills aren't static. When a skill was built for Python 3.10 and the project now uses 3.12, some steps might fail. When a library API changes between versions, the action sequence breaks. The evolution mechanism handles this: when a skill fails, the agent diagnoses the failure, adapts the skill, and saves a new version.