> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cogniagent.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Self-improvement & learning
> How a worker gets better with every task — an automatic review pass, skill upkeep, growing memory, and the roadmap "Learn" action.
A worker shouldn't need to be taught the same lesson twice. Cowork closes that loop automatically: after a task finishes, a background pass looks at what happened and drafts anything worth keeping, while a separate tidy-up pass keeps a worker's skill library from turning into clutter — all as proposals you approve, never as silent changes.
## The vision: workers that get sharper with every task
The goal is a colleague that accumulates real capability the way a person would — noticing a technique that worked, writing down a fact you keep having to repeat, and periodically tidying up its own notes — without you doing anything beyond a quick review.
None of this retrains or fine-tunes the underlying model. Every bit of growth lives in ordinary files a worker already has: [skills](/cowork/workers/skills) it can load on demand, and memory notes it keeps about you and your work. That's deliberate — it means everything a worker has "learned" is a file you can open, edit, or delete, and nothing it picks up is a permanent, invisible change to how the model itself behaves.
Growth happens in exactly two places: **skills** capture *how* to do a class of task, and **memory notes** capture *facts* about you and your work. The sections below cover how each one grows and who's driving each change.
## The improvement reviewer: a look back at the end of every task
When a task finishes, a hook fires on the [agentic loop's](/cowork/loop/agentic-loop) `Stop` event and hands the finished conversation to a review pass — the same mechanism described in full on [Hooks](/cowork/loop/hooks). The reviewer reads what actually happened in the task: the tools that were called, any errors the worker fixed along the way, and any corrections you made — and decides whether anything from it is worth keeping for next time.
It doesn't run on every task, and it doesn't force an update just to have one:
* It only kicks in when a task did enough to be worth learning from — for example, the worker made a meaningful number of tool calls, recovered from an error, or you corrected its course.
* It runs at most once per finished task, and only a handful of times a day per worker, so it never turns into background noise.
* "Nothing worth saving" is a completely normal outcome. The reviewer proposes at most a few ideas per task, often none at all.
When it does find something, it drafts up to a few candidates — a brand-new skill, a patch to an existing one, or a memory note — and lands them as **proposals**, never as applied changes.
```mermaid theme={null}
flowchart LR
A["Task settles"] --> B["Stop hook fires"]
B --> C["Improvement reviewer
reads the transcript"]
C -->|"nothing worth keeping"| D["No proposal — that's fine"]
C -->|"found something"| E["Drafts a proposal"]
E --> F["Improvements tab"]
F -->|"Approve"| G["New skill, patch, or memory note"]
F -->|"Tweak"| G
F -->|"Dismiss"| H["Discarded — never re-proposed"]
```
Every proposal shows up on the worker's **Improvements tab**, alongside the reason it was suggested and a link back to the task it came from, so you can always see the evidence behind it. From there you choose one of three verbs:
| Verb | What it does |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------- |
| **Approve** | Applies the draft exactly as written. A new skill is ready starting the worker's *next* task. |
| **Tweak** | Opens the draft for you to edit first — useful when the idea is right but the wording isn't — then applies your edited version. |
| **Dismiss** | Discards it. A dismissed idea is never proposed again. |
The reviewer only ever proposes changes to skills or memory the worker itself created. Anything you wrote by hand is never touched — at most it gets flagged, never rewritten, by any automatic pass.
## Keeping the skill library tidy: the curator
Left unchecked, a worker that keeps writing skills after every task would end up with a cluttered, overlapping library instead of a genuinely useful one. A separate weekly pass per worker exists to prevent that — think of it as the librarian to the reviewer's researcher.
It runs in two layers:
Always on, and free — it's just bookkeeping, not a model call. A worker-authored skill that goes **45 days** without being used is flagged stale; after **120 days** unused, it's **archived**, not deleted, and can be restored any time. Using it again resets the clock.
Off by default, opt-in per worker. Looks for skills that overlap enough to be one well-organized skill instead of several narrow ones, and proposes merging or rewriting them — landing on the same Improvements tab as the reviewer's suggestions, for you to approve or dismiss.
As with the reviewer, the curator only ever acts on skills the worker generated itself. A skill you wrote by hand can be flagged for your attention, but it's never archived or rewritten automatically. See [Skills](/cowork/workers/skills) for how a worker actually loads and uses these files day to day.
## How a worker's memory grows
Memory is the lighter-weight half of learning: quick, declarative facts rather than a full procedure — "replies should stay concise," "this client's meetings default to PST" — instead of a step-by-step how-to. A note the worker jots down mid-task lands in its memory right away, visible for you to read, edit, or remove at any time.
Memory notes suggested *after* the fact work differently: when the improvement reviewer looks back at a finished task, a memory note it drafts goes through the exact same Approve / Tweak / Dismiss review as a skill would — background suggestions always get a look before they become part of what a worker "knows."
This page covers memory as a *growth* channel — where notes come from and who approves them. For the full picture (memory's budget, what happens when it fills up, and how it fits alongside a task's working context), see [Context & memory](/cowork/loop/context-and-memory).
## The "Learn" action (roadmap)
The "Learn" action described below is **on the product roadmap** and not part of Cowork today. Everything above this section — the improvement reviewer and the curator — already ships.
The planned experience gives you a direct, on-demand way to turn a task into a lasting capability, alongside the automatic review pass:
Either you ask explicitly — optionally telling the worker exactly what to extract, like "just capture the deployment-rollback procedure" — or the worker proactively offers mid- or post-task, along the lines of "want me to turn this into a script?"
The worker reads back over the task (or the part you pointed it at) and identifies the reusable pattern — or patterns. A single task that actually contains more than one distinct capability gets split into separate candidates rather than packed into one catch-all skill.
You see every candidate individually, edit or reject any of them, and nothing is written until you say so — the same review discipline the improvement reviewer already uses.
Accepted candidates are written as skills or memory notes, ready the next time the worker picks up related work.
"Learn" is designed to reuse the same propose-then-review pipeline the improvement reviewer already established, rather than a separate engine — it's an on-demand trigger for the same loop, not a new one. A related idea — promoting a skill a worker learned on its own into a shared, workspace-wide skill — is still an open question, since two workers (or a worker and the workspace) could end up owning conflicting skills with the same name.
## What ships now vs. what's on the roadmap
| Ships now | On the roadmap |
| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Improvement reviewer drafts skill and memory proposals after a task settles | On-demand "Learn" action, plus proactive "want me to turn this into a script?" offers |
| Improvements tab: Approve / Tweak / Dismiss review queue with evidence links | Promoting a worker-authored skill into a shared, workspace-wide skill |
| Automatic skill tidy-up — stale after 45 idle days, archived (and restorable) after 120 | A fully automatic "trusted mode" that applies changes without a review step |
| Opt-in deeper consolidation pass that merges overlapping skills | — |
| Memory notes — written live during a task, or proposed by the reviewer for your review | — |
## Next steps
See how a worker packages and loads SKILL.md capabilities on demand.
The full mechanics of memory tiers, budgets, and how context is composed.
How the Stop event and other lifecycle hooks work under the hood.
The roadmap for workers that act ahead of being asked, not just learn after the fact.