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 overview 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 step 1 build and push container image before registration, your agent must be containerized and published to jfrog artifactory dockerfile example 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 stage ── from kyndryl jfrog io/kyn platform services team docker local/kaif pythoncompileimage\ latest \\ as compile image user root arg devops artifactory apikey arg devops artifactory user run python3 m venv /opt/venv env virtual env=/opt/venv env path="/opt/venv/bin $path" copy /requirements txt /tmp/requirements txt copy /pyinstall sh /tmp/pyinstall sh run chmod +x /tmp/pyinstall sh run /tmp/pyinstall sh $devops artifactory user $devops artifactory apikey /tmp/requirements txt copy /tmp/app/ \# ── runtime stage ── from kyndryl jfrog io/kyn platform services team docker local/kaif pythoncompileimage\ latest \\ as build image env tz=utc \\ virtual env=/opt/venv \\ path="/opt/venv/bin $path" \\ pythonpath=/app copy from=compile image /opt/venv /opt/venv copy from=compile image /tmp/app /app workdir /app cmd \["python3", "main py"] 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 $ /$ $ \# login to jfrog (use your credentials) docker login kyndryl jfrog io \# push the image docker push $ /$ $ \# note the full image path for registration echo "image $ /$ $ " 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 token endpoint post /api/iam/v4/identity/token request body { "apikey" "\<your service api key>" } the response contains a token field, use it as authorization bearer \<token> curl example \# step 1 get 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') \# step 2 register the agent curl x post \\ "$kaif host/kaif/v3/agent catalog/agents" \\ h "authorization bearer $token" \\ h "content type application/json" \\ h "accept application/json" \\ d @agent catalog registration json successful response { "status" "success", "message" "agent 'your agent name a1b2c3d4' created successfully", "agent catalog id" "your agent name a1b2c3d4" } important 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 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 example 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 \# create the registration file cat > agent catalog registration json << 'eof' { "name" "incident enrichment agent", (paste full json above) } eof 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 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 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" } ] best practices 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 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) 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 { "name" "chatops", "type" "connector", "description" null, "operations" \[], "endpoint" null, "auth required" false } important 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 } ] types global available across all accounts account specific to the deploying account 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} 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 when to set knowledge bases to empty if your agent does not perform rag/kb retrieval, keep "knowledge bases" \[] llm configuration specify the llm provider and model(s) your agent uses "llm" \[ { "provider" "hostedllm", "model" \["gpt 4 1"] } ] 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 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 step 6 keeping agent in draft status 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 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 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 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 example incident enrichment agent deployment { "agent catalog id" "\<your agent catalog id>", "agent service id" \[ "\<your agent service id>" ], "deployment name" "inc enrichment deploy v1", "application" "kaif", "displayname" "incident enrichment agent", "description" "ai agent that enriches incident tickets with contextual data from servicenow and bridge data platform", "type" "customagent", "status" "active", "access groups" \[ { "id" "grp platform ops", "name" "platform operations" } ], "version" "1 0 0", "starter message" "provide a servicenow incident id and i will enrich it with contextual data and ai powered resolution recommendations ", "starter questions" \[ "enrich incident inc0010001", "analyze incident inc0012345 with related changes", "get enrichment for a critical p1 incident" ], "default" false, "profiles" \[ { "name" "default", "kb instance name" \[], "access groups" \[ { "id" "grp platform ops", "name" "platform operations" } ], "tools" { "servicenow mcp" { "connection" "servicenow mcp", "mcp tools" \[ "servicenow mcp servicenow get all incidents", "servicenow mcp servicenow create incident", "servicenow mcp servicenow search incidents" ] }, "bridge mcp" { "connection" "bridge mcp", "mcp tools" \[ "bridge mcp bridge execute query", "bridge mcp bridge get table details", "bridge mcp bridge list tables", "bridge mcp bridge get domain details", "bridge mcp bridge list domains", "bridge mcp bridge list catalogs" ] } }, "connections" { "llm" "default", "kb connection" "default", "service api key" "\<service api key connection id>", "s3" "default" }, "connection details" \[ { "type" "llm", "provider" "openai", "name" "openai connection", "connection id" "\<your llm connection id>", "model" \["gpt 4 1"], "tools" null, "operation" null, "policy" {} }, { "type" "mcp", "provider" "bridge mcp", "name" "bridge mcp", "connection id" "\<your mcp connection id>", "model" null, "tools" \[ "bridge execute query", "bridge get table details", "bridge list tables", "bridge get domain details", "bridge list domains", "bridge list catalogs" ], "operation" null, "policy" {} } ] } ], "timeout" 1800, "notification" null, "flags" { "enable file upload" false, "enable session limit" false, "enable token" false } } 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>" ] } } note 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 ┌────────────────────────────────┐ │ deployment registration json │ │ │ │ "tools" { │ │ "servicenow mcp" { │ │ "connection" "servicenow mcp" ──────┐ │ "mcp tools" \[ ] │ │ │ }, │ │ │ "bridge mcp" { │ │ │ "connection" "bridge mcp" ──────┐ │ │ "mcp tools" \[ ] │ │ │ │ } │ │ │ │ } │ │ │ └────────────────────────────────┘ │ │ │ │ ▼ ▼ ┌──────────────────────────────────────────────────────────┐ │ bridge connection manager │ │ (admin ui → connections) │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ name "bridge mcp" │ ◄───────┘ │ │ type mcp │ │ │ provider bridge mcp │ │ │ connection id 69ae501f8a52a9dfa40a3f7a │ │ │ credentials (managed by platform) │ │ └─────────────────────────────────────────────┘ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ name "servicenow mcp" │ ◄─────── │ │ type mcp │ │ │ provider servicenow mcp │ │ │ connection id 69bae5725fa182d7fc3e0c94 │ │ │ credentials (managed by platform) │ │ └─────────────────────────────────────────────┘ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ name "openai connection" │ │ │ type llm │ │ │ provider openai │ │ │ connection id 69af9c4b8a52a9dfa40a3f8f │ │ │ model gpt 4 1 │ │ │ credentials (api key managed by platform) │ │ └─────────────────────────────────────────────┘ └──────────────────────────────────────────────────────────┘ 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 📖 official guide kaif onboarding enablement — configure connections manager https //kyndryl sharepoint com/sites/knowledge ai foundation/sitepages/kaif onboarding enablement aspx#3 configure connections manager 🎥 kindly refer to the video walkthrough on the enablement page above — it demonstrates end to end how to create and configure connections in the connection manager 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 important 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 curl example \# step 1 get token (same as catalog registration) 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') \# step 2 create the deployment curl x post \\ "$kaif host/kaif/v3/deployment/agentic" \\ h "authorization bearer $token" \\ h "content type application/json" \\ h "accept application/json" \\ d @deployment registration json 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 1\ verify deployment \# check in bridge admin ui \# deployments → search for your deployment name 2\ 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 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 or 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 3\ run integration tests use bridge dev mode locally pointing to the deployment validate all mcp tools work correctly test error handling scenarios 4\ request review submit for team review document any special configuration requirements update runbooks with deployment instructions 5\ publish (when ready) update is published true update cancreatedeployment true create production deployment quick reference registration json template { "name" "your agent name", "description" "your agent description", "agent type" "agentic solution", "flow" { "name" "your agent", "description" "flow description", "steps" \[{ "name" "your step", "image" "kyndryl jfrog io/kyn cto kaif docker local/your agent\ release yyyy mm dd sha ts", "command" \["python3 main py"], "resources" {"cpu" "900m", "memory" "2gi"} }] }, "metadata" { "tags" \["tag1", "tag2"], "owner team" "your team", "maintaining team" "" }, "skills" \[ {"name" "skill name", "description" "what it does"} ], "tools" \[ {"name" "mcp name", "type" "mcp", "description" null, "operations" \["op1", "op2"], "endpoint" null, "auth required" false} ], "knowledge bases" \[], "llm" \[{"provider" "openai", "model" \["gpt 4 1"]}], "schemas" { "default" false, "input" {"type" "object", "properties" {}, "required" \[]}, "output" {} }, "source" { "agent code url" "https //github com/org/repo", "branch" "main", "manifest path" " " }, "is latest" true, "is published" false, "cancreatedeployment" false } 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 example update image tag after a new release \# get the new image tag from your ci/cd build logs \# notice ✅ pushed kyndryl jfrog io/kyn cto kaif docker local/bdg sw agents your agent\ release 2026 03 27 5d45dd2 1774525017 \# patch just the image field curl x patch \\ "$kaif host/kaif/v3/agent catalog/agents/\<agent catalog id>" \\ h "authorization bearer $token" \\ h "content type application/json" \\ d '{ "flow" { "steps" \[{ "image" "kyndryl jfrog io/kyn cto kaif docker local/bdg sw agents your agent\ release 2026 03 27 5d45dd2 1774525017" }] } }' 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"]} ] tip 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/ curl x post \\ "$kaif host/kaif/v3/agenticsolution/\<deployment name>" \\ h "authorization bearer $token" \\ h "content type application/json" \\ d '{ "query" "enrich incident inc0012345", "parameters" {}, "input" { "data" { "incident id" "inc0012345" }, "channel" { "channelid" "c123456", "workspacename" "my workspace" } } }' note 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