After MCP hype, govern the Skill catalog before adding more tools
Skill catalog governance is the operating discipline that records, classifies, approves, and reviews the capabilities an AI digital employee may use, so manual and repetitive tool work does not become a new bottleneck. It is not a list of every connector a model can reach. It is the answer to practical questions: which Agent may call this capability, what input fields are required, what output should be produced, which actions require confirmation, and where the evidence lives after the run. Without this layer, teams waste time on authorization, inconsistent tool selection, scattered files, and error-prone responsibility checks after an automated task fails.
The tool ecosystem is moving quickly. Anthropic introduced the Model Context Protocol as a way to connect models with tools and data sources, and OpenAI’s Agents documentation treats tools as a core part of agent design in the OpenAI Agents tools guide. Those sources show why more systems will become reachable from AI workflows. For enterprise teams, however, reach is not the same as readiness. The durable advantage is a governed Skill catalog.
Put the catalog before automation
Many teams start by giving one Agent browser access, email access, spreadsheet access, CRM access, document access, database access, and web search. It looks powerful during a demo. It becomes fragile in operations. Similar tools overlap, one task writes inputs differently from another, and high-risk actions do not have a consistent approval boundary.
Axon uses a more operational language for office teams. System Skills provide standard capabilities for office, file, internet, and media work. User Skills package a company’s specific process into a reusable capability. Agents orchestrate Skills into a fixed workflow. Teams that need the capability layer can start with the System Skills foundation and the System Skills versus general agents article.
The central view of skill catalog governance is simple: tools should not be poured directly into Agents. Tools should first become Skills with boundaries, fields, permission levels, and review evidence.
What an operating Skill catalog contains
A Skill catalog is not only a technical inventory. It should be readable by operations, business owners, and reviewers. A practical catalog captures purpose, required inputs, output artifacts, permission level, failure behavior, and reuse scenarios.
{
"skillId": "sales-brief-from-web-and-pdf",
"owner": "sales-ops",
"capabilityLayer": "user-skill",
"allowedAgents": ["weekly-customer-brief-agent"],
"inputContract": ["companyName", "sourceUrls", "pdfFiles", "recipientRole"],
"permissionLevel": "confirm",
"outputs": ["brief.md", "source-list.md", "email-draft.md"],
"failurePolicy": "missing source or uncertain claim returns a review note",
"reviewEvidence": ["runId", "artifactPath", "approvalDecision"]
}
The value of the schema is not the JSON itself. It is the constraint it creates. allowedAgents prevents a random workflow from calling a sensitive capability. inputContract turns Source Data into a durable contract; the related design pattern is covered in Source Data fields. permissionLevel connects risky actions to Trust Mode. reviewEvidence makes each run inspectable after the fact.
| Catalog field | Operating use | Failure if missing |
|---|---|---|
| owner | Names the capability steward | Nobody repairs the Skill after failure |
| inputContract | Controls input quality | Context gets hidden in long prompts |
| permissionLevel | Separates automatic and confirmed actions | Send, overwrite, delete, or publish actions drift into risky automation |
| outputs | Names the expected artifacts | Files stay inside chat and cannot be accepted |
| failurePolicy | Handles uncertainty | The Agent invents an answer or fails silently |
Promotion rules for external tools
An external tool should not enter a core Agent just because it can be connected. Treat each capability as moving through four states.
- Observed: humans experiment with the tool and document where it helps.
- Candidate: the tool may be used for one-off tasks, but not scheduled workflows.
- Controlled: the tool has an input contract, permission level, artifact path, and a named owner.
- Stable: the capability has run history, failure examples, fixes, and acceptance criteria.
This promotion model keeps tool excitement from destabilizing business workflows. MCP servers, browser tools, file tools, and external connectors may all be useful. Only cataloged capabilities should become part of a long-running AI digital employee.
How Axon turns the catalog into governance
Skill catalog governance has to land in product objects, not only a spreadsheet. In Axon, it connects to three places.
The first is Trust Mode. Low-risk reading and formatting can be automatic. Sending email, changing external systems, overwriting files, deleting content, or publishing material should require confirmation or authorization. The operational boundary is explained in human approval boundaries.
The second is the workspace. Each Skill run should leave behind input snapshots, output files, source summaries, and approval decisions. A reviewer should not have to reconstruct the run from chat memory.
The third is the Agent control plane. The catalog gives the control plane metadata: which Agent called which Skill, whether the call matched the permission level, and whether a failure came from bad input or a broken capability. For teams managing multiple workflows, those fields become state, risk, and review signals.
A three-part rollout
This does not need to become a heavy governance project. Start with one department and a small number of repeated capabilities.
- Inventory five tools that Agents or human assistants already call repeatedly, and record owner, input fields, and output artifacts.
- Turn two low-risk tools into Skill catalog cards with
permissionLevelandfailurePolicy. - Run one Agent with a cataloged Skill, then save runId, artifactPath, and approvalDecision in the workspace.
FAQ
Q1: Does skill catalog governance slow down adoption?
It can slow the first workflow slightly, because the team has to name inputs, outputs, owners, and permissions. It speeds up every workflow after that. The same contract can be reused instead of renegotiated inside another prompt.
Q2: Can business teams use MCP tools directly?
They can experiment, but direct use should not be the default for recurring Agents. A business team needs a packaged Skill with a clear purpose, input contract, output artifact, owner, and permission level.
Q3: Which tools should enter the catalog first?
Start with low-risk, high-frequency capabilities whose output is easy to inspect: web reading, PDF extraction, Markdown generation, Excel reading, and email draft creation. Sending, overwriting, deleting, paying, or publishing should move through confirmation or authorization.
Q4: What proves the catalog is working?
Pick one Agent run. If you can see which Skills were used, where inputs came from, where artifacts were stored, which permission boundary was triggered, and how failure would be handled, the catalog is doing real work.
Start with one catalog card
If your team is experimenting with MCP or external tool connectors, do not begin by asking what else can be connected. Pick three frequent office actions and write one Skill catalog card for each: input fields, permission level, artifact path, owner, and failure policy. Then assemble one of those cards into an Axon AI digital employee and make the run evidence visible to the reviewer. Start with one small catalog card now, then learn more from the Axon Agent operations articles before expanding the catalog.