Skip to lesson

Google CloudProfessional Agentic Architect2026-093.1 Designing and building agentic workflows in code

Distinguish Skill Registry from Agent Registry

Completed by the knowledge check

Learning objective

Distinguish Skill Registry from Agent Registry by the architectural question each one answers: “Which reusable capability should an agent load?” versus “Which deployed agent should a consumer discover and govern?”

Core idea

Think of Skill Registry as a package library and Agent Registry as a service catalog.

  • Skill Registry distributes self-contained capability packages that agents can discover, version, and load.
  • Agent Registry catalogs callable agents and related agentic components so people and orchestrators can find them and platform teams can govern the fleet.

The distinction is about responsibility, not an exclusive list of resource types. Agent Registry can also govern standalone skills. Decide from the lifecycle you need to manage: capability code and instructions, or deployed agent inventory and endpoints.

How the registries work

Skill Registry distributes capability packages

A skill is a reusable package of instructions, executable code, and documentation. Its archive includes a SKILL.md file that describes the capability. Skill Registry validates uploaded packages and supports semantic retrieval so an agent can find a capability from user intent. The Skill Registry overview defines a mutable Skill resource with a default revision and immutable SkillRevision snapshots.

This model separates two concerns:

  • A publisher updates the skill and selects its default revision.
  • A consumer either follows the default or pins an immutable revision for repeatable behavior.

The result is content that an agent can load into its execution environment. For example, Managed Agents can mount a Skill Registry resource in the agent’s base environment, as described in Create and manage agents. Publishing a skill does not deploy an agent or create a callable agent endpoint.

Agent Registry discovers and governs deployed components

An agent is an autonomous service that performs a workflow. Its registry entry describes the deployed component, including metadata and, where available, its endpoint and advertised Agent2Agent (A2A) capabilities. Agent Registry provides a unified catalog for agents, Model Context Protocol (MCP) servers, endpoints, tools, and standalone skills. See the Agent Registry overview.

Supported Google Cloud runtimes can register agents automatically. External, unsupported, and cross-project agents require manual registration. An A2A-compliant agent exposes an Agent Card whose descriptive skills can be indexed for search. The Agent registration guide explains these paths.

Registration makes a deployment discoverable; it does not host the agent, install a skill package into it, or authorize calls to it. Runtime identity, gateway policy, and destination authorization remain separate controls.

Key distinctions and trade-offs

DimensionSkill RegistryAgent Registry
Primary questionWhat capability package should an agent load?What deployed agent or service should a consumer find?
Main unitSkill content and immutable revisionsCatalog records for agents and other agentic components
Lifecycle triggerPublish, revise, retrieve, and attach a capabilityDeploy, register, discover, update, and retire a service entry
Typical consumerAgent builder or runtimeDeveloper, orchestrator, platform owner, or governance process
Main benefitReuse and controlled capability distributionFleet visibility, ownership, discovery, and policy integration
Main riskLoading unreviewed code or an incompatible revisionTrusting stale metadata or treating discovery as authorization

Central distribution reduces duplicate skill implementations, but a shared update can affect many consumers. Pin revisions when reproducibility matters; follow a default revision when centrally managed updates are more valuable.

Central agent discovery reduces hard-coded endpoints and fragmented inventory, but dynamic selection increases dependence on accurate metadata. Use reviewed identifiers or allowlists when a workflow requires deterministic routing.

Understand the overlap

Agent Registry also supports top-level Skill and SkillRevision resources for centrally governed standalone skills. Its data model distinguishes these executable packages from A2A skills, which are descriptive capability metadata embedded in an agent’s Agent Card.

Therefore, “Agent Registry contains skills” does not make the registries equivalent. A standalone skill is an artifact that can extend an agent. An A2A skill describes what a deployed remote agent claims it can do. Search can find either, but only the standalone package is loaded as reusable implementation content.

Architecture / decision scenario

A bank builds a reusable “validate loan application” skill. The package contains approved instructions, validation scripts, and reference material. Several agent teams need the same logic.

The platform team publishes the package to Skill Registry. Production agents pin the tested revision; development agents can evaluate the default revision. This choice solves capability distribution and version control.

The bank deploys separate loan-intake agents for retail and commercial lending. It registers both in Agent Registry with their deployment metadata, endpoints, and advertised A2A capabilities, then links each stable identifier to its owning team in the bank’s governance catalog. An orchestrator searches Agent Registry to find the appropriate deployed agent for a request. This choice solves deployed-agent discovery and governance.

The two registries work together. Updating the reusable skill does not create a new callable agent. Registering a loan-intake endpoint does not distribute the validation package. The team tests and deploys the chosen skill revision, then keeps the deployed agent’s registry metadata synchronized. Authorization still decides whether the orchestrator may invoke the discovered endpoint.

Common exam traps

  • Choosing Skill Registry when the requirement is to inventory deployed agents, their endpoints, and their owners.
  • Choosing Agent Registry only because the word “agent” appears, when the need is to distribute versioned instructions and code to many agents.
  • Assuming the products are mutually exclusive because Agent Registry can also store standalone skills.
  • Confusing an executable standalone skill with an A2A skill description in an Agent Card.
  • Assuming skill publication deploys an agent, or agent registration installs capability content.
  • Treating a discoverable agent as authorized to receive traffic.

What to remember

  • Skill Registry is primarily a package library for reusable agent capabilities.
  • Agent Registry is primarily a governed service catalog for deployed agentic components.
  • A standalone skill contains loadable implementation content; an A2A skill describes a remote agent’s advertised capability.
  • Use both registries when shared capability packages power multiple discoverable agent deployments.
  • Keep discovery separate from runtime authentication and authorization.

Knowledge check

References