One agent's skill catalog is easy; a fleet's is not
A single agent loading skills from a local .claude/skills/ directory has no consistency problem to solve -- there is one process, one filesystem, one catalog. The moment a second agent joins the picture, running as its own process, possibly on its own host, possibly built by a different team, the catalog stops being a filesystem detail and becomes a piece of shared state that two independent runtimes both need to agree on.
This matters specifically in multi-agent fleets: a supervisor agent that delegates to worker agents, a pipeline of specialist agents handing a task off in sequence, or a set of peer agents that discover each other over a protocol like A2A. In every one of those topologies, "which skills exist and what do their descriptions say" is a question more than one process needs the same answer to, and the registry pattern is the architecture for keeping that answer consistent.
Central registry versus local copies
There are exactly two honest designs. A central registry is a service (or a shared, versioned store) that every agent in the fleet queries or subscribes to; no agent holds its own permanent copy of the catalog, only a cache with a known freshness bound. A local-copy design has each agent carry its own directory of skill files, kept in sync with the source of truth through whatever deployment mechanism ships that agent's code.
Local copies are simpler to reason about per-agent -- there's no runtime dependency on a registry service being up -- but they push the consistency problem into deployment: every agent's copy has to be redeployed together for a skill change to take effect fleet-wide, which is exactly the kind of coordinated rollout that's easy to get wrong under time pressure. A central registry inverts that: one place to update, but now every agent has a runtime dependency on that registry, and its availability becomes part of the fleet's own availability story.
The practical split that holds up: local copies for skills that are stable and rarely change (the equivalent of vendoring a dependency at a pinned version), a central registry for skills that change often enough that redeploying every agent per change is the actual bottleneck. Most fleets end up with both -- a small core of always-available local skills and a larger, more volatile set fetched from a registry with a fallback to the last-known-good local cache.
Advertising capability, not just holding it
A registry that only agents query is half the pattern. The other half is agents advertising what they can do, so a supervisor or a peer can decide whether to hand work to them without already knowing their internals. This is precisely the role an agent-to-agent protocol's capability declaration plays -- see A2A's agent card for the concrete shape of that advertisement, which is functionally a skill catalog exposed outward rather than consumed inward.
The distinction matters architecturally: a registry an agent reads from is a dependency; a card an agent publishes is an interface contract with everyone who might route work to it. Getting the two conflated is how a fleet ends up with an agent whose advertised capabilities have drifted from what its actual loaded skill set can do -- it claims a capability via its card, but the registry entry backing that skill was updated (or removed) out from under it.
Supervisor Worker agent A Worker agent B
| | |
|-- query capabilities ---->| |
|<-- advertises: {code-review, test-writer} ------------|
|-- query capabilities --------------------------------->|
|<-- advertises: {code-review, deploy-check} ------------|
|
| route "review this diff" to whichever advertises code-review
| (both do -- pick by load, or by which catalog version is fresher)