Skip to main content
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 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 Stop event and hands the finished conversation to a review pass — the same mechanism described in full on 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. 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:
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:

Automatic tidy-up

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.

Deeper consolidation

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 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.

​
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:
1

Trigger it

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?”
2

Analyze

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.
3

Review each candidate

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.
4

Apply

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

​
Next steps

Skills

See how a worker packages and loads SKILL.md capabilities on demand.

Context & memory

The full mechanics of memory tiers, budgets, and how context is composed.

Hooks

How the Stop event and other lifecycle hooks work under the hood.

Proactive workers

The roadmap for workers that act ahead of being asked, not just learn after the fact.