The 2,500-skill company

On Tuesday an Uber engineering exec posted three numbers: 99% of Uber's engineers use AI tools, more than 70% of pull requests are attributed to agents, and their engineers have built 2,500+ agent skills across the software development lifecycle.

The 2,500 got quoted everywhere as a milestone. The detail worth your attention is further down the post, and almost nobody mentioned it.

Uber's mechanism for spreading this beyond engineering is a program called Agentic Pods: hand-pick around thirty of the company's most AI-proficient engineers, pair each with a domain expert in Finance or Legal or HR, and give the pod two weeks to shadow the expert, learn the workflow, and automate it. One of the most agent-forward large companies in the world moves automation between departments the way medieval guilds moved craft: a skilled human travels to the knowledge, apprentices on it, and rebuilds it in place. Thirty people, two weeks at a time, against a company of thousands.

It's the only mechanism anyone has shown working in public. And that's the story hiding in the big number: skills have a scaling curve, and each stage has a different bottleneck.

• At 10 skills. Your problem is writing them.
• At 100. Your problem is finding them, and knowing which of the overlapping ones is good.
• At 2,500. Your problem is the org chart: who owns this, who vouches for it, what's stale, and what happens when the author changes teams.

The first stage is being solved from every direction at once. Model vendors ship official skills, educators ship suites, benchmarks now exist to score quality: SkillsBench measured expert-curated skills raising agent pass rates by 16 points on average. Supply stopped being the constraint a while ago. In my own tracking of the ecosystem, the last two weeks alone minted a dozen near-identical "sync my skills across agents" tools from strangers who don't know each other: everyone hand-building the same distribution duct-tape, nobody building the layer under it.

The second stage is where most teams are now. The obvious rebuttal is that finding is solved: index the skills, let the agent route by search. But routing has a mechanical cost. Every model-invoked skill puts its description into context on every request. One adopter of a major public suite summarized the math as "100 model-invoked skills = 100 descriptions eating your context window," and reports keeping 90% of his own user-invoked instead, meaning a human has to know they exist. And even perfect retrieval answers the wrong question. Search can find you four overlapping skills for a task. It can't tell you which one is maintained, which one your platform team stands behind, and which one encodes a convention you deprecated in March.

Finding is cheap. Vouching is the product.

The third stage had no public data until this week, and Uber is the first company to publish a four-digit internal skill count. The tweet is a victory lap, not an architecture doc; for all I know there's a beautiful internal registry behind it. The mechanism it does describe for moving automation across the org, though, is a rotation of thirty trusted humans, one pairing at a time. Read plainly: the people are the distribution system. Ruben Hassid, whose Claude Cowork guides have tens of millions of views, hit the same wall from the other side and said so after running enterprise workshops: "Teams with hundreds of people using Claude Cowork together. And my files + folder system broke." Individual systems fail at the team boundary. My read of Uber's post is that team systems fail at the org boundary and get patched with headcount.

Every company rolling out agents is on this curve, and it only goes one direction. The tweet-worthy number is how many skills you have. The operational number is how many you'd re-approve today.

Which is why the interesting Uber post is the next one: the one about which skills they deleted, and how they decided.