Agents & Registry

The Agents module is the lifecycle home for every AI agent you govern with the KLA Control Plane, the runtime safety, audit, and governance layer you instrument your existing agents with instead of re-platforming. It pairs an Agent Registry (the inventory of every agent, its owner, and its versions) with a governed shipping pipeline: draft a change, validate it, publish an immutable Release, roll it out, and roll it back if needed. Agents covers the full arc from "this agent exists" to "this exact version is running in production."

Who Uses It

• Developers and integrators register agents, define their manifests, run Simulations, and ship Releases through the same flow they use for code.
• Platform operators manage Rollouts across environments, gate promotions, and trigger a Rollback the moment behavior regresses.
• Compliance and risk officers rely on the Agent Registry as the authoritative answer to "which agents exist, who owns them, what can they do, and what changed." Every Release is versioned and attributable.

Key Capabilities

• Agent Registry. Search and filter every registered agent by model, owning team, release state, or manifest hash. Each entry carries ownership, the active Release, and full version history.
• Releases. A Release is an immutable, versioned snapshot of an agent's configuration: model, system instructions, parameters, and tool bindings. Releases never change after publish; a new change always produces a new Release with a new hash. This is what makes "what was running on that date" a precise, provable question.
• Rollouts and Rollback. A Rollout promotes a Release to a target environment. A Rollback instantly returns the environment to a previously published Release. Both are first-class, audited actions, with no hot-editing of live config.
• Simulations. Before publishing, run a Simulation in a sandbox: replay representative prompts against the candidate Release and inspect outputs, tool calls, cost, and the policy decisions each action would trigger, all with zero effect on production.
• Tool-binding enforcement. Every agent declares the tools it may call. At runtime, KLA enforces those bindings against the Tool Catalog (the governed inventory of approved tools and their permissions). If an agent attempts a tool that is not bound in its active Release, the action is blocked: least-privilege execution by default.

Agent Manifest

Agents are defined declaratively as JSON manifests. A new manifest produces a new Release with a new hash on publish.

{
  "id": "agt_9f81a7",
  "name": "support-classifier",
  "model": "gpt-4o",
  "temperature": 0.0,
  "tools": ["escalate_ticket", "read_knowledge_base"],
  "env": "production"
}

The tools array is the binding set. At runtime, KLA verifies every tool call against the Tool Catalog and this declared set; a call to any undeclared tool is rejected before it executes.

Release Lifecycle

flowchart LR
  A["Draft change"] --> B{"Validate"}
  B -->|fails| A
  B -->|passes| C["Publish Release"]
  C --> D["Rollout to env"]
  D --> E{"Healthy?"}
  E -->|yes| F["Active Release"]
  E -->|no| G["Rollback"]
  G --> F

How It Connects

Agents sits at the center of the four pillars, Govern, Operate, Assure, Prove:

• Policy Builder authors the policies evaluated against each agent action. Run those policies against a candidate Release in a Simulation before you publish.
• Decision Desk receives an Escalation whenever a governed action returns a require_approval decision, pausing execution until a reviewer rules.
• Lineage Explorer records every action as a Lineage Record, each one stamped with the exact Release hash that produced it, so a trace always ties back to a known, immutable configuration.
• Evidence Room seals that lineage into a Sealed Evidence Bundle, giving auditors cryptographic proof of which Release ran, what it was allowed to do, and what it actually did.