Bridge catalog registration

After completing local development and testing, the next step is to register your agent in the Bridge Catalog. This registration creates a draft version that can be reviewed, tested, and eventually published for production use.

The Bridge Catalog is the central registry for all agents on the Kyndryl Bridge Platform. Registration involves:

Building and publishing your container image to JFrog Artifactory

Discovering available MCP tools using the discovery script

Registering the agent definition in the Bridge Catalog

Configuring skills, tools, knowledge bases, and schemas

Keeping as draft until ready for production deployment

Prerequisites

Before registering your agent:

Agent code is complete and tested locally (local_dev mode)

Ready to test with Bridge Platform (bridge_dev mode) after registration + deployment

Container image built and pushed to JFrog Artifactory

MCP tools discovered using MCP Tools Discovery

Input/output schemas defined

Access to Bridge Platform Admin UI or API

Best practice for bridge_dev: Create both catalog registration and deployment registration before you start bridge_dev testing. This applies even when using a temporary testing image like under-development-for-bridge-dev-test:release-....

To register a catalog

Step 1: Build and push container image

Before registration, your agent must be containerized and published to JFrog Artifactory.

Do NOT use python:3.12-slim or other public Docker Hub images. All production agent images must use the kaif-pythoncompileimage base image.

Build and Push Commands

# Set variables
export IMAGE_NAME="bdg-sw-agents-incident-enrichment"
export IMAGE_TAG="release-$(date +%Y.%m.%d)-$(git rev-parse --short HEAD)-$(date +%s)"
export REGISTRY="kyndryl.jfrog.io/kyn-cto-kaif-docker-local"

# Build the image
docker build -t ${{REGISTRY}}/${{IMAGE_NAME}}:${{IMAGE_TAG}} .

# Login to JFrog (use your credentials)
docker login kyndryl.jfrog.io


# Push the image
docker push ${{REGISTRY}}/${{IMAGE_NAME}}:${{IMAGE_TAG}}


# Note the full image path for registration
echo "Image: ${{REGISTRY}}/${{IMAGE_NAME}}:${{IMAGE_TAG}}"

Step 2: Registration methods

There are two ways to register your agent in the Bridge Catalog:

Option A: UI Registration (Manual)

Navigate to Bridge Platform Admin Console

Go to Catalog → Agents → Create New Agent

Fill in the required fields:

Agent Name

Description

Agent Type

Container Image

Resource Requirements

Configure Skills, Tools, and Knowledge Bases

Define Input/Output Schemas

Save as Draft

Option B: JSON upload

Prepare your agent definition JSON file

Navigate to Catalog → Agents → Import Agent

Upload the JSON file

Review and confirm the configuration

Save as Draft

Option C: API registration (Programmatic)

You can register your agent programmatically using the Agent Catalog REST API.

API Endpoint

POST /kaif/v3/agent-catalog/agents

Host: Use KAIF_HOST (for example, https://dev1-aws-oregon-base.bridge.kyndryl.com)

Authentication

The API requires a Bearer token obtained from the Bridge Access Management token endpoint:

POST /api/iam/v4/identity/token

The response contains a token field, use it as Authorization: Bearer <token>.

Save the agent_catalog_id from the response — you will need it in your EXECUTION_CONTEXT for bridge_dev testing and production deployments.

Programmatic Registration Script

The project includes a helper script at scripts/register_agent.py:

# Ensure .env has KAIF_HOST, SERVICE_API_KEY, and BRIDGE_ACCOUNT_ID set  
python scripts/register_agent.py

The script: 1. Fetches an Bridge Access Management token using SERVICE_API_KEY 2. Reads agent-catalog-registration.json from the project root 3. POSTs to /kaif/v3/agent-catalog/agents on the account-specific host 4. Prints the agent_catalog_id on success

Step 3: Agent definition JSON Structure

The agent definition JSON contains all metadata required for registration. Below is the complete structure with explanations.

JSON Schema Reference

Field	Type	Required	Description
name	string	Yes	Unique agent identifier (lowercase, hyphens allowed)
description	string	Yes	Human-readable description of the agent
agent_type	string	Yes	Type: agentic_solution, chatops, workflow
flow	object	Yes	Container execution configuration
metadata	object	Yes	Tags and ownership information
skills	array	Yes	List of capabilities the agent provides
tools	array	No	MCP tools and connectors required (each with type, operations)
knowledge_bases	array	No	Knowledge bases the agent uses
llm	array	Yes	LLM provider and model configuration
schemas	object	Yes	Input/output JSON schemas
source	object	No	Source code repository (agent_code_url, branch, manifest_path)
is_latest	boolean	Yes	Whether this is the latest version
is_published	boolean	Yes	Publication status (false for draft)
canCreateDeployment	boolean	Yes	Whether deployments can be created

Step 4: Incident enrichment agent registration

Below is the complete registration JSON for the bdg-sw-agents-incident-enrichment agent:

Agent Definition JSON

{ 
 "name": "incident-enrichment-agent",
 "description": "AI agent that enriches incident tickets with contextual data from ServiceNow and Bridge Data platform for faster resolution",
"agent_type": "agentic_solution",
 "flow": {
 	"name": "incident-enrichment",
 	"description": "Multi-step workflow for incident analysis and enrichment",
 	"steps": [
	 {
	 "name": "inc-enrich-step",
	 "image": "kyndryl.jfrog.io/kyn-cto-kaif-docker-local/under-development-for-bridge-dev-test:release-2026.03.27-abc1234-1774333268",
 	"command": [
 	"python3 main.py"
 	]
    }
 ]
},

 "metadata": {
 "tags": [
 	"incident",
 	"enrichment",
 	"servicenow",
 	"operations"
 ],

"owner_team": "platform-operations",
 "maintaining_team": "kaif-agents-team"
 },

 "skills": [
 {

 	"name": "Incident Retrieval",
 	"description": "Retrieves incident details from ServiceNow using ticket ID"
 },

 {

 "name": "Asset Lookup",
 "description": "Looks up related CI/asset information from Bridge Data platform"
 },
 {
 "name": "Change History Analysis",
 "description": "Analyzes recent change records that may be related to the incident"
 },
 {
 "name": "Contextual Enrichment",
 "description": "Synthesizes data from multiple sources to provide comprehensive incident context"
 },
 {
 "name": "Resolution Recommendations",
 "description": "Generates AI-powered recommendations based on enriched incident data"
 }
 ],
 "tools": [
 {
 "name": "servicenow_mcp",
 "type": "mcp",
 "description": null,
 "operations": [
 "servicenow_search_incidents",
 "servicenow_search_change_requests",
 "servicenow_create_incident"
 ],
 "endpoint": null,
 "auth_required": false
 },
 {
 "name": "bridge_mcp",
 "type": "mcp",
 "description": null,
 "operations": [
 "bridge_execute_query",
 "bridge_get_domain_details",
 "bridge_get_table_details",
 "bridge_list_catalogs",
 "bridge_list_domains",
 "bridge_list_tables"
 ],

 "endpoint": null,
 "auth_required": false
 },

 {
 "name": "ChatOps",
 "type": "connector",
 "description": null,
 "operations": [],
 "endpoint": null,
 "auth_required": false
 },
 {
 "name": "Elasticsearch",
 "type": "connector",
 "description": null,
 "operations": [],
 "endpoint": null,
 "auth_required": false
 }
 ],
 "knowledge_bases": [
 {
 "name": "incident-runbooks",
 "description": "Knowledge base containing incident resolution runbooks and procedures",
 "type": "global"
 },
 {
 "name": "infrastructure-docs",
 "description": "Infrastructure documentation and architecture diagrams",
 "type": "account"
 }
 ],
 "llm": [
 {
 "provider": "hostedllm",
 "model": "bring_your_own"
 }
 ],
 "schemas": {
 "default": false,
 "input": {
 "type": "object",
 "required": ["query", "parameters", "input"],
 "properties": {
 "query": {
 "type": "string",
 "description": "Natural language query or instruction for the agent"
 },
 "parameters": {
 "type": "object",
 "additionalProperties": true,
 "description": "Additional parameters for agent execution"
 },
 "input": {
 "type": "object",
 "required": ["data", "channel", "account_settings"],
 "properties": {
 "data": {
 "type": "object",
 "required": ["incident_id"],
 "properties": {
 "incident_id": {
 "type": "string",
 "description": "ServiceNow incident ticket ID (e.g., INC0012345)"
 },
 "include_changes": {
 "type": "boolean",
 "default": true,
 "description": "Whether to include related change records"
 },
 "lookback_days": {
 "type": "integer",
 "default": 7,
 "description": "Number of days to look back for related changes"
 }
 },
 },
 "channel": {
 "type": "object",
 "required": ["channelId", "workspaceName"],
 "properties": {
 "channelId": {
 "type": "string",
 "description": "Slack channel ID for notifications"
 },
 "workspaceName": {
 "type": "string",
 "description": "Slack workspace name"
 }
 },
 },
 "account_settings": {
 "type": "object",
 "required": ["servicenow", "bridge_data"],
 "properties": {
 "servicenow": {
 "type": "object",
 "required": [
 "SERVICENOW_INSTANCE",
 "SERVICENOW_USER",
 "SERVICENOW_PASSWORD"
 ],
 "properties": {
 "SERVICENOW_INSTANCE": {
 "type": "string",
 "format": "uri",
 "description": "ServiceNow instance URL"
 },
 "SERVICENOW_USER": {
 "type": "string",
 "description": "ServiceNow API username"
 },
 "SERVICENOW_PASSWORD": {
 "type": "string",
 "description": "ServiceNow API password"
 }
 },
 },
 "bridge_data": {
 "type": "object",
 "required": [
 "BRIDGE_DATA_ENDPOINT",
 "BRIDGE_DATA_API_KEY"
 ],
 "properties": {
 "BRIDGE_DATA_ENDPOINT": {
 "type": "string",
 "format": "uri",
 "description": "Bridge Data platform endpoint"
 },
 "BRIDGE_DATA_API_KEY": {
 "type": "string",
 "description": "Bridge Data API key"
 }
 },
 }
 },
 }
 },
 }
 },
 },
 "output": {
 "type": "object",
 "properties": {
 "incident": {
 "type": "object",
 "description": "Original incident details from ServiceNow"
 },
 "enrichment": {
 "type": "object",
 "properties": {
 "related_assets": {
 "type": "array",
 "description": "List of related CIs/assets"
 },
 "recent_changes": {
 "type": "array",
 "description": "Recent change records that may be related"
 },
 "similar_incidents": {
 "type": "array",
 "description": "Similar past incidents"
 }
 }
 },
 "recommendations": {
 "type": "array",
 "items": {
 "type": "object",
 "properties": {
 "action": {
 "type": "string"
 },
 "confidence": {
 "type": "number"
 },
 "reasoning": {
 "type": "string"
 }
 }
 },
 "description": "AI-generated resolution recommendations"
 },
 "summary": {
 "type": "string",
 "description": "Natural language summary of the enriched incident"
 }
 }
 }
 },
 "source": {
 "agent_code_url": "https://github.com/kyndryl-agentic-ai/bdg-sw-agents-incident-enrichment",
 "branch": "main",
 "manifest_path": "."
 },
 "is_latest": true,
 "is_published": false,
 "canCreateDeployment": false
}

Save as File

Save this JSON to your project for easy upload

Step 5: Field configuration details

Flow Configuration

The flow section defines how your agent container runs:

"flow": {
 "name": "incident-enrichment",
 "description": "Multi-step workflow for incident analysis and enrichment",
 "steps": [
 {      "name": "inc-enrich-step",
 "image": "kyndryl.jfrog.io/kyn-cto-kaif-docker-local/bdg-sw-agents-incident-enrichment:release-2026.03.27-abc1234-1774333268",
 "command": ["python3 main.py"],
 "resources": {
 "cpu": "900m",      // 0.9 CPU cores
 "memory": "2Gi"     // 2 GB RAM
 	}
   }
  ]
}

Constraints: - Step name: Maximum 18 characters (e.g., inc-enrich-step ✅, incident-enrichment-step ❌) - Image tag: Must use the release- prefix (e.g., release-2026.03.27-abc1234-1774333268 ✅, main-abc1234-... ❌) - Resources: Optional — if omitted, the platform applies default resource limits. Add only if your agent needs specific CPU/memory allocations.

Bridge_dev-only Image Pattern (Important)

You can register with a bridge_dev testing image such as: kyndryl.jfrog.io/kyn-cto-kaif-docker-local/under-development-for-bridge-dev-test:release-2026.03.27-abc1234-1774333268

Use this pattern only for bridge_dev validation.

For bridge_dev testing, first complete: 1. Catalog registration (POST /kaif/v3/agent-catalog/agents), and 2. Deployment registration (POST /kaif/v3/deployment/agentic).

Then execute your bridge_dev tests against that deployment.

After testing is complete, do a proper release cut and switch to the released image tag/repository for ongoing deployments by either:

Updating the existing catalog registration (PATCH/PUT) with the new released image tag, or

Creating a new registration version and deploying that version.

Then create a fresh deployment so runtime points to the released image.

Skills Configuration

Skills describe what your agent can do. These appear in the UI and help users understand capabilities:

"skills": [
 {
 "name": "Incident Retrieval",
 "description": "Retrieves incident details from ServiceNow using ticket ID"
 },
 {
 "name": "Asset Lookup",
 "description": "Looks up related CI/asset information from Bridge Data platform"
 }
]

Use clear, action-oriented names - Keep descriptions concise (< 100 characters) - Map skills to your workflow nodes - Include all capabilities users should know about

Tools Configuration

The tools section declares MCP tools your agent requires. First, discover available tools using the MCP Tools Discovery script:

Discover available MCP tools on your Bridge instance: python scripts/list_mcp_tools.py

Export in catalog format: python scripts/list_mcp_tools.py --format catalog --output available-tools.json

Then configure only the tools your agent needs.

For MCP tools, use the minimal valid object by default (name + type + operations):

"tools": [
 {
 "name": "servicenow_mcp",
 "type": "mcp",
 "operations": [
 "servicenow_search_incidents",
 "servicenow_create_incident"
 ]
 },
 {
 "name": "bridge_mcp",
 "type": "mcp",
 "operations": [
 "bridge_execute_query",
 "bridge_get_table_details"
	]
    }
]

Use extended optional fields (description, endpoint, auth_required) only when your platform workflow explicitly requires them.

Connector type tools

(e.g., ChatOps, Elasticsearch) use "type": "connector" with empty operations: []. They represent platform-managed integrations where the credentials are injected via the Connection Manager:

Tool names must match MCP server names exactly - type is required and must be valid (for MCP entries use "mcp") - Operations must use underscores (not hyphens) - Only list operations your agent actually uses (least privilege) - Run the discovery script to see available tools on your instance - This affects permission requests during deployment

Schema-driven validation (registry truth): Agent registration payloads are validated against registry Pydantic models and enums. If type is missing or an operation is not allowed for the selected tool name, registration is rejected.

Knowledge Bases Configuration

If your agent uses RAG capabilities:

"knowledge_bases": [
 {
 "name": "incident-runbooks",
 "description": "Knowledge base containing incident resolution runbooks",
 "type": "global"        // Available to all accounts
 },
 {
 "name": "infrastructure-docs",
 "description": "Infrastructure documentation",
 "type": "account"       // Account-specific
  }
]

Knowledge Base Integration (Registration + SDK Runtime)

If you declare knowledge_bases in catalog registration, integrate retrieval in code using KBSearchService.

SDK-aligned usage pattern:

import logging
from bridge_agent_sdk import KBSearchService

logger = logging.getLogger(__name__)

async def node_search_kb(self, state: dict) -> dict:
 # state must contain platform_context (agent_payload)
 kb = KBSearchService(logger, state)

 

 # KBSearchService.search is sync and accepts (query, k)
 articles = kb.search(
 query=state.get("short_description", ""),
 k=5,
 )

 return {**state, "kb_articles": articles}

LLM Configuration

Specify the LLM provider and model(s) your agent uses:

"llm": [
 {
 "provider": "hostedllm",
 "model": ["gpt-4.1"]
 }
]

Schemas Configuration

Define your agent's input/output contract:

"schemas": {   
"default": false,         // false = custom schema  
"input": { ... },         // JSON Schema for input 
"output": { ... }         // JSON Schema for output 
}

Schema Best Practices: - Use "additionalProperties": false for strict validation - Include "description" for all properties - Set appropriate "default" values - Mark required fields explicitly

Resource Guidelines (optional):

Agent Complexity	CPU	Memory
Simple (single tool)	500m	1Gi
Medium (2-3 tools)	900m	2Gi
Complex (workflow)	1500m	4Gi
Heavy (RAG + multiple MCPs)	2000m	8Gi

Tool Entry Fields:

Field	Type	Required	Description
name	string	Yes	MCP server name or connector name (e.g., bridge_mcp, servicenow_mcp)
type	string	Yes	"mcp" for MCP tool servers, "connector" for platform connectors (e.g., ChatOps, Elasticsearch)
description	string	No	Optional description (set to null if not needed)
operations	array	Yes (for mcp)	List of tool operation names. Empty [] for connectors
endpoint	string	No	Custom endpoint override (set to null for platform-managed)
auth_required	boolean	No	Whether the tool requires explicit auth (false = platform handles auth)

Runtime notes (important):

local_dev: KB search returns an empty list by design (no Bridge KB backend).

bridge_dev / production: endpoint resolves from KAIF_HOST; auth is handled via SDK token flow.

state should include platform_context.account_id and platform_context.instance_name for correct scoping.

Providers:

Provider	Description	Example Models
hostedllm	Self-hosted / bring-your-own LLM	bring_your_own

💡 Tip: Check the Bridge Platform Admin Console UI for the latest list of supported providers and models — the platform team adds new models regularly.

Step 6: Keeping agent in draft status

Draft Status Benefits

Testing: Deploy to test environments without affecting production

Review: Team can review configuration before publishing

Iteration: Make changes without versioning concerns

Validation: Platform validates configuration before publish

When registering, ensure these flags are set to keep the agent as a draft:

{
 "is_latest": true,
 "is_published": false,
 "canCreateDeployment": false
}

Flag	Draft Value	Production Value
is_latest	true	true
is_published	false	true
canCreateDeployment	false	true

Step 7: Validation checklist

Before uploading your registration JSON, verify:

Required Fields

[ ] name - Unique, lowercase, alphanumeric with hyphens

[ ] description - Clear, concise explanation

[ ] agent_type - Valid type (agentic_solution, chatops, workflow)

[ ] flow.steps[].image - Valid, accessible container image

[ ] flow.steps[].resources - Appropriate CPU/memory

[ ] schemas.input - Valid JSON Schema

[ ] llm[].model - Supported model names

Optional but Recommended

[ ] metadata.tags - Relevant search tags

[ ] metadata.owner_team - Team ownership

[ ] skills - At least one skill defined

[ ] tools - All required MCP tools listed

[ ] source.url - Source repository link

Common Validation Errors

Error	Cause	Solution
Image ... is invalid. Image must be hosted on kyndryl.jfrog.io and tagged with a release tag	Image tag uses main- or other prefix instead of release-	Change tag to release-YYYY.MM.DD-<sha>-<ts> format
Step name '...' is N chars — max is 18	Step name exceeds 18-character limit	Shorten the step name (e.g., inc-enrich-step)
Invalid image reference	Image not in JFrog	Push image to kyndryl.jfrog.io first
Unknown tool operation	Typo in operation name	Run MCP discovery script to get exact names
Schema validation failed	Invalid JSON Schema	Validate with jsonschema
Duplicate agent name	Name already exists	Use a unique name — the API appends a hash suffix automatically

Step 8: Create a deployment

After registering the agent in the catalog, the next step is to create a deployment. A deployment binds your registered agent to a specific environment with its tool connections, LLM configuration, and access groups.

Deployment API endpoint

POST /kaif/v3/deployment/agentic

Host: Use KAIF_HOST (for example, https://dev1-aws-oregon-base.bridge.kyndryl.com)

Authentication is the same as catalog registration — use a Bearer token from the Bridge Access Management endpoint.

Deployment payload structure

Field	Type	Required	Description
agent_catalog_id	string	Yes	The catalog ID returned from registration
agent_service_id	array	Yes	Service ID(s) for the agent runtime
deployment_name	string	Yes	Unique name for this deployment
application	string	Yes	Application context (e.g., "KAIF")
displayname	string	Yes	Human-readable name shown in UI
description	string	Yes	Deployment description
type	string	Yes	Agent type: "customagent"
status	string	Yes	"active" or "draft"
profiles	array	Yes	Connection profiles (tools, LLM, KB)
timeout	integer	Yes	Execution timeout in seconds
starter_message	string	No	Default greeting message
starter_questions	array	No	Suggested starter prompts
flags	object	No	Feature flags

Key configuration notes

Profiles → Tools & the connection Field

The profiles[].tools section maps MCP tool providers to their operations. Each entry has a connection field that references a named connection from the Bridge Connection Manager:

"tools": {
 "<provider_name>": {
 "connection": "<connection_name>",
 "mcp_tools": [
 "<provider_name>::<operation_name>"
 	]
   }
}

Tool references use the provider::operation format with double colons.

Understanding the connection field

The "connection" value (e.g., "servicenow_mcp", "bridge_mcp") is not a URL or credential — it is a logical name that points to a connection configured in the Bridge Connection Manager.

How it works at runtime:

When your agent makes an MCP call (e.g., servicenow_search_incidents), the SDK looks up the connection name from the deployment profile

The platform resolves that name to a connection record in the Connection Manager - which holds the credentials, endpoint URL, and access policies for the target account

The credentials are injected into the MCP request automatically - your agent code never sees or handles raw credentials

Setting up connections in Bridge Connection Manager

Connections are created by your Bridge Platform Admin in the admin UI.

Steps:

Navigate to Bridge Admin Console → Connections Manager

Click Create Connection

Fill in the connection details:

Field	Example	Description
Name	bridge_mcp	Logical name — must exactly match the "connection" value in your deployment JSON
Type	mcp	Connection type (mcp, llm, cloudProvider, etc.)
Provider	bridge_mcp	The backend provider
Credentials	(managed by UI)	API keys, tokens, service accounts — stored securely by the platform

Save → note the Connection ID (e.g., 69ae501f8a52a9dfa40a3f7a)

Use that Connection ID in connection_details[] in your deployment JSON

Note: The connection name you set here is what gets referenced in your deployment-registration.json. When the agent runs, the platform pulls the credentials from this connection record and injects them into MCP / LLM requests automatically — your agent code never handles raw credentials.

Common Connection Names

These are the standard connection names used across Bridge agents:

Connection Name	Type	Provider	Purpose
bridge_mcp	mcp	bridge_mcp	Bridge Data Platform — SQL queries, domain/table listing
servicenow_mcp	mcp	servicenow_mcp	ServiceNow ITSM — incident search, create
openai-connection	llm	openai	Azure OpenAI — LLM chat completions
dynatrace_mcp	mcp	dynatrace_mcp	Dynatrace monitoring — metrics, problems
azure_mcp	mcp	azure_mcp	Azure cloud operations

The connection name in "tools" → "connection" must exactly match a connection configured in the Connection Manager for your account. If it doesn't match, MCP calls will fail with 403 — Agent instance not found.

Profiles → Connection Details

The connection_details array defines the actual connections the agent will use at runtime. Each entry references a connection from the Connection Manager by its connection_id:

"connection_details": [
 {
 "type": "llm",
 "provider": "openai",
 "name": "openai-connection",
 "connection_id": "69af9c4b8a52a9dfa40a3f8f",
 "model": ["gpt-4.1"],
 "policy": {}
 },
 {
 "type": "mcp",
 "provider": "bridge_mcp",
 "name": "bridge_mcp",
 "connection_id": "69ae501f8a52a9dfa40a3f7a",
 "tools": ["bridge_execute_query", "bridge_list_tables"],
 "policy": {}
 }
]

connection_id — The unique ID of the connection record in the Connection Manager. Get this from your admin or the Connections page in the admin UI.

name — Must match the connection name used in tools → connection and in connections block.

LLM connection: Links to the LLM provider (OpenAI, etc.) with model selection — the platform injects the API key and endpoint at runtime

MCP connection: Links to the Bridge MCP server — the platform injects auth tokens and routes requests through the MCP gateway

These connection IDs are provisioned in the Bridge Admin UI under Connections. Your agent code never needs to know the underlying credentials — the platform handles credential injection automatically based on the connection name.

Successful Response

{
 "message": "Instance deployed successfully",
 "$KAIF_HOST/api/iam/v4/identity/token" \
}

Programmatic Deployment Script

"$KAIF_HOST/kaif/v3/agenticsolution/execution-context/<deployment-name>" \
# Ensure .env has KAIF_HOST, SERVICE_API_KEY, and BRIDGE_ACCOUNT_ID
# Ensure deployment-registration.json exists with the correct agent_catalog_id
python scripts/deploy_agent.py

Two-step registration summary

Step	API Endpoint	Payload File	What It Does
1. Catalog	POST /kaif/v3/agent-catalog/agents	agent-catalog-registration.json	Registers agent definition (skills, tools, schemas)
2. Deployment	POST /kaif/v3/deployment/agentic	deployment-registration.json	Creates a runnable deployment with connections and profiles

Step 9: Post-Deployment steps

After successful deployment:

Verify Deployment

# Check in Bridge Admin UI

# Deployments → Search for your deployment name

Update EXECUTION_CONTEXT for bridge_dev Testing

After deployment, you can get a real execution context from the platform to test locally. This is the recommended approach because it includes real connection details and credentials.

Fetch from the Platform

# Get Bridge Access Management token
TOKEN=$(curl -s -X POST \
 "$KAIF_HOST/api/iam/v4/identity/token" \
 -H "Content-Type: application/json" \
 -d '{"apikey": "'"$SERVICE_API_KEY"'"}' | jq -r '.token')

# Fetch the execution context for your deployment
curl -X POST \
 "$KAIF_HOST/kaif/v3/agenticsolution/execution-context/<deployment-name>" \
 -H "Authorization: Bearer $TOKEN" \
 -H "Content-Type: application/json" \
 -d '{"content": "test query", "parameters": {"accountCode": "BAC000ACME"}}' \
 -o test_exec_ctx.json

# Run locally
KAIF_MODE=bridge_dev python main.py \
 --agent_name my_agent \
 --execution_context "$(cat test_exec_ctx.json)"

Security: The response contains live credentials. Add test_exec_ctx.json to .gitignore.

Update Manually

If you prefer to update your existing test_exec_ctx.json by hand, ensure these fields match your deployment:

system_data.metadata.deployment_name → your deployment name

system_data.metadata.agent_catalog_id → your catalog ID

system_data.connection_details → connection details from your deployment profile

Run Integration Tests

Use bridge_dev mode locally pointing to the deployment

Validate all MCP tools work correctly

Test error handling scenarios

Request Review

Submit for team review

Document any special configuration requirements

Update runbooks with deployment instructions

Publish (When Ready)

Update is_published: true

Update canCreateDeployment: true

Create production deployment

Updating an existing registration

You can update your catalog registration at any time — for example, to change the Docker image tag after a new release, update tool lists, or modify schemas.

If your current registration uses under-development-for-bridge-dev-test, treat it as bridge_dev-only. After release cut, update to the released image (or create a new registration version) before non-bridge_dev usage.

API Methods

Method	Endpoint	Purpose
PUT	/kaif/v3/agent-catalog/agents/	Full replacement — send the entire updated JSON
PATCH	/kaif/v3/agent-catalog/agents/	Partial update — send only the fields to change

After updating the catalog, create a fresh deployment via /kaif/v3/deployment/agentic so the platform runs the updated image.

Using the UI

All catalog and deployment operations (create, update, delete) can also be done through the Bridge Platform Admin Console UI:

Navigate to Catalog → Agents → find your agent

Click Edit to update any field (image, tools, schemas, LLM models, etc.)

Save changes

The UI also allows you to: - Browse available LLM models when configuring the llm section - Create and manage deployments visually - View agent execution history and logs

LLM Models

The available LLM models can be browsed in the Bridge Platform Admin Console UI when configuring the llm section of your agent registration. The UI shows all models currently available on the platform.

In the registration JSON, specify the provider and model(s) your agent uses:

"llm": [
 {"provider": "openai", "model": ["gpt-4.1"]}
]

Check the UI for the latest list of supported models — the platform team adds new models regularly.

Triggering your agent in production

Once deployed, your agent can be triggered in two ways:

1. Via API

Call the agent execution endpoint with a payload that strictly matches the input schema you defined during catalog registration:

POST /kaif/v3/agenticsolution/

The payload must conform to the input schema registered in the catalog. If the schema has required fields, they must be present — otherwise the platform will reject the request.

2. Via the Bridge UI

Users can trigger agents directly from the Bridge Platform UI by selecting the agent, filling in the input form (auto-generated from your input schema), and clicking Run.