A Whole-Task Skill Can Hurt the Next Task

An agent that writes a skill after each completed task looks like it is accumulating capability. The write can still be the wrong grain. A new preprint compares how skills are induced, not only whether they are stored, and reports that task-level skills tend to harm the same agent that subtask-level skills help.

The signal

Break It Down, Pass It On: Cross-Task Skill Transfer in LLM Agents compares two axes under a shared induction prompt: skill induction level (whole trajectory versus one subtask) and skill format (text note versus Python function). The panel uses three long-horizon benchmarks (AppWorld 417, OfficeBench 300, KramaBench 92), eleven models, and each skill condition against the same agent with memory off.

Averaged over those eleven models, task-level skills lower success relative to the no-memory task-level agent by 1.2 points for text and 4.1 for code (22.1 to 20.9 and 18.0). The same prompt at the subtask level raises success by 1.9 points for text and 0.5 for code (24.8 to 26.7 and 25.3). Text beats code at both levels. One named setting makes the grain visible: on AppWorld, Gemini-3.1-Pro falls from 68.1 to 58.0 / 52.3 with task-level text/code, and rises from 68.3 to 72.4 / 77.5 with subtask-level text/code. The authors further define a skill-utility score as specificity times abstractness, computed from skills and task descriptions with no new execution; tasks that retrieve higher-utility skills succeed more, and neither dimension alone predicts success. Those numbers belong to these three suites, these eleven models, and this fixed retrieve-and-store memory. They are not a ranking of WTK skills.

The evidence

The useful contribution is not a claim that skills cannot transfer. It is a grain-of-induction hypothesis. A whole-trajectory write stays tied to its source task and can enter the next context as misaligned procedure. A subtask write can name a shared step. Storing the procedure as code does not, on this evidence, make it more transferable than text.

For WTK, that challenges a comfortable habit: treating a completed package run as permission to promote the whole trajectory into a reusable skill. Our take is that a gate should name the induction span, the format, and a no-memory baseline in the same harness, then refuse to count a skill that only helps because it restates the source task. A portable package still has to qualify what a later execution form will retrieve, not what the last run happened to finish.

The boundary

This is a preprint on three official-evaluator benchmarks: multi-app tool use, office documents, and data-science pipelines. The authors state that computer-use, agentic coding, and web search were out of scope because they need Docker with root access they could not obtain at scale. The skill memory uses fixed induction, retrieval, and deduplication; evolving, agent-revised libraries are a separate study. Grading is final environment state only, with no step-level ground truth.

Individual models vary around the averages, including cases where adding skills does not help. The no-memory subtask agent already includes a planner and summarizer, so the skill contrast is within-agent, not a claim that decomposition is free.

It is therefore not a WTK Finding and does not promote the maturity of any WTK mechanism. Span-controlled skill induction and an execution-free utility check can complement deterministic conformance, grounded evidence, independent evaluation, and target-specific qualification. They cannot replace them.

The builder impact

Builders can make a skill gate legible by declaring, before a run, the induction span (task versus subtask), the stored format, the retrieval query, and the no-memory baseline in the same agent. Score the library against that baseline, not against a different agent.

Keep task-level writes from silently filling context on later tasks. If a utility score can be computed from descriptions alone, run it before the next live stream and retain the low-utility half rather than deleting it without a record.

A code skill that fails to load is a failed qualification of that write, not extra tooling. A text skill that restates one source task is not thereby reusable.

The WTK test

WTK could test this as a small held-out qualification experiment. Freeze a package, one target projection, one harness, and matched tool budgets. Induce skills at task grain and at subtask grain, each as text and as code, against a no-memory arm of the same agent. Transfer the library onto a disjoint later stream.

Score only the pairing that beats its own no-memory baseline, and retain every retrieved skill with its induction span.

The result would tell us whether this specific pairing earns its skill writes in one execution form. Until then, the paper is a useful prompt to inspect the grain of a skill, not evidence that WTK has solved skill transfer.