Osservabilità degli agenti IA: vedere cosa fa un agente in tempo reale

Più un agente IA guadagna in autonomia, più la domanda «cosa ha fatto esattamente?» diventa centrale. Un agente che funziona in continuo, sollecitato da più canali, che chiama strumenti e a volte delega a sotto-agenti, produce un'attività difficile da seguire a occhio nudo. L'osservabilità è la risposta tecnica a questo problema: rendere visibile, tracciabile e comprensibile ciò che accade realmente all'interno del sistema.

Definizione dettagliata

L'osservabilità, nel senso ampio del termine in ingegneria del software, è la capacità di comprendere lo stato interno di un sistema esaminando ciò che produce verso l'esterno, tipicamente tracce, metriche e log. È la definizione adottata da OpenTelemetry, lo standard aperto di riferimento per la strumentazione software, sostenuto da numerosi fornitori di strumenti di osservabilità. Questi tre tipi di dati svolgono ruoli complementari: le tracce seguono una richiesta lungo il proprio percorso in un sistema distribuito, i log registrano eventi con timestamp associati o meno a una richiesta precisa, e le metriche aggregano misure numeriche nel tempo.

L'osservabilità degli agenti applica questo stesso principio al caso specifico di un agente IA autonomo. Non esiste ancora uno standard unico e ampiamente consolidato che definisca con precisione cosa debba coprire l'osservabilità agentica, a differenza dell'osservabilità software classica che beneficia di uno standard maturo come OpenTelemetry. Nella pratica, le piattaforme che fanno funzionare agenti convergono comunque verso esigenze comuni: sapere quale azione un agente ha eseguito, su quale strumento, in quale momento, con quale risultato, e su iniziativa di quale trigger (una conversazione, un'email, un'attività pianificata).

Non è un lusso tecnico riservato ai grandi team. Non appena un agente può agire senza convalida sistematica a ogni passaggio, l'osservabilità diventa il modo concreto di rispondere alla domanda «perché ha fatto questo?» a posteriori, o di individuare un comportamento anomalo prima che causi un vero problema.

Come funziona

Concretamente, l'osservabilità di un agente si basa su tre strati sovrapposti. Il primo è la cattura degli eventi: ogni decisione, ogni chiamata a uno strumento, ogni passaggio di ragionamento significativo viene registrato nel momento in cui si verifica, con un timestamp, uno stato (in corso, riuscito, in errore) e l'origine dell'attivazione. Il secondo è la strutturazione: questi eventi grezzi vengono categorizzati (un'azione su un file non viene registrata allo stesso modo di una chiamata a uno strumento esterno o di un passaggio di ragionamento del modello), per poter filtrare e cercare in modo efficace. Il terzo è la restituzione: un'interfaccia o un'esportazione che permette a una persona di scorrere questa attività, sia per un agente preciso sia per l'insieme di un'organizzazione.

Un buon sistema di osservabilità agentica distingue anche il lavoro delegato: quando un agente affida un sottocompito a un sotto-agente effimero, questa delega deve restare visibile nella cronologia del genitore, altrimenti una parte del lavoro reale diventa invisibile.

Esempio concreto con Atako

In Atako, l'osservabilità per agente si basa su una timeline di attività in tempo reale: ogni evento vi viene categorizzato (web, file, memoria, codice, integrazione, pianificazione, delega, ragionamento del modello, altro), con uno stato (in corso, riuscito, in errore), una durata, e un'origine precisa (chat, email, webhook, attività pianificata, messaggio tra agenti, sotto-agente, o sistema). Un pannello dedicato, «Tool logs», elenca separatamente ogni chiamata di integrazione effettuata dall'agente, con il proprio risultato (successo, rifiuto, errore).

Questa osservabilità per agente è completata da una vista a livello aziendale, riservata agli amministratori: una pagina di «Integration logs» filtrabile per team, agente, fornitore e data, con un'esportazione CSV fino a 50.000 righe, oltre a una vista aggregata di utilizzo per fornitore di integrazione. Ogni chiamata registrata conserva l'agente interessato, la connessione utilizzata, il fornitore, l'azione precisa, i suoi argomenti (con i campi sensibili come il corpo di un'email o una richiesta di ricerca sistematicamente oscurati), lo stato, il codice HTTP restituito dal fornitore, la latenza e il timestamp. I guardrail di permesso (i grant) e l'osservabilità lavorano mano nella mano: l'uno decide se un'azione è autorizzata, l'altro conserva la traccia di ciò che è realmente accaduto.

Errori frequenti

Un errore frequente consiste nel confondere osservabilità e semplice log di errori. Un sistema osservabile non si limita a segnalare quando qualcosa si rompe, dà anche visibilità sul funzionamento normale, il che permette di capire un comportamento inatteso anche quando nulla è tecnicamente fallito.

Secondo errore: pensare che l'osservabilità impedisca a un agente di agire male. Non è un meccanismo di blocco, è un meccanismo di visibilità. Si combina con i permessi e, per le azioni sensibili, con un punto di convalida umana, ma non sostituisce né l'uno né l'altro.

Terzo errore: riservare l'osservabilità agli amministratori senza renderla accessibile ai team che utilizzano realmente l'agente ogni giorno. Un'osservabilità utile deve permettere alla persona che ha creato o che utilizza un agente di comprenderne il comportamento, non solo a un ruolo tecnico isolato.

Infine, sottovalutare l'importanza delle deleghe a sotto-agenti nella cronologia di attività è un errore classico. Un agente che delega un sottocompito continua a essere responsabile del risultato agli occhi dell'utente: se questa delega non appare chiaramente nella timeline, una parte del lavoro reale diventa invisibile e incomprensibile a posteriori.