A Skill Nobody Calls Is Worse Than No Skill

Last week my own weekly audit caught me red-handed. I’d built a beautiful machine and then ignored it.

The machine is an audit engine. You feed it a business, it collects the data on cheap deterministic scripts, drafts the writeup on a cheap model, and reserves the expensive model for the one thing that needs real judgment — the honest score. It has 41 passing tests. It has a cost model. It runs a 50-business batch for about three dollars. It is, by any measure, good work.

And nothing called it. Three feet away, an agent I run every three hours was doing the exact same audit — collecting the same data, scoring the same way — except by hand, in its own instructions, a second copy of logic that would slowly drift from the first. I had built the shared thing and then not plugged it in.

That is the trap I want to name, because it’s the one that gets you once you’re good enough at building to build faster than you wire in: a skill nobody calls is worse than no skill. No skill is an honest gap. A skill nobody calls is a lie you tell yourself — you think that capability is handled, it has your name on it, it sits in the folder looking finished — while the work actually runs on a hand-rolled copy that no one is maintaining. The unused version rots. The running version drifts. And you don’t find out until the two disagree in front of a client.

How you end up here

You end up here precisely because you’re doing the right things. You extract the shared engine. You write the reusable skill. You absorb a teammate’s tool into the standard. Every one of those is the correct move. The build instinct is not the problem.

The wiring instinct is what’s missing. Building a capability and deploying a capability are two different jobs, and the first one is more fun. So the shelf fills with excellent tools — an audit engine, a video-repurposing skill, a monitoring script for one site — and the agents that should call them keep doing it the old way, because the old way already works and rewiring is nobody’s Tuesday.

Here’s the tell: on July 21, about 150 of our client sites went down at once — every one of them returning a server error. Nothing caught it. It was found by luck, hours later, when an unrelated job happened to trip over the outage. We had an uptime alarm — for exactly one site. The pattern to watch the whole fleet existed; it had just never been generalized. One site was wired. A hundred and fifty were not.

The fix is boring, and that’s the point

You don’t need a new framework for this. You need to close three loops:

Point the agent at the engine. If you built the shared thing, the hand-rolled copy has to go — replaced by a call to the real one, with a safe fallback so a missing key never takes down a live agent. The test is simple: grep your automation for the name of the thing you built. If it appears zero times, you haven’t shipped it. You’ve shelved it.

Register the skill so it can actually be called. A markdown file in a folder is a draft, not a deployed capability. Until it’s a real, triggerable skill your agents can invoke by name, it’s a document about a capability, not the capability.

Generalize the one-off before you need the hundredth. The single-site monitor becomes a fleet monitor by parameterizing the thing you already wrote. You are never closer to fleet coverage than the moment you finish the first instance — that’s when the pattern is freshest and the cost of generalizing is lowest.

Why this is the whole game

The mission is a million people who own their name across Google and AI answers, at scale, taught to others. Every word in that sentence depends on wiring, not building. “At scale” means the one-off becomes the fleet default. “Taught to others” means the skill is registered and callable, not trapped in your head or your folder. And “owns their name” dies quietly the moment a site goes dark and nothing is watching — a page returning an error cites no one, ranks for nothing, and owns nothing.

Recursive self-improvement is not the machine getting cleverer. It’s the machine noticing the gap between what it built and what it actually runs, and closing it. The audit that caught me is that loop. It re-checks reality every week and asks one unglamorous question: is the thing you built actually the thing that’s running?

Most weeks, the honest answer is “not yet.” The work is making that answer “yes” — pointing the agent at the engine, registering the skill, generalizing the one-off — until the machine you drew on the whiteboard and the machine that’s actually running are the same machine.

Build it. Then wire it in. The second half is the job.