The future of skills is learning from work

A correction should improve the next relevant task. Too often, it disappears with the conversation.

Teaching an agent your document format, customer terminology, and exceptions should be work you can reuse.

My view is that successful enterprise AI will need to turn these interactions into durable improvements. When someone demonstrates useful work or corrects an error, the system should help capture the lesson, propose a reusable procedure, and establish whether it works. As tools, policies, and models change, it should keep that procedure current.

“Do the work once” is an appealing ambition. The practical promise should be more precise: people should not have to teach the same valid lesson repeatedly. One demonstration can suggest a procedure; reliability requires evidence across situations.

From saved prompts to maintained procedures#

An agent skill packages instructions for a recurring task, sometimes with code, references, and templates. It gives a model a working method without necessarily changing its weights. If the format is unfamiliar, start with what an agent skill actually is.

Consider a hypothetical delivery team. An employee prepares a customer handover by reading the signed agreement, checking account notes, separating commitments from assumptions, and drafting a document for review.

Drafting the handover is one useful task. I want the system to go further: notice that the employee keeps correcting the same mistake, where the agent treats something discussed in a sales call as a confirmed commitment.

The useful lesson includes the decision rule, its evidence, and the exceptions. The procedure should distinguish an agreement from a discussion, retain unresolved conflicts, and know when a reviewer must decide.

Today, a person can write that into a skill. I want the system to propose the change from observed corrections, construct evaluation cases, and show the owner whether the revision helps.

AutoSkill describes extracting and evolving reusable skills from interactions. MUSE-Autoskill explicitly combines creation, memory, management, evaluation, and refinement. Their shared interest is knowledge that survives a single task. These papers support parts of the direction, but neither establishes that an arbitrary office workflow can be learned reliably from one demonstration.

WikiSkill: keep the lessons behind the instructions#

WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution separates execution traces, a persistent wiki of patterns and prior interventions, and active skills. A maintainer consolidates experience; a proposer changes one skill; validation accepts improvements and rolls back rejected changes. The wiki retains the history, including failed interventions.

Across five benchmarks and five models, the authors report stronger average results than their skill-evolution baselines. For Qwen-3.5-9B, the five-task average rises from 29.9 without skills to 47.4 with WikiSkill: 17.5 percentage points. Individual settings can regress; this is benchmark evidence, not a measured enterprise productivity gain.

Several details qualify the result. Active skills are injected directly into the prompt, so the experiment does not test discovering the right skill in a large library. The execution agent is denied wiki access during evolution; granting access in a comparison hurts final skill quality. Retaining knowledge does not imply every agent should read everything.

The authors also identify missing wiki pruning and evaluation of tasks lasting hundreds of actions or multiple hours. Strict validation improvement can reject neutral changes that might enable later gains. These limits matter when translating the design into an evolving company workflow.

OpenWiki: memory needs a reason to remain trusted#

LangChain's OpenWiki Brains announcement addresses the repeated-context problem from another direction. Its personal mode builds a maintained Markdown wiki from connected information sources; its code mode documents repositories. The aim is useful context that an agent can consult without someone pasting the same background into every conversation.

The OpenWiki repository describes linked wikis, agent integrations, and evidence-backed repository updates. This is a maintained knowledge system, not proof that a wiki automatically becomes an effective procedural skill library. Connecting those layers still requires selection and evaluation.

Colin Francis's self-correcting memory article explains an important mechanism: record a claim with versioned supporting evidence. Changed evidence marks a claim as stale until it is checked. Stale means uncertain, rather than necessarily false. OpenWiki can refresh the evidence or correct the claim and page together.

In an evaluation replaying successive code changes, LangChain's results table reports reducing stale claims from 3.5% to 0.5%. Here the evaluator's stale category means a formerly correct claim no longer holds against the updated code; this differs from the runtime's flag to recheck changed evidence. That is a vendor-run test of factual wiki maintenance, not an evaluation of enterprise workflow reliability. The mechanism described is grounded in code evidence; it should not be assumed to validate every kind of personal or organizational knowledge equally well.

For an enterprise, I would extend this idea to the assumptions behind procedures. If a skill depends on a policy section or an API behavior, a change to that dependency should trigger review and relevant tests. Being able to say “this procedure needs rechecking” is more useful than presenting old instructions with fresh confidence.

Capture a task, its outcome, and the correction#

There is a real precedent for the uncomfortable version of learning from work. On April 21, 2026, Reuters reported that Meta was introducing software on US employees' computers to collect mouse movements, clicks, keystrokes, and occasional screen snapshots from selected work applications. Meta said the purpose was model training, with protections for sensitive content and no use for performance assessments. Reuters, republished by Investing.com

On June 22, 2026, Business Insider reported that Meta paused the program after employee information became accessible internally. Meta confirmed it was investigating and said it had no indication of improper employee access at that time. Business Insider's report

That example concerns collecting computer-use training data. It does not demonstrate validated organizational skills. I would pursue task-specific capture with the worker's participation: explicitly start and stop capture for a named workflow, show what is recorded, allow inspection and deletion of captured material, and let the person review the proposed lesson. Define access, retention, and any training reuse before capture begins.

For the handover, useful evidence could include selected source documents, the draft, the employee's correction, and the accepted result. The person can explain why the change mattered. Where available, structured tool events and document diffs give more precise evidence than inferring intent from screen coordinates.

A recording shows actions. It may omit the reason someone chose them, the exception they recognized, or the information they knew before recording began. Saving more activity does not by itself close those gaps.

How I would release a learned procedure#

Here is the lifecycle I would want an enterprise system to support. It is a proposed design, not a capability demonstrated end to end by the sources above.

First, capture a bounded example with its outcome and relevant evidence. Then propose a general rule and its limits. In our handover, the candidate might require agreement evidence before presenting a customer commitment as confirmed.

The domain owner then checks the proposed rule and its evaluation cases. Test both whether the agent selects the skill for the right tasks and whether the procedure helps when it is used. The point is to catch a bad generalization before it becomes the default for everyone.

The procedure owner approves the scope and expected behavior; release requires the agreed quality and process checks to pass. Release a version tied to the skill content, tool definitions, model configuration, relevant source versions, and evaluation results. Roll it out within a defined scope. Keep the previous version available while remembering that rollback cannot undo external actions already taken.

Finally, monitor accepted work, corrections, and changing dependencies. Propose repairs when evidence warrants them. Merge overlapping procedures and retire obsolete ones. Otherwise a skill library can become another place where plausible but contradictory instructions accumulate.

A correction needs an explanation#

Suppose the employee deletes a promised delivery date from the handover. The system can observe the edit. It cannot safely infer the general lesson from that edit alone.

The date could be unagreed, superseded, or simply in the wrong section. The reviewer could also be mistaken.

If the reviewer explains that the date came only from a sales note, the system can propose requiring governing-agreement evidence for confirmed dates. It can add an unsigned-note case that should remain unresolved and a signed-amendment case that should pass. The delivery owner checks the rule and cases before the change is evaluated for release.

A useful feedback interface would show the proposed explanation and ask for a small correction when the cause is unclear. Repeated patterns can help prioritize investigation; they should not silently turn an uncertain interpretation into company policy.

Some problems will need a skill edit. Others need better retrieval, a repaired integration, current reference data, or a deterministic check. Evaluating the whole workflow helps locate the intervention.

A study of process-level evaluation reinforces the need to inspect more than the final output. Across 240 trials of two enterprise skills, many runs with correct numerical answers still had evaluator-detected process deviations. The study is narrow and does not test actual longitudinal API evolution.

I would keep the evaluation method separate from the skill that is being improved. Give the agent a definition of done explains the cases, state checks, and independent acceptance criteria in more detail.

Memory should reduce explanation without spreading assumptions#

The distinction that matters here is who a lesson belongs to. A skill can store procedural memory, but that does not make every remembered preference or fact a shared procedure.

An individual preference for short summaries belongs with that person. A customer commitment belongs with its authoritative source and access restrictions. A team-wide handover rule needs an owner with authority to define that rule.

Making a personal lesson available to a team should be an explicit decision. One employee's workaround might be valuable evidence, but it may depend on their permissions or an unusual customer arrangement. Automatically sharing it can spread the wrong lesson or reveal information to people who could not access the original.

I want the agent to be able to say: “I used your preferred format, the delivery team's procedure, and the current agreement.” I should be able to correct each layer separately.

That makes forgetting part of the design too. A revoked preference should stop returning. An outdated policy should stop influencing new work. Source removal or access revocation must also reach derived memories and cached copies where relevant. A stale label is helpful, but it does not enforce those boundaries by itself.

Count corrections that stop recurring#

The SkillFlow benchmark tests discovery and evolution across sequential tasks. Its results vary substantially by model, and frequent skill use does not necessarily produce useful gains. A separate analysis of 138,133 public skill files finds widespread packaging defects and problems with skill selection under its taxonomy. That measures detected file defects, not a corresponding rate of real-world task failures. Both studies caution against counting saved skills as progress.

I would test this on one recurring workflow. Track which correction categories stop recurring, the reviewer effort per accepted task, and the cost of capturing, testing, and maintaining the procedures. Check samples of accepted work for mistakes the reviewer missed. Compare against the same system without the learning loop.

The economics matter. Saving a few repeated instructions is little use if maintaining the lesson takes longer. But when a correction improves the next hundred relevant tasks, the value is quite different. That is the behavior I want enterprise AI to make routine.

Research checked on October 15, 2026. The handover is hypothetical; the lifecycle is my proposed design.