For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Review the components that make up Solo Enterprise for agentregistry and the role that each one plays.

Learn about the components that make up Solo Enterprise for agentregistry and the role that each one plays.

Solo Enterprise for agentregistry is a single control plane that you install once and connect to multiple runtimes. It provides a common catalog and control-plane experience across those runtimes, while deployment, discovery, runtime policy enforcement, and telemetry paths vary by runtime. For details about how the registry integrates with each platform, see Runtime architectures.

Component architecture

The following diagram shows the components that make up Solo Enterprise for agentregistry and how they relate to each other.

Clients

You interact with the registry through three interfaces, all served by the registry server on port 12121 by default. Every request they make carries a JWT that the registry validates before it does anything else.

• Registry UI: A browser-based dashboard for people who prefer a visual experience. Use it to browse and search the catalog, deploy agents and MCP servers, review approvals, and explore traces.
• arctl CLI: A command-line client for developers and automation. Use it to scaffold, build, publish, pull, and deploy artifacts, and to script the artifact lifecycle in CI/CD pipelines.
• REST API: HTTP endpoints that expose the same capabilities as the UI and CLI. Use the API to integrate the registry into your own tools and portals.

Registry server

The registry server (agentregistry-enterprise-server) is the core of the control plane. It manages the artifact catalog, artifact approval workflow, deployments, runtime connections, and discovery across connected runtimes. It evaluates AccessPolicy resources for user requests to the registry and chat interfaces. For deployed agent traffic, gateway components enforce runtime authorization from the applicable AccessPolicy configuration. The server also serves the Registry UI and the REST API used by arctl and other integrations.

The registry server relies on PostgreSQL for persistent control-plane state and queries ClickHouse for trace data. It also coordinates with connected runtimes to deploy agents and MCP servers, discover existing agents, and configure governed MCP access.

Access to the server is protected by OIDC. All three interfaces—the Registry UI, arctl, and the REST API—authenticate with your identity provider and send the resulting JWT with each request. The server uses the provider’s OIDC discovery metadata and JWKS public keys to validate the token signature and audience. Only after the token is validated does the server evaluate the caller’s access policies. See OIDC identity provider and About access control for details.

PostgreSQL

PostgreSQL is the control plane’s system of record. It stores published AI artifacts and versions, deployments, runtime connections, and related metadata. By default, the Helm chart deploys a bundled PostgreSQL instance as a single pod for development and evaluation. For production, connect the registry to an external PostgreSQL database. For more information, see BYO PostgreSQL database.

ClickHouse

ClickHouse is a columnar database suited to the high volume of trace data that AI workloads produce. It stores the distributed traces and spans collected from deployed agents and MCP servers. The registry server queries ClickHouse to render the Tracing view in the UI, including the per-request execution flow across agent steps, LLM calls, and MCP tool calls. The Helm chart enables a bundled ClickHouse deployment by default. PostgreSQL remains the system of record for registry state, while ClickHouse is dedicated to telemetry storage and queries.

OpenTelemetry Collector

The built-in OpenTelemetry (OTel) Collector is the ingestion point for runtime traces. Deployed agents and MCP servers export OTLP traces to the endpoint configured in the Runtime resource’s telemetryEndpoint field. When the registry deploys an agent or MCP server, it injects this endpoint into the workload configuration. The collector receives OTLP over gRPC on port 4317 or HTTP on port 4318, and writes the trace data to ClickHouse.

The telemetry endpoint must be reachable from the deployed workload. Runtimes outside the registry cluster require an externally reachable endpoint. You can also point a Runtime directly to an external OTel-compatible backend, or configure the built-in collector to forward traces to a backend such as Jaeger or Grafana Tempo. For more information, see Tracing.

The collector shown in the diagram is the runtime tracing pipeline. Control-plane audit events use a separate, optional OTLP export pipeline and can be sent directly or through a dedicated relay collector to an external audit backend. For more information, see Audit logs.

OIDC identity provider

The registry does not bundle an identity provider (IdP). You bring your own OIDC-compliant provider, such as Keycloak, Okta, or Auth0. The OIDC configuration uses four clients:

• ar-backend: A confidential client used by the registry server. Access tokens must include this client in the aud claim.
• ar-cli-interactive: A public client used by arctl for interactive device authorization.
• ar-cli-password: A public client used by arctl for scripted authentication in CI/CD pipelines.
• ar-ui: A public client used by the Registry UI for the authorization code flow with PKCE.

On every request, the server validates the JWT against the provider’s JWKS public keys and rejects a token that is missing, expired, has an invalid signature, or has the wrong audience before it evaluates any policy. The role or group claims in the validated token are then matched against AccessPolicy resources to decide what the caller can do. For the required clients, claim mappings, and authorization layers, see About access control.

Runtimes

A runtime is a platform that the control plane connects to in order to deploy agents and MCP servers, discover existing agents, or expose MCP servers through a gateway. One registry can connect to multiple runtimes at the same time. The integration model differs by platform; see Runtime architectures for details.

Deployment runtimes materialize deployable artifacts from the catalog. An agent is a deployable unit that combines model configuration with its associated MCP servers, skills, and prompts. MCP servers can also be deployed independently. Prompts and skills remain versioned catalog artifacts and are not deployed as standalone runtime services.

Solo Enterprise for kagent

Solo Enterprise for kagent is a deployment runtime on Kubernetes. The registry deploys and manages agents and MCP servers as Kubernetes workloads. When Solo Enterprise for Istio and Solo Enterprise for agentgateway are installed, runtime AccessPolicy rules are translated into gateway configuration and enforced at an agentgateway waypoint for MCP tool calls and agent-to-agent requests.

AWS Bedrock AgentCore

AWS Bedrock AgentCore is a deployment runtime on AWS. The registry deploys agents and MCP servers as Bedrock AgentCore runtimes in your VPC. A managed agentgateway instance routes governed MCP traffic and enforces runtime authorization.

Azure AI Foundry and Microsoft Copilot Studio

Azure AI Foundry and Microsoft Copilot Studio are discovery-only runtimes. The registry reads agents that already run in your Foundry projects and Power Platform environments and surfaces them in the Instances view. The registry cannot deploy artifacts through a discovery-only runtime.

agentgateway (virtual runtime)

The virtual runtime uses Solo Enterprise for agentgateway to expose remote MCP servers through a single governed endpoint. Unlike the other runtimes, the registry does not manage the lifecycle of the servers here; it governs network access to them and proxies their MCP traffic.

Next steps