How is this different from RAG?

RAG retrieves text the model uses as context for an answer. The text is read; the answer is generated; the text is not part of the agent's "skills" in any structural sense. A learning agent retrieves procedures — small structured units that look more like saved tool sequences, prompt templates, or task plans — and executes them. The output of RAG is an answer; the output of the learning loop is an executable capability. The two compose (a learning agent can use RAG inside its skills), but they are different layers.

What can go wrong with a learning agent?

Three failure modes worth designing for. First, bad patterns get extracted: the agent had a sequence that looked successful but was actually a hack or used a side effect, and the skill that gets written perpetuates the bad pattern. Second, skill drift: a skill works for a while, then the codebase or the environment changes, and the skill silently produces worse results without anyone noticing. Third, the evaluation step itself is an LLM call and has its own error rate, so the agent's self-assessment of what worked can be wrong. Mitigations include human review of new skills before they go live, eviction policies based on usage and recency, and observability over skill invocations.

The Learning Agent Pattern, Explained

Q: Why not just fine-tune the model on the task history?

Fine-tuning bakes patterns into the model's weights. That works but is heavy: you need a dataset, a fine-tune run, an evaluation, a deployment. The learning loop pattern keeps the model frozen and changes what the agent loads as its toolset. It is much cheaper to iterate, observable (skills are inspectable files), reversible (delete a bad skill), and per-operator (different operators end up with different skills). Fine-tuning is the right answer for stable widespread patterns; the learning loop is the right answer for evolving operator-specific ones.

The most interesting design idea in the recent wave of self-hosted agent runtimes is not "fire-and-forget" or "messaging-first" — both of those were already obvious by 2024. The interesting idea is the learning loop: an agent that gets more capable the longer it runs, by extracting reusable procedures from its own task history and adding them to its skill set.

Hermes Agent shipped the most visible implementation of this pattern. Other runtimes are starting to copy it. The pattern is general enough that it is worth understanding on its own, separately from any one project.

This article works through what the pattern is, why it is different from related ideas you may already know, and what fails when you try to ship it.

The pattern in one paragraph

A learning agent runs tasks normally. Periodically — after some number of tasks completes, or on a time interval — it evaluates the recent task set: what worked, what failed, which sequences of tool calls or prompts appeared multiple times. From that evaluation it extracts the patterns that look reusable and serializes them as new skill files. Those skills get loaded into the agent's active toolset based on relevance to incoming tasks. Used skills get refined; unused or failing skills get evicted. The net effect is an agent whose tool set is shaped by your actual workflows rather than by whatever someone shipped in a library.

This sounds simple in the paragraph. It is not exotic technically, either — none of the individual steps requires a research breakthrough. The interesting part is that the whole loop forms a feedback cycle that did not exist in earlier agent designs, and the runtime engineering to make it work in production is non-trivial.

Why this is different from RAG

The first question worth answering: is this just RAG with extra steps? Not really.

RAG retrieves text — passages, documents, chunks — that the model reads as context for its answer. The retrieval is over a corpus; the model uses what it finds; the corpus is not changed by the interaction. A learning agent retrieves something different: procedures, not text. A procedure is a small structured unit that says "given a task of this shape, do these steps in this order," or "use this prompt template with this tool call configuration." When invoked, it changes how the agent acts, not just what it knows.

The two layers compose cleanly. A learning agent can use RAG inside its skills (a skill might be "search docs, then propose code based on what you find"). But the learning loop is not RAG — the output is an executable capability, not a passage of text.

Why this is different from fine-tuning

Second related idea: why not just fine-tune the model on the task history? Take the successful tasks, build a dataset, run a LoRA, deploy a model that has learned the patterns implicitly.

Fine-tuning works and is the right answer for some cases. It is also heavy:

You need a dataset of reasonable size.
The fine-tune run takes infrastructure, time, and money.
The result is opaque: the patterns are baked into weights, not inspectable.
Iteration is slow — bad fine-tunes are expensive to roll back.
The result is shared across all operators, not per-operator.

The learning loop keeps the model frozen and changes what the agent loads as tools instead. The skills are inspectable files. Bad skills can be deleted. Different operators end up with different skill sets shaped by their work. The iteration loop is minutes, not days. The cost is a small evaluation call per cycle, not a fine-tune.

The trade-off: fine-tuning produces deeper integration of the patterns into the model's behavior; the learning loop is shallower but operates on a faster cycle. For evolving, operator-specific patterns the loop is the right shape. For stable patterns that should hold across everyone, fine-tuning is.

Why this is different from chat memory

Third related idea: "chat memory" — the long-running personalization features in chat products (ChatGPT memory, Claude's organizational context, similar). Those are per-user stores of facts and preferences the model reads on each turn.

Chat memory is factual: it stores what the model knows about the user. The learning loop is procedural: it stores what the agent knows how to do. Both compose with each other — a learning agent can also have chat-style memory of facts about the operator — but they fill different roles.

The distinction matters because a lot of "agent memory" discourse conflates the two. "The agent should remember things about me" is factual memory. "The agent should remember how to do things for me" is procedural memory, and that is what the learning loop addresses.

What actually goes into a skill file

A reasonable mental model for what gets serialized when the agent extracts a pattern:

A name and description of the procedure ("triage a GitHub issue and add labels," "run the React test suite and summarize failures").
A trigger condition — when this skill is relevant. Often a small classifier prompt or a keyword set.
A sequence of steps — tool calls, sub-prompts, file reads or writes, with dependencies between them.
Parameters — what varies between invocations (the issue URL, the repo path, the failing test pattern).
Examples — one or two cases of the skill being used successfully.
Provenance — where this skill came from (extracted from which tasks, refined how many times).

Exactly how this is serialized varies by project — Python files, JSON, YAML, or some custom format. The shape of the information is similar across implementations.

Failure modes worth designing for

The learning loop is not free. The realistic failure shapes:

Bad patterns get extracted. The agent ran a sequence that looked successful (the test passed, the output was produced) but was actually a hack — it disabled a check, used a side effect, papered over a real problem. The skill that gets written perpetuates the bad pattern. Future tasks that load it produce more of the same kind of work.

The mitigation: human review of new skills before they go live. Hermes Agent's loop is documented as autonomous, but a production deployment that cares about quality typically adds a review step for new skills, especially in safety-sensitive or correctness-sensitive domains.

Skill drift. A skill worked when the codebase or the environment was a certain way. The environment changes. The skill still loads, still runs, but now produces worse results. No one notices for a while because the skill name still matches the task.

The mitigation: track success rate per skill over time, evict skills whose success rate drops, and re-extract from current task history rather than letting old skills accumulate forever.

Evaluation noise. The evaluation step that decides "did this task succeed" is itself an LLM call. It has an error rate. The agent's self-assessment can be wrong, especially on subtle failures the model itself can be fooled by ("the code compiled" is not the same as "the code is correct"). Bad evaluation leads to bad extraction.

The mitigation: external verifiers where possible (tests must pass, schemas must validate, builds must succeed), and treat the LLM evaluation as a coarse signal rather than the ground truth.

Operational complexity. The loop is one more moving piece. Logs to monitor. Skill files to back up. Evaluation costs to budget for. A learning agent is more complex to operate than a static-skill agent. Teams adopting it should plan for the extra surface.

When the pattern is worth it

The learning loop pays off most clearly when:

The workflow is repetitive enough that patterns will emerge over time.
Each operator's patterns are different enough that a shared library would not cover them.
The agent runs long enough (weeks or months) to accumulate task history.
Bad skill extractions can be caught and recovered from.

It pays off less when:

The workload is one-shot or highly varied, so no patterns repeat.
The patterns that exist are already well-served by a community skill library.
The operational complexity of running the loop exceeds the benefit of the patterns it extracts.

For a single developer running occasional tasks, the static-skill approach (OpenClaw, Claude Code) is probably the right shape. For a team running an agent continuously against the same kind of work for months, the learning loop changes what the agent eventually becomes, and that compounding is where the pattern's value actually shows up.

The Learning Agent Pattern, Explained

Article summary