How an AI agent learns a new skill - and tidies up after itself

Memory says what is true. Skills say how work gets done.

Most conversations about AI memory stop at facts, and facts are worth keeping: your pricing, your escalation rules, who the difficult account is. That whole stack is the subject of How AI agents remember. It is genuinely useful, and it is not the same thing as competence.

Competence is procedural. The Monday report gets assembled in a particular order from particular sources with particular caveats. The refund enquiry gets checked against three things before anyone answers it. The quarterly supplier review pulls the same six numbers. An agent holding perfect facts and no procedure will do each of those slightly differently every time, and the variance is what your team notices.

So Olano agents keep a second kind of artifact next to memory: a skill. A skill is a small folder holding a SKILL.md file - a name, a one-line description, a trigger saying when to reach for it, and numbered steps. Some skills ship with the platform. Some come from a skill pack or a marketplace. Some you write. And some the agent writes for itself, out of work it has actually done.

That last category is where this article lives.

Where a learned skill comes from

Every turn an agent takes is appended to a transcript. A background pass reads those transcripts on a cycle - hourly at the most active cadence setting, every four hours at the most relaxed - and it reads only what it has not read before, tracked by byte offset per transcript. Nothing is re-analysed, and nothing is skipped because a file grew between runs.

From there the pass is deliberately hard to trigger:

• Fewer than four new turns and it does nothing. The offsets are committed anyway, so those turns do not pile up for a later run to over-interpret.
• It runs on the deep reasoning tier, or it does not run. There is no cheap fallback model. Each agent has a daily cap on deep runs - roughly six, twelve, or twenty-four depending on the cadence preset - and when the cap or the spending budget is exhausted the cycle is skipped and retried next time, with its offsets left uncommitted. Degraded analysis is worse than none: it produces confident, wrong procedures.
• It stands down while memory is being rewritten. The memory consolidation pass takes a lock; the distiller sees it and backs off rather than appending into a file that is being rewritten whole.

When it does run, facts land in memory first. Then, if skill learning is enabled, the same turns go to a second pass.

The scout reads the library before it reads the transcript

This is the part that keeps a learned library from turning into landfill. The skill scout is not handed a conversation and asked "what did you learn?". It is handed a conversation and an inventory of every skill the agent already has - including managed and third-party skills that live outside the agent's own workspace and that its file tools cannot see on their own - and asked what, if anything, is missing.

Each candidate it returns carries an action, and two of the three actions produce no new skill at all:

• skip - the capability is already covered. This is the most common outcome, and it is a success.
• update - an existing skill nearly covers it and should be sharpened. The candidate names the target.
• create - genuinely new. Only then does a skill get written.

A new skill then goes through a second validation pass that scans for near-duplicate names, skips if it finds one, and writes a properly structured SKILL.md with correct frontmatter. If that pass cannot complete, the system falls back to writing the candidate directly rather than losing it.

Improving a skill it did not write

An update is the interesting case, because the obvious implementation is the wrong one.

A skill you installed is not a single document. It may be a multi-file runbook: a SKILL.md plus scripts, reference tables, forms, templates. And it is owned upstream - when the pack it came from is refreshed, that folder is replaced wholesale. So an agent that "improves" such a skill by rewriting it in place has done two bad things at once: it has squeezed a runbook through a summary, and it has put its improvement directly in the path of the next update, which will silently delete it.

Olano forks instead. The first time an agent improves a skill it does not own:

• The entire folder is copied into the agent's learned library, byte for byte, with internal path references rewritten so the copy works from its new location.
• The copy reuses the original's exact name, so when the agent loads its skills the copy shadows the original rather than replacing it. The original file is never touched on disk.
• A provenance record is written alongside it: a per-file fingerprint of the source at fork time, a per-file fingerprint of the copy at fork time, and the section structure of the original SKILL.md file.
• A pristine snapshot of the starting state is kept separately, to serve as the merge base later.

Every subsequent improvement is applied to the copy, additively. Two properties fall out of this that a rewrite-in-place design cannot have: "did this improvement lose anything?" becomes a checkable question against a recorded baseline rather than a fuzzy diff between two unrelated documents, and "did the original change upstream?" stays answerable forever.

The preservation gate

The failure mode everyone worries about with self-modifying systems is gradual, quiet degradation: each pass slightly shorter, slightly blander, until the thing that used to work is a paragraph of platitudes. Promising it will not happen is not an engineering answer.

So a learned copy is checked against its own recorded starting state whenever skills are loaded. It fails if:

• a file that existed at fork time is now missing;
• a prose file has shrunk below half its original size (files under about half a kilobyte are exempt, since small files legitimately change size a lot);
• the SKILL.md file has lost more than a third of the original's section headings.

A copy that fails is quarantined - it stops shadowing, and the original serves again. The agent loses an improvement; it does not lose a working skill. And the gate deliberately applies only to machine-written copies: a learned skill a human wrote by hand is never quarantined, because a deliberate override is meant to be authoritative even when it is shorter.

When the original changes underneath it

Eventually the upstream skill is updated - a pack refresh, a marketplace update, an edit by your team. Now there are two lineages that both moved, and the provenance record makes a real three-way merge possible instead of a guess. Resolution is per file, and deterministic first: a model is consulted only where a deterministic answer does not exist.

Scroll the table sideways to see every column.

Afterwards the fingerprints and the base snapshot are refreshed to the merged state. That is what makes the loop converge: the same drift is never re-flagged, and the preservation gate keeps working against the new baseline rather than an ancient one. A copy currently failing the gate is skipped by the merge entirely - re-merging a degraded copy would launder it back into service.

One pass over the whole library

Validating skills one at a time is not the same as keeping a library coherent. So a separate pass, on its own schedule, reads every skill the agent has and treats the collection as the unit of work: merging duplicates and near-duplicates into one authoritative version with the best name, the clearest trigger and the union of the steps; deleting the folders it merged away; re-merging any copy whose original has drifted; and improving what survives.

The boundary is enforced, not advisory: originals and managed skills are read-only to this pass. It can only edit, merge and delete inside the learned library. Before it starts, every file it might touch is snapshotted, and when it finishes it reports what it changed with a single undo attached.

The same treatment for the workspace itself

An agent's own configuration is prose too, and prose written incrementally over months accumulates the same way: the same instruction phrased three ways in three places, a preference recorded in the wrong file, a note repeated in eleven consecutive daily logs, and occasionally two instructions that quietly contradict each other.

A workspace consolidation pass handles that. It reads the agent's identity, behaviour, instruction and long-term memory files plus its two most recent weeks of daily logs, and rewrites them in place to merge reworded duplicates, remove contradictions, group related content under clear headings, and move content into the file where it actually belongs. The daily logs get the most aggressive deduplication, because that is where repetition collects fastest.

The instruction it runs under is one sentence long and does the heavy lifting: preserve the agent's voice and every unique instruction; consolidate, never erase. As with the library pass, every target file is snapshotted first, and the result is reported with one-click undo.

Two policies, and the difference matters

Not everything in this loop is governed the same way, and the split is deliberate rather than convenient.

• Changing what an agent is told to do is proposal-only. The pass that reviews recent work and concludes an agent's instructions should be sharper does not edit those instructions. It writes grounded proposals into a review queue, and they wait - even with Fully Autonomous on, which otherwise lets new skills, memory and tidy-ups apply on their own. Nothing rewrites an agent's instructions because a background job thought it should, unless a deployment owner has explicitly lifted that hold for the agent.
• Lossless tidying applies, with a snapshot and an undo. Deduplicating memory, merging two identical learned skills, consolidating a repeated note - these do not change what the agent does, only how tidily it is written down. Requiring a human click for each one would train your team to approve without reading, which is the worst possible outcome for the queue that really matters. So they apply directly, after a snapshot, and each run reports what it changed with undo attached.

All of it is switchable. Each behaviour - distillation, skill learning, library upkeep, workspace consolidation, memory consolidation - is an independent toggle, settable for the whole deployment and overridable per agent in either direction, so "off everywhere except this one agent" is a real configuration. Above those sits a master switch, and a separate choice between running on a schedule and running only when someone asks. The cadence presets - relaxed, balanced, aggressive - move the schedules and the daily deep-reasoning caps together, and they sit underneath the same hard spending controls that govern everything else in the deployment.

What a full loop looks like

The compounding is slow and specific. The report your operations agent assembled by hand three weeks running exists as a written procedure by the fourth. The pack skill that was nearly right for your industry carries your correction, and still absorbs the vendor's next update instead of being flattened by it. The instruction file that had grown to four pages of overlapping guidance is two pages of non-overlapping guidance, and every sentence that was only in the version you deleted is still in the version you kept.

What this is not

No model weights are trained, fine-tuned, or adjusted. This entire loop operates one layer above the model, on artifacts written in plain language inside your own isolated deployment: skills, memory entries, instruction proposals. They are files. Your team can read them, edit them by hand, approve them, roll them back, and audit who changed what and when.

That is not a limitation we are working around. It is the reason the loop is something you can govern instead of something you have to trust - and it is the same reason the model underneath can be swapped without the agent losing what it has learned.