Expo Measured How Often Agents Load Its Skills. Before One Fix, 9% of Sessions Did.

TV
Thiago Victorino
6 min read
Expo Measured How Often Agents Load Its Skills. Before One Fix, 9% of Sessions Did.

In Expo’s baseline runs, 9% of agent sessions loaded any Expo skill at all. The page rounds that figure to 10% in two places, a heading and one body sentence, and states 9% in two others, including its takeaways box. After Expo added a single entrypoint skill called expo-overview, 55% of sessions loaded one or more downstream skills.

That is a governance finding. In the teams I work with, a skill file is often where a rule for the agent gets written down, and a rule in a file is treated as a control. Expo’s measurement shows how often a skill was absent from the run it was written for.

The Expo post states it in one sentence: “If a skill never enters the agent’s context, the quality of the instructions inside it does not matter for that run.”

What Expo Actually Measured

The setup, published on October 8, 2026 by Aditya Shukla of Georgian AI Lab and co-authors at Expo and Georgian AI Lab, was small and specific. Claude Code running sonnet-5-high. Ten greenfield mobile app PRDs. Three runs each, before and after expo-overview was added.

Two findings come out of it, and a third from a separate test.

The first is the load rate. Without the entrypoint, agents mostly worked without Expo’s skills. With it, a majority of sessions pulled in at least one downstream skill. The 55% counts any non-entrypoint skill, so it says the agent opened the door. It does not say the agent opened the right door.

That is what the second finding measures. Expo calls it Relevant Skill Recall. It “rose from 2% to 18%, but remained incomplete.” The entrypoint helped on a small base, and most relevant skills were still left on the shelf.

The third comes from a different setup. The 10-PRD runs used “a clean environment with only the Expo plugin installed.” The truncation test used “one test environment with 175 skills installed, including 24 from the Expo plugin … only the first 60 or so characters of each description were visible.” The agent chooses which skill to load from a catalog of descriptions. In the Codex version Expo inspected, the catalog gets a fixed budget, and “when the full skill catalog exceeded the allowance of 5.4k tokens, Codex started by shortening skill descriptions.” Whatever a skill’s description says after the cut, the agent never reads before deciding.

Expo frames the whole result as “an initial signal from a handful of datapoints.” Treat it as a starting measurement. It is enough to change what you look at and too small to serve as a benchmark.

The Control You Wrote Versus the Control That Ran

In the reviews I see, skill files are audited like policy documents. Someone reads the text, checks that it says the right thing, approves the pull request. That review answers one question: if the agent reads this, will it behave correctly?

It leaves a prior question unasked. Did the agent read it?

A security rule in a skill file that loads in 9% of sessions is absent from most of them. Reviewing its wording more carefully leaves that number where it was. The control exists in the repository and is missing at runtime, and a review of the text alone does not surface the difference.

We have covered the adjacent territory before. Passive context in AGENTS.md is one answer to the discovery problem, and what hundreds of skills taught Anthropic covers what goes inside a skill once it loads. Expo’s contribution is narrower and more useful for an operator: it treats discovery as a quantity that can be measured, changed, and measured again.

The First 60 Characters Are the Interface

The truncation finding deserves its own attention because it changes how skill descriptions should be written.

If only the first 60 or so characters of a description are visible in a crowded catalog, then those characters, with the skill’s name, are the whole interface between the skill and the agent’s decision to load it. A description that opens with background, a product name, or a polite summary spends its visible budget on words that do not help the agent match the skill to the task.

Expo observed the limit in one test environment. Other catalogs, other harnesses, and other skill counts may cut at a different point. In harnesses that give the catalog a fixed budget, like the Codex version Expo inspected, the more skills installed, the less of each description survives into the agent’s view.

Two practical consequences follow. Put the trigger first: the task or situation that should cause the load, in the words a request would use. And count your installed skills, because in such a harness every plugin you add can shorten the visible description of skills you already have. A team that installs a large plugin can shorten what the agent sees of its own internal skills without touching them, and Expo has not yet measured what that does to discovery.

This also bears on skills written in many languages. If the visible window is short, my expectation is that the language of those first characters affects whether the match happens.

Instruction Text Rots Too

Loading is one half of the problem. The other half is what gets loaded.

In a post published on October 9, 2026, Cockroach Labs describes a July audit of the skill files behind its agent workflow: 25 skill files totaling a little over 100,000 words. About 23,000 of those words, roughly 23%, were flagged as removable.

My reading of both numbers is that instruction text tends to grow by accretion. An incident adds a paragraph, an edge case adds a rule, and removal can feel like weakening a control. Cockroach’s audit shows what the removable share looks like when someone goes looking for it. Long files cost tokens on every load, and long descriptions risk the cut in a crowded catalog.

A removable sentence costs more than the tokens it consumes. It dilutes the instructions that matter once a skill is loaded, and in the description field it can push the useful words past the cut.

Load Rate as a Governance Metric

The governance move here is to treat load rate as a first-class metric, reported alongside the skill itself.

For every skill that encodes a rule you depend on, you should be able to answer how often it entered the agent’s context in the sessions where it applied. If your harness keeps traces of which skills each session loaded, the work is aggregating them and setting an expectation. If it does not, that instrumentation comes first.

Once load rate is a number, three practices become possible.

Gate skill changes in CI. A change to a skill’s name or description is a change to whether it gets loaded. Run a fixed set of representative tasks before and after, and fail the change if load rate or relevant recall drops. Expo’s method, ten PRDs and three runs each, produced an initial signal with a modest harness.

Test under a realistic catalog. Expo’s 9% baseline came from a clean environment with only its own plugin installed. A crowded catalog adds truncation on top of that, so test with the full set of plugins and internal skills your teams actually install.

Prune on a schedule. Cockroach’s audit flagged about 23% of its instruction text as removable. Make that review periodic. Shorter files cost fewer tokens per load and leave less to dilute the rules that matter, and shorter descriptions put the trigger inside the visible window.

Do This Now

Pick the three skills in your environment that carry rules you would be uncomfortable seeing violated: a security constraint, a data-handling rule, a release step.

For each one, pull the last batch of agent traces where that skill should have applied and count how many sessions loaded it. If you cannot produce that count, your first task is instrumenting it. If the count is low, rewrite the opening words of the description so they name the trigger, then measure again with your full catalog installed.

Then add the measurement to the pull request template for skill changes, so every edit to a name or description arrives with its load rate attached.


This analysis synthesizes Your skills need an evaluation mechanism (Expo and Georgian AI Lab, October 2026) and Five months treating bugs like patients and coding agents like a medical team (Cockroach Labs, October 2026).

Victorino Group helps engineering teams measure whether their agent rules actually load, and gate skill changes before they reach production. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation