Agents y Registry

El módulo Agents es el hogar del ciclo de vida de cada agente de IA que usted gobierna con KLA Control Plane, la capa de seguridad, auditoría y gobernanza en tiempo de ejecución con la que instrumenta sus agentes existentes en lugar de migrarlos a otra plataforma. Combina un Agent Registry (el inventario de cada agente, su responsable y sus versiones) con una canalización de distribución gobernada: redacte un cambio, valídelo, publique un Release inmutable, despliéguelo y reviértalo si es necesario. Agents cubre todo el recorrido, desde "este agente existe" hasta "esta versión exacta está ejecutándose en producción".

Quién lo usa

• Los desarrolladores e integradores registran agentes, definen sus manifiestos, ejecutan Simulations y distribuyen Releases con el mismo flujo que usan para el código.
• Los operadores de plataforma gestionan los Rollouts entre entornos, controlan las promociones y activan un Rollback en cuanto el comportamiento se degrada.
• Los responsables de cumplimiento y de riesgo se apoyan en el Agent Registry como la respuesta autorizada a "qué agentes existen, quién es su responsable, qué pueden hacer y qué cambió". Cada Release tiene versión y es atribuible.

Capacidades clave

• Agent Registry. Busque y filtre cada agente registrado por modelo, equipo responsable, estado del release o hash del manifiesto. Cada entrada incluye la titularidad, el Release activo y el historial completo de versiones.
• Releases. Un Release es una instantánea inmutable y versionada de la configuración de un agente: modelo, instrucciones del sistema, parámetros y vínculos con herramientas. Los Releases nunca cambian tras su publicación; un nuevo cambio siempre genera un nuevo Release con un nuevo hash. Esto es lo que convierte "qué estaba en ejecución en esa fecha" en una pregunta precisa y demostrable.
• Rollouts y Rollback. Un Rollout promueve un Release a un entorno de destino. Un Rollback devuelve al instante el entorno a un Release publicado anteriormente. Ambas son acciones de primer nivel y auditadas, sin edición en caliente de la configuración en vivo.
• Simulations. Antes de publicar, ejecute una Simulation en un entorno aislado: reproduzca prompts representativos contra el Release candidato e inspeccione las salidas, las llamadas a herramientas, el coste y las decisiones de política que cada acción activaría, todo sin ningún efecto sobre producción.
• Aplicación de los vínculos con herramientas. Cada agente declara las herramientas que puede invocar. En tiempo de ejecución, KLA aplica esos vínculos contra el Tool Catalog (el inventario gobernado de herramientas aprobadas y sus permisos). Si un agente intenta usar una herramienta que no está vinculada en su Release activo, la acción se bloquea: ejecución de mínimo privilegio por defecto.

Manifiesto del agente

Los agentes se definen de forma declarativa como manifiestos JSON. Al publicarse, un nuevo manifiesto genera un nuevo Release con un nuevo hash.

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

El array tools es el conjunto de vínculos. En tiempo de ejecución, KLA verifica cada llamada a una herramienta contra el Tool Catalog y este conjunto declarado; una llamada a cualquier herramienta no declarada se rechaza antes de que se ejecute.

Ciclo de vida del Release

flowchart LR
  A["Redactar cambio"] --> B{"Validar"}
  B -->|falla| A
  B -->|pasa| C["Publicar Release"]
  C --> D["Rollout al entorno"]
  D --> E{"¿Saludable?"}
  E -->|sí| F["Release activo"]
  E -->|no| G["Rollback"]
  G --> F

Cómo se conecta

Agents se sitúa en el centro de los cuatro pilares, Govern, Operate, Assure, Prove:

• Policy Builder redacta las políticas que se evalúan contra cada acción del agente. Ejecute esas políticas contra un Release candidato en una Simulation antes de publicar.
• Decision Desk recibe una Escalation siempre que una acción gobernada devuelve una decisión require_approval, lo que pausa la ejecución hasta que un revisor decide.
• Lineage Explorer registra cada acción como un Lineage Record, cada uno sellado con el hash exacto del Release que lo produjo, de modo que una traza siempre se vincula a una configuración conocida e inmutable.
• Evidence Room sella ese linaje en un Sealed Evidence Bundle, lo que ofrece a los auditores una prueba criptográfica de qué Release se ejecutó, qué se le permitía hacer y qué hizo realmente.