Agent Registry lets you register, discover, and govern agentic components,
including AI agents, Model Context Protocol (MCP) servers and tools, endpoints,
and standalone skills, across your Google Cloud environment. By
consolidating these components into a single registry, you can reduce
fragmented tool access, isolated data, and redundant integrations across your
AI deployments.

You can view and manage registered components as resources in
Agent Registry. For more information about Agent Registry
resources, see [Agent Registry data model](https://docs.cloud.google.com/agent-registry/data-model.md.txt).

## Why use Agent Registry?

Agent Registry is structured around three primary goals to help you manage
your agents, MCP servers, endpoints, and skills:

- **Accelerate development** : discover and reuse existing agentic capabilities such as [A2A skills](https://docs.cloud.google.com/agent-registry/skills-architecture.md.txt#standalone-vs-a2a), standalone [skills](https://docs.cloud.google.com/agent-registry/skills-architecture.md.txt), and MCP tools across your organization. You can query the registry to identify and use available capabilities, removing the need to create custom integrations for each new process.
- **Simplify integration** : use the standardized MCP and [Agent2Agent (A2A)](https://docs.cloud.google.com/agent-registry/a2a-protocol.md.txt) protocols to locate and connect to functional endpoints and reduce infrastructure management overhead.
- **Support governance** : enforce security through network and access policies and [management boundaries](https://docs.cloud.google.com/agent-registry/boundaries-and-topology.md.txt) across your agentic fleet. Other services can use the [identifiers of your agentic
  components](https://docs.cloud.google.com/agent-registry/identity-and-identifiers) to define permissions and control which agents can access your data, including centralizing agent metadata across multiple Google Cloud projects for governance with [Agent Gateway](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview.md.txt).

## Use Agent Registry with Gemini Enterprise Agent Platform

Agent Registry is designed to work alongside other services in
[Agent Platform](https://docs.cloud.google.com/gemini-enterprise-agent-platform/overview.md.txt)
to secure and govern agent interactions at runtime.

In Agent Platform, Agent Registry
maintains the authoritative registry of agents, MCP servers, tools, skills, and
external endpoints that you need to govern, and generates the
[identifiers and resource names](https://docs.cloud.google.com/agent-registry/identity-and-identifiers.md.txt)
referenced by discovery clients and security policies.

Identity and Access Management (IAM) access policies bind
[agent principals](https://docs.cloud.google.com/agent-registry/identity-and-identifiers.md.txt#agent-principals)
to the target resources registered in Agent Registry. You can provision
verifiable agent principals for workloads through
[Agent Identity](https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity.md.txt)
and manage credentials for external tools through
[auth providers](https://docs.cloud.google.com/agent-registry/component-lifecycle-and-discovery.md.txt#auth-providers).

[Agent Gateway](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview.md.txt)
uses your IAM and content security policies to determine where
to enforce policies at runtime as the network enforcement point for agent
traffic. Before routing requests between agents, MCP servers, or external
endpoints, Agent Gateway queries Agent Registry,
evaluates your configured IAM policies, and applies
[Model Armor prompt and response
inspection](https://docs.cloud.google.com/model-armor/model-armor-agent-gateway-integration).

## Define the governance project for a central registry

In Agent Registry, a *governance project* is the Google Cloud project
where you [enable the Agent Registry API](https://docs.cloud.google.com/agent-registry/setup.md.txt) to centrally catalog,
discover, and govern your [agentic components](https://docs.cloud.google.com/agent-registry/data-model.md.txt). You
run discovery queries, manage registry resources, and configure access and
egress policies in this project.

Depending on your architecture, you can use a governance project in a
single-project or cross-project configuration:

- **Single-project configuration** : you deploy your AI workloads and enable Agent Registry in the same Google Cloud project. Agent Registry [automatically registers](https://docs.cloud.google.com/agent-registry/automatic-registration.md.txt) supported workloads deployed in that project, and you can [manually register](https://docs.cloud.google.com/agent-registry/manual-registration.md.txt) custom components or external endpoints in the same project.
- **Cross-project configuration**: you can centralize governance across
  multiple Google Cloud projects with, or without, a management
  boundary:

  - **[Management boundary](https://docs.cloud.google.com/agent-registry/boundaries-and-topology.md.txt)** : you configure a management boundary on a folder or organization in [Resource Manager](https://docs.cloud.google.com/resource-manager/docs/boundaries-and-capabilities-overview.md.txt), and its associated [management project](https://docs.cloud.google.com/agent-registry/boundaries-and-topology.md.txt#management-project) serves as your central governance project. Agent Registry automatically aggregates supported agents and MCP servers discovered across all member projects in the boundary into the management project. You can also aggregate `Service` and `Binding` resources that you register directly in the management project.
  - **No management boundary** : you designate a standard Google Cloud project as your governance project where Agent Registry and shared governance services such as [Agent Gateway](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview.md.txt) are enabled. Your AI workloads can run in separate Google Cloud projects, on-premises environments, or external clouds. In Agent Registry, components hosted outside the governance project are referred to as *remote* components. Because automatic registration without a management boundary only discovers supported workloads deployed in the governance project, you manually register remote components in the central registry using `Service` resources. For more information, see [Cross-project registration considerations](https://docs.cloud.google.com/agent-registry/register-agents.md.txt#cross-project-considerations).

## What's next

- Learn about the Agent Registry [data model](https://docs.cloud.google.com/agent-registry/data-model.md.txt) to understand how to manage your agentic capabilities.
- Review [key concepts](https://docs.cloud.google.com/agent-registry/concepts.md.txt) to familiarize yourself with the essential terms used in Agent Registry.
- Learn about [Identity and identifiers](https://docs.cloud.google.com/agent-registry/identity-and-identifiers.md.txt) used for registry discovery and policy governance.
- Learn about [Component lifecycle and discovery](https://docs.cloud.google.com/agent-registry/component-lifecycle-and-discovery.md.txt), [A2A protocol](https://docs.cloud.google.com/agent-registry/a2a-protocol.md.txt), [Cross-project boundaries](https://docs.cloud.google.com/agent-registry/boundaries-and-topology.md.txt), and [Skills architecture](https://docs.cloud.google.com/agent-registry/skills-architecture.md.txt).
- To get started, [set up Agent Registry](https://docs.cloud.google.com/agent-registry/setup.md.txt).