How a 3,000-person company got 95% of its employees using AI
By Kaia Colban
A 3,000 person company got 95% of its employees using AI weekly. Not 95% of engineers. Everyone. Sales, marketing, ops, support. We talked to their AI Platform Manager last week to learn how they did it. They bet big on skills (reusable markdown files that teach the AI how to do a specific job) and built their whole system around them. But you can't give everyone every skill, since that results in skills canceling each other out and the right skill being skipped (more on that here: /blog/stuff-nobody-tells-you-about-claude-skills). So they split who gets what into three layers.
- Core: everyone gets them by default. Slack, GitHub, notes. A new hire joins and the skills are already there.
- Team: assigned by department. Sales gets sales skills, marketing gets marketing skills.
- Playground: one place where anyone can build and experiment with whatever they want.
Here's how it runs and what's worth stealing:
- Skills spread bottom-up. Their most-used skill, "Grill Me" (it interrogates your requirements before you build), came from one employee. It landed in the playground, usage climbed, an automated pipeline flagged it, and it got promoted to official. There's one human approval gate at the end, but no one centrally decides what's good.
- More skills is not the goal. He runs about 100 skills but thinks the useful ceiling is closer to 55. Past that, they start colliding and duplicating, so the pipeline actively hunts for overlap and quality. He's seen three different "Google Docs" skills where none of them did the job well. Quality and coverage > volume.
- Skills aren't just tool connectors, they're encoded workflows. The sharpest example is their SRE team, who stopped writing troubleshooting docs and started writing skills instead. Their rule is that if you want them to support your system, you upload a skill, because that's what their triage agent runs against. A doc just sits there waiting to be read, but a skill plugs straight into the triage agent that acts on it when something breaks.
- Non-engineers create skills without ever touching Git. There's a "create skill" skill that they invoke, it branches the repo, wires up CI, and ships. Now, non-engineers are shipping more skills than the engineering team.
- They killed their own tooling. They used to build code-review agents with LangChain and LangGraph, then ripped it all out. Review is now just a skill plugged into a GitHub Action.
Hearing all this, I was impressed with the system, but I wondered whether it was actually being used. That's when he told me "95% of employees are on AI every week," and that everything above is what got them there. I was in disbelief and asked how they calculated the 95%, assuming most people were just using AI to figure out where to get lunch. Turns out they have a whole method. Instead of counting logins, they count "active sessions," which have to include 10+ substantive questions, actual reasoning, and a real decision. I pushed on how they'd even know a session cleared that bar. He explained:
We built an internal wrapper that auto-configures the model, telemetry, and default skills, so every session emits metrics without anyone opting in.
It took his team of 12 engineers six months to build this system, and he said there's still a lot missing. He highlighted three things he would still love to have but doesn't:
- Coverage, not just usage. His metrics tell him a skill fired in 50% of sessions or under 1%. They do not tell him how much of anyone's actual job is covered by skills, or where a skill should exist and doesn't.
- Proactive gap detection. Everything is bottom-up. Skills only get built when a motivated person decides to build one. He was blunt: "if nobody creates it, that probably means people don't see the need." So gaps just sit there, invisible.
- Org-wide visibility. He runs the platform but doesn't actually know how covered the SRE or support teams are. Nobody has the top-down view.
We're building Lore so you get this system without the six-month build, and without the gaps he's still missing. We're early, with a working product and a lot more coming. We're looking for 10 design partners to build alongside. If you're looking for something like this, or want to share what you've built internally, DM us.