OpenClaw self-learning

Self-learning is how an OpenClaw agent turns corrections and successful work into reusable skills. Skills are the durable unit, procedures that future sessions can discover and follow, and Skill Workshop owns the ones the agent learned. The default mode is auto; propose stages drafts for review instead, and off disables autonomous learning. Here are the two learning paths, the conditions that gate the delayed review, what qualifies and what does not, the safety argument for the default, the cost and privacy note, and the commands that let you review or revert.

Two learning paths

• Immediate repair: when the foreground agent discovers that a skill it used is wrong or incomplete, it reads the current live skill and drafts a targeted patch through Workshop in the same turn; a usage receipt prevents repairing skills the run did not use, and the patch still goes through proposal storage, hash binding, the security scanner and rollback capture.
• The repair changes the live skill for new sessions, not the snapshot already loaded into the running one, and the mode decides the outcome: off disables it, propose leaves it pending, auto scans and applies immediately.
• Experience review: after substantial work, one detached background review looks for a reusable recovery technique or a stable procedure that would remove at least two future model or tool round trips; interrupted deep turns qualify too, since the wrong path and its correction are exactly the evidence worth keeping, while turns that ended in a provider or prompt error never schedule a review.
• The review runs under a private detached session identity, its messages never enter the foreground transcript, it retains the source session’s sandbox policy, and the foreground answer never waits for it.

Every learning decision comes from a model reviewing real evidence, not a template or pattern-matching path.

When a review runs

Six conditions must all hold: the foreground turn completed or was interrupted without a provider or prompt error; it used at least ten model iterations; it was an eligible foreground conversation, not cron, heartbeat, memory, overflow, hook, subagent or review work; the runtime reported the resolved provider, model and the actual availability of the Workshop tool; the system has been quiet for thirty seconds; and no agent or reply run is still active. A later completion in the same session restarts the quiet period. In auto mode the reviewer uses ordinary directory, file, patch and shell tools under the source session’s permissions, rooted at the Workshop directory, and shares the weekly collection’s maintenance rules: audit before editing, give a procedure one home, preserve distinct tasks, verify the result, and replace or strengthen a rule rather than append a copy. In propose mode only the Workshop tool executes and one create, patch, update or revision is staged. Each review gets one attempt, and a failure is recorded rather than retried.

Candidates, modes, safety

• Good candidates: a reliable recovery after repeated failures, a durable user correction or standing instruction embedded as a procedure step, a non-obvious ordering constraint, a stable multi-step workflow that needed repeated discovery, a reusable preflight. The reviewer abstains for routine work, personal facts and simple preferences, transient failures, generic advice without evidence, unsupported negative claims, and secrets.
• The mode is one config key set from the CLI: off creates no captures, propose creates or revises pending proposals and applies nothing, auto maintains Workshop skills with normal file tools. Changing it does not alter existing proposals or applied skills, and manual learning, the learn command and explicit Workshop requests work in all three.
• Why auto is safe to default, in the docs’ words: file tools stay in the Workshop directory, the run preserves the source session’s permission mode, tool restrictions and shell approval policy, foreground work never awaits the review, and the agent reads complete files and checks its changes. Direct maintenance creates no proposals, scanner run or rollback snapshot, so backups are the recovery path, and the residual risk of an incorrect edit is why propose exists.

OpenClaw skills explained explains what a skill is before one is learned, and The best OpenClaw skills the hand-authored ones worth installing.

Cost, privacy, and revert

A review adds one model run on the configured provider after a substantial turn, not after every message, and can make several requests while it inspects, edits and verifies; it reuses the foreground provider, model and auth identity with fallbacks disabled, and it can send conversation content including tool inputs and results to that provider, so the docs say to choose a provider and mode that match the workspace’s privacy requirements. The Workshop CLI lists and inspects every pending, applied, rejected, quarantined or stale capture, rejects one with a reason, or quarantines it for security review; the learn command asks for an explicit proposal from the current conversation or named sources and never auto-applies; and the Workshop page offers learning from past conversations as a normal agent session that follows the current mode. The other runtime facts: the embedded runner and the Codex harness report what the review needs, other CLI-backed runtimes fail closed until they do, and the config caps pending proposals at fifty and a proposal body at forty thousand bytes. OpenClaw usage tracking is where the extra run shows up, and OpenClaw sandboxing explained the policy the review inherits.

On Diali

On Diali the Workshop directory lives inside the assistant’s persistent workspace, so a learned procedure survives a release, and the catalog skills you installed sit beside the ones the assistant wrote itself. Hosted OpenClaw on Diali is the assistant.

• Repair in the turn, review after it.
• Ten iterations, thirty quiet seconds, one attempt.
• Auto by default; propose when every capture needs a human.