A single agent skill can contain a planning rule, a warning from experience, tool instructions and executable code. Cognitive Differentiation in Skill Evolution, or CDSE, argues that these parts should be updated and checked according to the work they do.
The research concerns external, reusable skill knowledge. Its goal is to improve how agents retain and apply lessons from completed trajectories, rather than to claim that every successful run should modify the underlying model.
Four roles within one skill
CDSE organises a unified skill into Meta, Experience, Tool and Script components. Meta concerns planning, monitoring, verification and stopping. Experience holds context-dependent heuristics and recovery strategies. Tool covers operational guidance, while Script captures reusable executable procedures with validation expectations.
The components remain coordinated. The point is not to split every skill into unrelated files, but to avoid applying the same update process to a broad planning rule and a specific piece of executable code.
The authors analyse 500 widely used skill packages and report that 96.8% contain at least two functional roles. That finding motivates the design; it does not imply that every package needs the same four-part implementation.
Learn from contrasting outcomes
The framework extracts evidence-grounded directions for change from successful and failed trajectories. It then consolidates useful updates by functional role, applies component-specific validation and adapts which components are invoked during later tasks.
Across six benchmarks, three agent models and two execution harnesses, the authors report the highest scores among compared methods in all 36 settings. Average improvements are 7.6 percentage points over the base agent and 2.6 points over the strongest competing method in each setting.
Those are aggregate results within the paper's experiments. They do not establish that adding four headings to an existing skill will produce the same gain, or that a rule learned on one workflow transfers safely to every other task.
Inspect the lesson and its validation together
Our reading is that the useful contribution is a more precise unit of maintenance. A lesson about when to stop should be evaluated differently from a script that sorts data. Keeping those roles explicit gives a reviewer a clearer question to ask about the proposed change.
A practical reproduction could follow one failed trajectory through the resulting update, identify which component changed and test both the original failure and a nearby task that previously worked. That checks whether a lesson repairs a recurring problem without becoming an overbroad rule. The reported average gains are encouraging, but the individual update and its evidence remain worth inspecting.
Comments