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

Understand the key concepts of Solo Enterprise for agentregistry, including the artifact catalog, artifact types, runtimes, security, observability, and management interfaces.

Catalog

An artifact catalog is a centralized, searchable inventory of all AI building blocks that your organization uses, including agents, MCP servers, prompts, and skills. Think of it as a package registry for AI, similar to how Docker Hub or npm manage container images and code libraries, but designed for the governance and lifecycle management challenges that are unique to AI systems.

Without a catalog, organizations end up with fragmented artifact sprawl. AI building blocks are scattered across GitHub repos, internal wikis, container registries, and personal machines. Teams share MCP server endpoints over Slack and pass skill files over email. When someone iterates on a skill, colleagues who received an earlier copy have no way of knowing whether or not a newer version exists. MCP servers get stood up ad-hoc with no record of who owns them, whether they have been reviewed by security, or whether they are actively maintained.

The Solo Enterprise for agentregistry catalog solves this by giving every artifact a single authoritative home and making discovery straightforward. Developers publish artifacts to the catalog with a version tag. Any team member can then search artifacts by name, description, or tag to find available instances that are approved within the organization. Platform teams can govern what AI artifacts are added to the catalog and which ones to remove through access policies and approval workflows. The catalog also tracks where each artifact is deployed, so teams have full visibility across environments.

Solo Enterprise for agentregistry also adds the enterprise controls that production systems require when managing AI artifacts in the catalog, including OIDC-gated access, role-based permissions, artifact approval queues for AI artifacts, runtime authorization that governs what deployed agents are allowed to call, and MCP-aware observability so operators can see exactly what is happening at the tool level.

Artifacts

The catalog stores different types of AI artifacts so that they can be consumed, deployed, maintained, and observed within an organization. Each type has its own lifecycle, versioning semantics, and deployment options.

Agents

An agent is a deployable unit that you publish, version, and deploy to a runtime through the registry. When you add an agent to the catalog, other teams can discover it, reuse it, or compose it into multi-agent workflows. You can also use Solo Enterprise for agentregistry to discover agents that were not deployed through the registry but exist in connected runtimes, giving you a unified view of your full agent inventory.

Solo Enterprise for agentregistry supports two agent types that differ in how they are built and deployed.

Agent harnesses

An agent harness is the application layer that executes an agent and adds capabilities around its model. It typically assembles context, invokes the model, executes tool calls, loads skills, feeds results back into the agent loop, and manages session state. A harness can also provide memory, subagents, permissions, approvals, sandboxing, and event streaming.

Examples include Claude Code, Codex CLI, Gemini CLI, OpenClaw, and custom in-house applications.

MCP servers

An MCP server exposes tools that agents can call at runtime. Solo Enterprise for agentregistry supports three approaches to managing MCP servers, depending on whether you need catalog visibility, traffic governance, or full lifecycle management.

Prompts

A prompt is a versioned, org-wide system prompt or instruction template that is stored in the catalog. Prompts let platform teams publish standardized baselines, such as safety guardrails, agent persona guidelines, or approved reasoning frameworks, that development teams can reference from their agent configurations. Like other artifact types, prompts are versioned so consumers can always see which iteration they are using and when a newer version becomes available.

Skills

A skill is a reusable instruction set or slash command for AI agents that you can store as a versioned artifact in the catalog. Instead of sharing skill files ad-hoc, developers publish skills to the registry with a version tag. Consumers pull the latest approved version with a single arctl pull command. When the author iterates on a skill, they publish a new version to the catalog so that consumers can pull the update at any time rather than waiting to receive a file over email or Slack.

Runtimes

A runtime is an agentic platform that Solo Enterprise for agentregistry connects to in order to deploy agents, discover existing agents, or expose MCP servers.

Deployment runtimes

A deployment runtime is a platform where Solo Enterprise for agentregistry can actively deploy and manage agents and MCP servers. When you connect a deployment runtime, you can push agents from the catalog to that runtime with a single command or UI action. The registry tracks every deployment instance and surfaces both managed instances (deployed through the registry) and unmanaged instances (deployed by other means) in the Instances view.

Solo Enterprise for agentregistry supports the following deployment runtimes:

Discovery-only runtimes

A discovery runtime is a read-only connection to a platform where agents are already running but were not deployed through Solo Enterprise for agentregistry. The registry scans the connected platform and surfaces the discovered agents in the Instances view so you have a unified view of your agent portfolio across environments. You cannot deploy agents to a discovery runtime through the registry.

Solo Enterprise for agentregistry supports the following discovery-only runtimes:

Virtual runtime (MCP gateway)

The Virtual runtime is a special runtime that integrates Solo Enterprise for agentregistry with Solo Enterprise for agentgateway to expose remote and in-cluster MCP servers through a single managed gateway endpoint. Unlike deployment and discovery runtimes, the virtual runtime is exclusively used for proxying MCP server traffic.

When MCP traffic flows through the gateway, every request is logged with MCP-specific metadata—including the session ID, tool name, and resource type—giving operators visibility into exactly what agents are doing at the tool level.

Unlike a deployment runtime, the registry does not manage the lifecycle of the MCP servers that are exposed through the virtual runtime. You deploy and update those servers yourself, for example through your own CI/CD pipelines. The registry’s role is to govern network access to them, acting as an east-west gateway for MCP traffic rather than to build, deploy, or version them.

For more information, see Remote MCP gateway.

Governance

As organizations expand their AI footprint, governance typically comes down to who can put artifacts into the registry, who can access them, and what those artifacts are allowed to do at runtime. Solo Enterprise for agentregistry addresses each of these with a layered model.

User access control

Solo Enterprise for agentregistry requires all users to authenticate through an external OIDC-compliant identity provider, such as Keycloak, Okta, or Auth0. Every request must carry a valid JWT. Tokens without a valid signature or with an incorrect audience claim are rejected before any other check runs.

After authentication, access is controlled by AccessPolicy resources. The default posture is deny all: a user with no matching AccessPolicy cannot see or interact with anything in the catalog, even if they authenticate successfully. Platform teams create AccessPolicy resources that map OIDC group claims to specific actions and artifact kinds. This way, you can account for different personas, such as a security reviewer who can approve artifacts but not deploy them, or a developer who can read and publish artifacts to the catalog, but cannot delete them.

For more information, see About access control.

Artifact approval

By default, any user with registry:publish permission can add artifacts to the catalog immediately. Organizations that need a stronger gate can enable the artifact approval mode. When enabled, any create, update, or delete operation by a non-admin user is staged instead of applied immediately. The artifact is held in a pending state, invisible to other users, until an admin approves the request.

Admins manage the approval queue through the registry UI, the REST API, or an embedded Python client library, allowing teams to integrate approvals into existing internal portals or CI/CD pipelines without being forced to use the registry UI directly.

For more information, see Artifact approval.

Agent runtime authorization

The same AccessPolicy resource that controls user access also governs what deployed agents are allowed to do at runtime. For example, you can restrict which MCP tools an agent is allowed to call and which other agents it is allowed to invoke. Enforcing these policies requires a Solo Enterprise for agentgateway instance.

Runtime authorization closes the gap between catalog-level governance and runtime behavior. Having an MCP server in an agent’s configuration does not automatically grant access to every tool that the server exposes.

For more information, see Agent runtime authorization.

Observability

Traditional monitoring tools were not designed for AI systems. Knowing that an HTTP request succeeded tells you very little when the request is initiated by an agent that invokes several MCP tools. You also need to know which tool was called, which agent called it, how long the tool took to respond, and whether the call was permitted by policy. Without this context, debugging unexpected agent behavior becomes a guessing game, and compliance teams have no audit trail to work with.

Solo Enterprise for agentregistry comes with the following built-in capabilities to address common observability concerns.

Distributed tracing

Solo Enterprise for agentregistry emits distributed traces by using the OpenTelemetry standard. Traces give platform teams a complete picture of latency, errors, and call chains across agent interactions. The registry UI includes an integrated execution flow view that lets you drill into any request to see the details of each hop, so you can identify exactly where latency or errors occur without leaving the registry.

For more information, see Tracing.

Compliance

Where observability serves platform and SRE teams, compliance serves security and audit teams. Solo Enterprise for agentregistry keeps a verifiable record of activity in the registry to support these requirements.

Audit logging

Solo Enterprise for agentregistry records every operation that was performed on registry artifacts, including who published, approved, updated, or deleted an artifact, and when. This audit trail gives compliance and security teams a verifiable record of all changes to the catalog without relying on manual processes. Audit events can be exported to an external SIEM for centralized analysis and retention.

For more information, see Audit logs.

Management interfaces

Solo Enterprise for agentregistry exposes three interfaces for interacting with the registry: the registry UI, the arctl CLI, and the REST API. Each is suited to different personas and workflows. Understanding which interface to reach for and when helps teams to integrate the registry into their existing processes without unnecessary friction. Installation and configuration are handled separately with Helm; see Operations.

Registry UI

The registry UI is a browser-based dashboard designed for both administrators and everyday users. It provides a visual, point-and-click experience for the most common catalog, deployment, and governance tasks.

arctl CLI

arctl is the command-line interface for developers and operators who prefer scripting or terminal-based workflows. It covers the full artifact lifecycle, from authentication and publishing to querying the catalog and managing deployments, making it the right choice for CI/CD pipelines, automated testing, and day-to-day developer tasks.

REST API

The REST API exposes the full capabilities of the registry as HTTP endpoints, making it the right interface for automation engineers and teams that need to integrate the registry into custom tooling. Any action available in the UI or CLI is also available through the API. This includes the artifact approval endpoint, which lets teams embed the approval step into their own internal developer portals or pipeline tools without requiring users to log into the registry UI directly.

Next steps

Use the guides below to dive deeper into each of the concepts.

Artifacts

Scaffold, build, and publish agents and MCP servers to the catalog so that other teams can discover and reuse them.

Runtimes

Connect deployment and discovery runtimes so that you deploy and discover agents across multiple environments, or set up the Virtual runtime to expose MCP servers through a managed gateway endpoint.

Governance

Configure who can access the registry, set up approval workflows to control what enters the catalog, and define runtime policies that restrict what deployed agents are allowed to do.

Observability

Get visibility into agent and MCP server activity across your environment.

Compliance

Keep a verifiable audit trail of changes to the registry for security and audit teams.