KM4BI KM4BI

Un agente Cursor ha cancellato un database in 9 secondi. L’analytics degli agenti l’avrebbe previsto.

Il caso Pocket OS mostra perché i prodotti agentici devono misurare i run, le correzioni e la fiducia dell’utente, non solo sessioni e messaggi.

Il caso Pocket OS è un avvertimento: se un agente può eliminare in pochi secondi un database di produzione e i backup, il problema non è solo tecnico. È anche un fallimento di analytics di prodotto, perché manca una vista del run prima del momento pericoloso.

Con gli agenti cambia ciò che va misurato

Le analytics tradizionali misurano sessioni, clic, messaggi, funnel e conversioni. In un prodotto agentico, l’evento decisivo può essere un’istruzione, una chiamata a uno strumento, una richiesta di approvazione, un retry, un limite di permesso o una correzione umana. Il comportamento diventa lavoro delegato.

I log delle chat aiutano, ma non bastano. Spesso non mostrano quali strumenti erano disponibili, quali chiamate sono fallite, dove i permessi hanno bloccato il processo, se l’utente ha corretto l’output o se il risultato finale è stato accettato.

Il run dell’agente è la nuova unità prodotto

La lente giusta è il run: quale compito era stato avviato, a quale workflow apparteneva, quali strumenti sono stati usati, cosa è fallito, se sono state chieste approvazioni, se il task è stato completato e se l’utente si è fidato del risultato.

Questo non coincide con la sola osservabilità ingegneristica. Una trace può dire che è stata richiesta un’approvazione o che un run è costato trenta centesimi. L’analytics di prodotto deve dire se quell’approvazione ha aumentato la sicurezza o solo aggiunto attrito, e se il run ha creato valore.

Le correzioni sono segnali di prodotto

Quando un utente interrompe un agente, modifica un output, nega un’approvazione, chiarisce una consegna o riapre un task, sta etichettando il run. Questi segnali rivelano contesto mancante, azioni percepite come rischiose, bassa fiducia o workflow mal progettati.

Un punto di partenza pratico: tre eventi — inizio del run, completamento del task e intervento/correzione dell’utente — collegati allo stesso run ID. Così si possono confrontare completamento, accettazione e correzioni per workflow.

In sintesi

Un prodotto agentico può mostrare molta attività e produrre comunque risultati pericolosi. Serve analytics di prodotto costruita sopra le trace di esecuzione per individuare run difettosi e segnali deboli prima che l’agente arrivi a un’azione distruttiva.

Source