Should we standardise agents with a Skills catalog — or is that more sprawl?

You’re right to smell both the win and the mess. Reuse without ownership is just sprawl with a friendlier name.

Here’s what’s going on. On Learn, agent skills (for agents and workflows powered by the GitHub Copilot harness) are portable packages of instructions, scripts, and resources — domain expertise you can create, share, and reuse. Unlike tools (connectors, APIs, MCP servers that reach external systems), skills are self-contained logic the orchestrator loads when the user’s request matches the skill’s description. You can upload a SKILL.md or zip bundle, create from blank, or generate with AI. Microsoft 365 Roadmap 571880 (status In development; preview timing September CY2026 and GA October CY2026 on the roadmap — verify for your cloud) describes a Skills catalog so makers can discover, reuse, and selectively share approved organisational skills, with a shared catalog powered by the Microsoft 365 App Store spanning experiences such as Copilot Studio, Microsoft 365 Copilot, and Cowork. Public maker threads (for example on r/copilotstudio) keep asking the practical fork: when is a skill better than a sub-agent or yet another prompt? The honest answer from the product model: skills package how to do a task consistently; tools are what the agent can call; sub-agents are whole collaborators. Mixing them without a register is how you get three half-finished expense bots and no owner.

Steady before scale: Pane 07 Adoption owns the catalog hygiene; Pane 05 GRC owns what “approved organisational skill” means. Schofield’s First Law (historically attributed): don’t put process truth into a skill package unless you can see exactly how to version, reclaim, and retire it when policy changes.

Options that actually work:

1. Curated catalog first. Name 3–5 Wave 0 skills (expense policy check, joiners checklist, knowledge citation style). Require a business owner, review date, and environment scope before anything is “org approved.” Best Steady default.
2. Personal/sandbox skills freely; org catalog by request. Makers experiment in exploration environments; promotion to the shared catalog needs the same bar as publishing an agent. Good while 571880 rolls out.
3. Open the catalog to every maker “to drive reuse.” You’ll get duplicate skills, stale policy Markdown, and nobody sure which version is authoritative.
4. Ignore skills and only govern agents/tools. You’ll keep paying for reinvented instructions in every agent — and miss the standardisation the catalog is for.

12 Panes action / comms: Tell makers: Skill = reusable how-to; tool = external action; don’t paste secrets into a SKILL.md. Tell Adoption: Catalog entries need owners and retirement dates like agents do. Security: Skills that instruct tool use still sit under your tool/MCP allow-list — the catalog doesn’t bypass DLP. Leadership: Reuse is a cost and quality play only if someone owns the package.

Benefits / risks: Consistency and faster agent builds; harness-specific docs (GitHub Copilot harness on Learn) may not match every agent type in your estate; progressive disclosure means a vague skill description gets the wrong invocations; shared App Store surfaces will move with the roadmap. Verify Learn and Message Centre before promising a tenant-wide catalog next quarter.

I’d suggest this week: pick one painful duplicated process, write it once as a skill with a named owner, trial it on two agents in a sandbox, and draft the promotion checklist for “org catalog.” You’ll get Steady reuse without inventing a second junk drawer labelled Skills.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer