Agents e Registry

Il modulo Agents è la sede del ciclo di vita di ogni agente AI che governi con il KLA Control Plane, ovvero il livello di sicurezza, audit e governance a runtime con cui aggiungi strumentazione ai tuoi agenti esistenti invece di rifarne la piattaforma da zero. Combina un Agent Registry (l'inventario di ogni agente, del suo proprietario e delle sue versioni) con una pipeline di distribuzione governata: prepara una modifica in bozza, validala, pubblica una Release immutabile, eseguine il rollout e, se necessario, il rollback. Agents copre l'intero percorso che va da "questo agente esiste" a "questa esatta versione è in esecuzione in produzione".

Chi lo usa

• Sviluppatori e integratori registrano gli agenti, definiscono i relativi manifest, eseguono le Simulation e distribuiscono le Release attraverso lo stesso flusso che usano per il codice.
• Operatori della piattaforma gestiscono i Rollout tra gli ambienti, controllano le promozioni e attivano un Rollback nel momento in cui il comportamento regredisce.
• Responsabili di compliance e rischio si affidano all'Agent Registry come risposta autorevole alla domanda "quali agenti esistono, chi li possiede, cosa possono fare e cosa è cambiato". Ogni Release è versionata e attribuibile.

Funzionalità principali

• Agent Registry. Cerca e filtra ogni agente registrato per modello, team proprietario, stato di release o hash del manifest. Ogni voce riporta la proprietà, la Release attiva e l'intera cronologia delle versioni.
• Releases. Una Release è uno snapshot immutabile e versionato della configurazione di un agente: modello, istruzioni di sistema, parametri e binding degli strumenti. Le Release non cambiano mai dopo la pubblicazione; una nuova modifica produce sempre una nuova Release con un nuovo hash. È questo che rende "cosa era in esecuzione in quella data" una domanda precisa e dimostrabile.
• Rollout e Rollback. Un Rollout promuove una Release verso un ambiente di destinazione. Un Rollback riporta istantaneamente l'ambiente a una Release pubblicata in precedenza. Entrambe sono azioni di prima classe e tracciate, senza alcuna modifica a caldo della configurazione attiva.
• Simulations. Prima della pubblicazione, esegui una Simulation in una sandbox: riproduci prompt rappresentativi sulla Release candidata e ispeziona output, chiamate agli strumenti, costi e le decisioni di policy che ogni azione attiverebbe, il tutto senza alcun impatto sulla produzione.
• Applicazione dei binding degli strumenti. Ogni agente dichiara gli strumenti che può richiamare. A runtime, KLA applica questi binding rispetto al Tool Catalog (l'inventario governato degli strumenti approvati e delle loro autorizzazioni). Se un agente tenta di usare uno strumento non vincolato nella sua Release attiva, l'azione viene bloccata: esecuzione con privilegio minimo per impostazione predefinita.

Agent Manifest

Gli agenti sono definiti in modo dichiarativo come manifest JSON. Un nuovo manifest produce, alla pubblicazione, una nuova Release con un nuovo hash.

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

L'array tools costituisce l'insieme dei binding. A runtime, KLA verifica ogni chiamata a uno strumento rispetto al Tool Catalog e a questo insieme dichiarato; una chiamata a qualsiasi strumento non dichiarato viene rifiutata prima della sua esecuzione.

Ciclo di vita della Release

flowchart LR
  A["Modifica in bozza"] --> B{"Valida"}
  B -->|fallisce| A
  B -->|supera| C["Pubblica Release"]
  C --> D["Rollout verso ambiente"]
  D --> E{"In salute?"}
  E -->|sì| F["Release attiva"]
  E -->|no| G["Rollback"]
  G --> F

Come si collega

Agents si trova al centro dei quattro pilastri, Govern, Operate, Assure, Prove:

• Policy Builder redige le policy valutate rispetto a ogni azione dell'agente. Esegui quelle policy su una Release candidata in una Simulation prima di pubblicare.
• Decision Desk riceve un'Escalation ogni volta che un'azione governata restituisce una decisione require_approval, mettendo in pausa l'esecuzione finché un revisore non si pronuncia.
• Lineage Explorer registra ogni azione come un Lineage Record, ciascuno marcato con l'esatto hash della Release che lo ha prodotto, così che una traccia rimandi sempre a una configurazione nota e immutabile.
• Evidence Room sigilla quella lineage in un Sealed Evidence Bundle, fornendo agli auditor la prova crittografica di quale Release fosse in esecuzione, cosa le fosse consentito fare e cosa abbia effettivamente fatto.