Agent Registry

The Agent Registry is where agents and agent teams are defined, configured and published. Changes take effect at runtime, so no redeployment of the service is needed.

Why a registry?

An agent is made of several parts: a language model, instructions, tools, and rules for when to hand over to another agent. The registry keeps these parts as separate, reusable building blocks, so that you can:

• Reuse the same model, tool or instruction set in many agents.
• Change one building block and have every agent that uses it pick up the change.
• Publish an agent to selected users without touching the rest of the platform.
• Run the same agent in several stages, for example test and production, with different settings.
• Protect agents with guardrails and require user approval before sensitive actions.

From agent to deployment

An agent or team describes what it does. An environment holds the settings it runs with, such as endpoints. A deployment combines both and makes the agent available to users. The same agent can be part of several deployments, for example one for test and one for production. See Deployments for details.

Key concepts

Concept	What it is	Everyday analogy
Component	A reusable building block, such as an agent, a team, a model, a tool or an instruction set.	A part in a parts catalog
Environment	A named set of settings and secrets, such as endpoints or timeouts.	The configuration sheet for a workplace
Deployment	A selection of agents and teams, combined with environments, guardrails and the users allowed to use them.	The published edition of the catalog
Guardrail	A rule that checks requests or answers and blocks them if they break the rule.	A safety inspector
Policy	A rule that checks how agents are configured, for example which tools may be combined with which data.	A building code

flowchart LR
    subgraph Components
        M[Model]
        T[Tools]
        C[Instructions]
        A[Agent]
        TM[Team]
    end
    M --> A
    T --> A
    C --> A
    A --> TM
    A --> D[Deployment]
    TM --> D
    E[Environment] --> D
    G[Guardrails] --> D
    D --> U[Users with access]

How an agent gets from idea to users

1. Create the building blocks. Add the model, the tools and the instructions. See Components and tools.
2. Create the agent. Combine the building blocks into an agent. If needed, add handoffs or combine several agents into a team.
3. Define an environment. Store the settings that differ per stage, for example endpoints and secrets. See Environments and secrets.
4. Create a deployment. Select the agents and teams to publish, attach the environment and guardrails, and choose which roles may use them. See Deployments.
5. Use the agent. Authorized users can use the agent in the chat interface. Applications call it through the API, see the Integration Guide.
6. Automate processes. Combine deployed agents with your systems into automated workflows in the low-code editor Agentic Flows.

Tip

Make small changes in a test deployment first. Once the behavior is as expected, apply the same change to the production deployment.

In this section

• Components and tools: building blocks and the kinds of tools an agent can use
• Environments and secrets: settings per stage and how to store credentials
• Deployments: publish agents and control who may use them
• Guardrails: check requests and answers against your rules
• Human-in-the-loop: require user approval before a tool runs
• Policies: check agents against your organization’s rules
• Metadata and descriptions: best practices for describing agents, tools and data
• Registry API reference: endpoints, naming rules and errors