Skills Governance in the Field: Where AMC Fits.

One of our clients had people building about 25 skills a week. Nobody was coordinating it. Two people would spend days and a pile of tokens on the same skill, and neither knew the other existed. Some of the best work ran on someone's laptop, under their login, and stopped when the laptop went to sleep.

Their president put the ask plainly:

"I don't want to be the bottleneck, but I want to know what we're building, why we're building it, who is building it."

That sentence has shaped most of how we think about skills governance.

Usage is easy to see. Value isn't.

An IT lead at another client told us: "Our internal usage of Claude is going up, but I don't know that the team is doing something with it." Token spend and seat counts tell you people are busy. They don't tell you whether any work moved off anyone's plate.

We call this random acts of AI. A pilot here, a hackathon there, a few power users getting big gains that never show up on the P&L.

A promotion path

If people need approval to try something, they stop trying, or they do it somewhere you can't see. So we leave personal use alone. Anyone can build a skill for themselves, and we don't track general prompting.

Governance starts when a skill gets promoted for other people to depend on. A skill moves up four stages:

A person opens every gate. The checks tighten as risk goes up. A skill used inside one department gets a lighter review than one another team depends on, and client-facing or regulated work gets the most.

What promotion looks like

We worked through the mechanics with that same client's team this week. When someone wants to promote a skill to an org skill:

• It checks what's already built or in progress. On site, their team described it as "Johnny's already building that, go talk to Johnny."
• It runs an evaluator. Does it pass its evals, are sources cited, did a second agent check it, are any secrets stored in it?
• It records who approved it. Someone other than the builder signs off.
• It registers as a draft in Agent Mission Control (AMC).
• It opens a pull request to the firm's skill repo in GitHub, and a reviewer signs off before it ships.

Once it's an org skill, it shows up in everyone's Claude from the firm's repo, and every run reports to AMC.

Where AMC fits

AMC turns this from a policy document into something that runs. It does three jobs.

Registry. Through the AMC MCP server, a builder can search existing and draft skills before starting, and register a new draft. That's how the duplicate check works.

Tracking as a condition of certification. A skill can't become an org skill unless AMC reporting is built in. We've demoed a track-skill tool that writes a copy of the skill with reporting baked in, so every run is logged without the user doing anything. Tracking covers only the skills the firm has chosen to depend on. Personal experiments never show up.

Measurement. ROI usually shows up only once you have agents running work. Requiring tracking at the org-skill stage moves measurement earlier. Leaders see runs, cost and who ran what for each skill before any agent exists. The formula is value of the work times runs, minus human intervention cost, minus token cost. Every number traces back to the run log and Azure billing, so it holds up when finance asks.

AMC is available on the Microsoft Marketplace. More on how it works at agentmissioncontrol.ai.

Where to start

You don't need all of this on day one. Three pieces cost almost nothing and stop most of the waste:

• Register what's being built before you build it.
• Publish each skill once, in one place, so everyone gets the latest version.
• Require reporting on anything other people depend on.

Evals, certification and builder levels can come once the catalog has some volume.