10 min read

Skill Learning Loops

How agents improve between tasks: distilling completed work into reusable skill files, retrieving them later, and securing the write path.

TL;DR
  • A skill learning loop runs between tasks, not inside them: when a task completes, the agent distills the procedure that worked into a structured skill file, stores it, and retrieves it when a similar task appears.
  • Skills store procedures, not facts. 'How we deploy the staging environment' is a skill; 'the staging URL' is memory. Conflating the two produces stores that are hard to retrieve from and impossible to audit.
  • The description is the retrieval API. Skill metadata stays cheap and always discoverable; the full body loads into context only when a task actually matches, a pattern known as progressive disclosure.
  • Treat the skill store like a code repository: every skill has provenance, a version history, and a review gate—especially when the author is the agent itself.
  • Agent-written skills are a new attack surface. A poisoned skill is a prompt injection that fires on every future matching task, so scan writes for injection patterns, exfiltration instructions, and invisible Unicode before they reach the store.
  • Measure skills like features: track how often each one is retrieved, whether it changes task outcomes, and retire skills that stop earning their place.
  • An open skill format makes learned procedures portable across agent environments instead of locking them inside one framework's memory.
Quick view
Best for
Agents that face recurring task families
Core primitive
Complete → distill → store → retrieve
Do first
Distill one recurring task into a skill file
Primary risk
Unreviewed writes poisoning future runs

What & why

A skill learning loop is the cycle that lets an agent get better at its job over time. After a task completes, the agent (or its operator) distills the non-obvious parts of the solution into a structured, reusable skill file. The store indexes it, and when a similar task appears later, the agent retrieves the skill and starts from a working procedure instead of rediscovering it turn by turn.

This is the visible shift in 2026 agent systems: agents that accumulate procedures, not just facts. Anthropic's Agent Skills format packages instructions, scripts, and resources into folders an agent loads on demand, and the same format is being standardized so skills move portably between agent environments [1] [2].

The idea has research roots. Voyager showed in 2023 that an agent maintaining an ever-growing library of verified, reusable skills dramatically outperforms one that starts fresh each episode [4], and the cognitive-architecture literature has long separated procedural memory—how to do things—from episodic and semantic memory [5].

The economics are the practical argument. An agent that spends thirty turns discovering a deployment quirk has paid for that knowledge once; without a learning loop it pays again on every future run. Distillation amortizes exploration cost across every future task in the same family.

Mental model

Keep two loops distinct in your head. The agent loop is intra-task: plan, act, observe, repeat, terminate. The skill learning loop is inter-task: complete, distill, store, retrieve. The first is an event loop; the second is closer to a CI/CD feedback cycle. One finishes; the other is what makes the agent different tomorrow than it was today.

The closest human analogy is a team runbook culture. An incident gets resolved (task), someone writes the postmortem and updates the runbook (distillation), the runbook lives in a searchable place (store), and the next on-call engineer follows it instead of improvising (retrieval). Teams that skip the write-up step stay permanently junior; so do agents.

Skills are code-shaped, and that is their advantage over opaque learned weights or free-form memory. A skill file can be read, diffed, reviewed, versioned, tested, and deleted. When an agent behaves differently this week, you can inspect exactly which stored procedure changed—something fine-tuning can never offer.

Retrieval works by progressive disclosure. Every skill's name and one-line description sit in a cheap, always-searchable index; the full body—instructions, examples, scripts—loads into context only when the current task matches. This keeps a store of hundreds of skills from costing hundreds of skills' worth of tokens [1] [3].

The learning loop, one pass at a time

  1. 01
    Detect a distillable outcome

    The trigger is a verified task success whose procedure was non-obvious: the agent needed real exploration, hit and recovered from failures, or applied undocumented constraints.

    Routine tasks the agent already handles in a few clean turns produce nothing worth storing. Distilling everything creates a store where retrieval noise buries the skills that matter.

  2. 02
    Distill the procedure, not the transcript

    Extract the reusable shape: preconditions, ordered steps, decision points, verification checks, and known failure modes with their fixes. Strip run-specific details—paths, ticket numbers, one-off values—or parameterize them explicitly.

    A skill that replays one historical run is a log entry. A skill that transfers to the next similar-but-not-identical task is the asset.

  3. 03
    Gate the write

    Before anything reaches the store, deduplicate against existing skills—updating a near-match beats accumulating variants—and run the security checks covered below.

    Decide the review policy by blast radius: a formatting convention can be auto-committed; a skill that touches credentials, production systems, or spend should wait for human approval.

  4. 04
    Store with an index-ready description

    Write the description for the retrieval moment: what task shapes it applies to and what signals should trigger it, in the vocabulary future tasks will actually use.

    Record provenance in metadata—which run produced it, whether a human reviewed it, and a version—so every skill can be traced and rolled back like a commit.

  5. 05
    Retrieve and apply on the next matching task

    Match the incoming task against skill descriptions and load only the matched bodies into context. The agent should treat a retrieved skill as a strong prior, not an unbreakable script—the environment may have drifted since it was written.

    When a skill's steps fail against current reality, that observation is itself input to the next distillation pass.

  6. 06
    Measure, update, or retire

    Track per skill: how often it is retrieved, whether matched tasks succeed more often and in fewer turns than unmatched ones, and when it was last useful.

    Skills rot as tools, APIs, and models change. Update the ones that earn their retrievals; delete the ones that stopped matching or started misleading.

Anatomy of a portable skill

  • A folder with a required SKILL.md file, plus optional scripts, templates, and reference documents the instructions can point to [2].
  • Frontmatter with a unique name and a description that states what the skill does and when to use it—the only part guaranteed to be in context before a match.
  • A body with the procedure: preconditions, steps, decision points, and verification checks, written for a capable reader rather than as brittle keystroke-level automation.
  • Concrete examples of inputs and expected outcomes, which do more for reliable application than abstract instructions.
  • Version and provenance metadata: who or what authored it, which run it came from, and whether it passed review.
  • A body kept small enough to load without crowding out the task itself; large reference material belongs in linked resource files loaded on demand [1].

Secure the write path

  1. 01
    Treat memory poisoning as a first-class attack surface

    In a normal prompt injection, malicious text influences one run. A poisoned skill persists: it fires on every future task that matches its description, long after the malicious input that planted it is gone.

    The attack path is indirect. An agent that browses the web or reads user-supplied documents can be manipulated into 'learning' a procedure an attacker authored. The write path, not just the context window, is where injection defense now lives [7].

  2. 02
    Scan every write before it reaches the store

    Check candidate skills for instruction-override patterns, requests to exfiltrate credentials or contact unexpected endpoints, and invisible or homoglyph Unicode that hides text from human reviewers. Self-improving agent frameworks such as Hermes run exactly this scan on every memory write.

    Scanning is a filter, not a guarantee—pair it with review gates and least privilege rather than treating it as the whole defense.

  3. 03
    Apply least privilege to skill execution

    A skill that bundles executable scripts is code from a semi-trusted author. Run it under the same sandbox, permission, and approval rules as any other agent-initiated action—retrieval from the store must not imply execution rights.

    Keep the skill store itself permissioned: the agent writes through the gated path, not directly to the directory its future selves will trust.

  4. 04
    Audit third-party skills like dependencies

    Portable skill formats create a sharing ecosystem, and with it a supply chain. An installed skill is closer to a browser extension than a text file: it shapes future agent behavior inside your permissions.

    Review before installing, pin versions, and record where each skill came from—the same hygiene you apply to packages [3].

Common failure modes

  • Storing facts, preferences, or session context as skills instead of keeping procedural and factual memory separate.
  • Distilling every completed task, so retrieval drowns in near-duplicate, low-value entries.
  • Writing vague descriptions that never match future tasks—an unretrieved skill might as well not exist.
  • Loading every skill body into every context instead of using progressive disclosure.
  • Letting the agent write directly to its own store with no dedupe, review, or injection scanning.
  • Baking run-specific paths, IDs, or credentials into skill bodies.
  • Treating retrieved skills as infallible scripts after the environment has drifted.
  • Never measuring retrieval or outcomes, so dead and misleading skills accumulate unnoticed.
  • Installing shared skills from unknown authors without the scrutiny given to any other dependency.

Final checklist

The agent faces recurring task families where a stored procedure would transfer.
Skills hold procedures; facts and preferences live in a separate memory layer.
Distillation is selective and strips or parameterizes run-specific detail.
Every skill has a retrieval-oriented description, a version, and provenance metadata.
Writes are deduplicated against existing skills before landing.
Writes are scanned for injection patterns, exfiltration instructions, and hidden Unicode.
High-blast-radius skills require human review before entering the store.
Skill metadata is always searchable; bodies load only on match.
Bundled scripts execute under the same sandbox and approval rules as other agent actions.
Retrieval frequency and matched-task outcomes are measured per skill.
Stale or misleading skills are updated or deleted on a regular pass.
Third-party skills are reviewed, pinned, and attributed like dependencies.

Read next

  • Agent LoopsThe intra-task cycle this loop wraps around: turns, tools, state, and stopping conditions.
  • Agent MemoryWhere skills sit in the full memory hierarchy, alongside session state and persistent facts.
  • Evaluation for LLM FeaturesMeasure whether retrieved skills actually change task outcomes for the better.

References

More recipes

Subscribe to all Software Cookbook updates

If this recipe was useful, subscribe for the next ones. New pages arrive with the same concise, technical format.

New cookbook updates, sent when there's something worth reading.