User-correction learning loop
Source workflow
Choose the layer you own
Separate three learning layers:
- model: trained weights;
- harness: loops, tools, prompts, and checks around the model;
- context: memory and skills stored outside the model.
In product workflows without a free, trustworthy automatic score, work in the harness or context rather than the model. Context is readable plain text that can be changed, deleted, shared, moved to another model, or rolled back.
Capture both halves of the correction
Capture the agent and user in the same interface. Keep the agent's proposed decision together with the user's corrective action. A screen recording sees the person's actions but not the agent; a chat correction sees the words but misses the person's other actions.
Use the interaction event stream to retain the tool calls, state changes, approvals, the agent's miss, and the person's fix in one trace. The source uses AG-UI and CopilotKit as the implementation example.
Distill the pair into procedural context
Have a background agent record what the person did and why. Write it as procedural memory-the way to handle a matching case-rather than changing model weights.
In the source's refund example, the agent refuses a $5,000 refund because of a $2,000 limit; a manager approves it for a loyal customer after a third late delivery. The paired state, decision, action, and reason form the lesson.
Review before the lesson lands
Keep the acting agent from editing its own core memory. Use a separate agent or maintenance process to propose the context change. Preserve the source's Hermes boundary: a proposed skill change passes tests and a person before it lands.
Read the lesson on the next matching run
Let the next agent read the approved procedural memory when a case looks the same. Keep the text readable and reversible so a reviewer can inspect, delete, or roll it back.
XSkills operational adaptations
Preflight access to the interaction-event stream, a writable procedural-memory store, a separate proposal process, tests or replay cases, and a human approval step. If any capability is unavailable, return the paired trace and proposed lesson without claiming it was installed, replayed, or monitored.
Record a narrow trigger, action, exceptions, evidence, and scope for the proposed lesson. Recheck stale lessons and counterexamples before reuse. These schema and lifecycle mechanics are XSkills additions, not Atai's stated procedure.
XSkills safety adaptations
Obtain an appropriate consent and access basis before capturing user interactions. Minimize unrelated messages, personal data, and secrets; define retention and deletion. Do not learn illegal, discriminatory, protected-trait, or policy-violating instructions. Require qualified human review for high-impact decisions and explicit approval before a context change is published to users or teams.
Return
Return the minimized paired trace, proposed procedural lesson, capability status, test or replay evidence when available, human approval state, and installed version or honest proposal-only fallback.
Source attribution
Independently compiled by XSkills from Atai Barkai's X Article explaining self-learning for agents. Barkai did not author or review this skill. Capability fallback, lesson schema, replay and staleness checks, consent, minimization, retention, prohibited-learning limits, high-impact review, and publish authority are XSkills adaptations. Attribution does not imply endorsement.