Your skills work.
Not for the reason you think.
Researchers stopped asking whether agent skill libraries help and started asking why. The mechanism that most builders assume is responsible for the gain accounts for about one in twenty-two helpful uses. The mechanism most builders overlook accounts for roughly two in three. And the retriever that connects libraries to agents falls apart long before content quality can matter.
First surfaced in Tandemly Briefing — 2026-08-14.
Skill libraries help.
Nobody knows how.
Researchers have spent years showing that giving agents access to a library of reusable skills improves task success. That finding is solid. What's missing is the mechanism behind it, and the mechanism determines what you should actually build.
The standard pitch for agent skill libraries goes something like this: store useful knowledge or procedures in a searchable index, retrieve the relevant ones when a task appears, let the agent apply what it finds. Studies confirm this works. Task success goes up when skills are available.
But "does it help?" and "how does it help?" are different questions, and they have very different implications for what to invest in. If skills work by supplying missing facts, you should pour effort into the quality of those facts. If they work by stabilizing action sequences, you should pour effort into the structure of those actions. If they fail because the retriever breaks before the content can even reach the agent, then content quality is largely irrelevant until the retrieval problem is solved.
The field has generated a lot of evidence for the first question and almost none for the second. That gap is what this paper goes after. The researchers describe their goal plainly: not to add another proof that skill libraries are helpful, but to dissect how they are helpful, and to map where that mechanism stops working.
When a skill library raises an agent's task success rate, what is actually happening inside the execution trajectory? And when library-equipped agents still fail, is the failure in the content of the skills, the retrieval of the skills, or something else entirely?
8,135 trials.
238 labeled trajectories.
The researchers built a controlled study that held different properties of the skill system fixed while varying others. That structure is what separates the retrieval bottleneck from the content bottleneck, two failure modes that aggregate task-success numbers routinely conflate.
The study normalized 8,135 trial records across conditions that isolated four variables in turn: how skills are represented, how outcomes are annotated, how retrieval difficulty is varied, and how robust results are across different agent harnesses. Varying one while fixing the others is the move that lets you attribute a result to a cause rather than a correlation.
On top of the controlled experiments, the team ran paired trajectory analysis on a sample of cases where skills were helpful and cases where they weren't. Two researchers coded 238 open-labeled instances and resolved disagreements through discussion. The result is a taxonomy of three categories and twelve skill-use modes that describes what is happening inside a trajectory when a skill makes a difference.
One condition in particular is worth noting: the researchers included a setting where the exactly correct skill was provided directly to the agent, bypassing retrieval entirely. This is the control that lets you check whether finding the right skill is sufficient for downstream success. The answer turns out to matter quite a bit for how you interpret offline retrieval benchmarks.
The three categories distinguish skills that change what the agent knows (knowledge injection), skills that change what the agent does and in what order (procedural anchoring), and cases where the skill was retrieved or invoked but didn't materially affect the trajectory at all. Twelve finer-grained modes sit inside those three categories and describe specific patterns of how each type of influence operates.
The mechanism is procedure.
The bottleneck is retrieval.
Two findings emerged from the taxonomy and the controlled conditions. Both reshape the standard mental model for how to build and maintain a skill library.
Procedural anchoring accounts for 65.7% of the cases where a skill made a meaningful difference. Explicit knowledge injection accounts for 4.5%. The mechanism practitioners tend to assume is responsible for skill library gains is roughly one-fourteenth as common as the mechanism they tend to overlook.
What procedural anchoring looks like in practice: the agent has the relevant information somewhere in its context. What it lacks is a stable sequence of actions to apply that information. The skill provides the sequence. The agent follows it. The task succeeds where it otherwise would have drifted into improvisation or gotten stuck in a loop.
Actual-use precision collapses from 29.6% to 3.3% as the skill pool grows from 5 to 100 skills. This is not a gradual decline. It is a sharp one. An agent with five skills finds and uses the right one roughly three times in ten. With a hundred skills, it does so roughly three times in a hundred.
The researchers describe this as a failure mode that is separate from the content of the skills. The skills themselves may be excellent. The retriever that locates them degrades under scale. This means teams that are continuously expanding their skill libraries may be unwittingly making their retrieval problem worse while their content problem gets better.
The study included a condition where the ground-truth skill was provided directly to the agent without retrieval. Task success in that condition did not reach ceiling. This establishes that exact invocation of the right skill is neither sufficient nor necessary for downstream success.
That result directly undermines the usefulness of offline retrieval benchmarks. Most such benchmarks measure whether a system retrieves the ground-truth skill. They assume that hitting ground truth on retrieval is the right target. The data here suggests otherwise: the agent can use the wrong skill and succeed, and can receive the right skill and fail. Retrieval accuracy on a held-out benchmark is a poor proxy for the thing you actually care about.
The taxonomy comes from 238 manually coded instances. Hand-coding at that scale is standard for qualitative trajectory analysis, and two coders resolved disagreements through discussion, but the categories reflect the researchers' interpretive choices. The retrieval-precision collapse is measured within the experimental setup the team designed. Whether it generalizes to other skill formats, retrieval architectures, and task domains would require additional study.
Write procedures,
not encyclopedias.
The mechanism finding and the retrieval finding together point in the same direction: the investment strategy that the field has tacitly adopted for skill libraries may be pointing at the wrong targets.
Where to go
from here.
The paper is a diagnostic, not a design prescription. Here is where to start applying what it found.