Anthropic ha pubblicato il 18 agosto 2026 un resoconto sull'esperienza nell'utilizzo di Claude come primo rispondente durante incidenti CI/CD. L'azienda annuncia che i rapporti iniziali vengono generalmente prodotti in meno di quindici minuti. Al di là dei numeri, il caso è interessante perché descrive un'architettura riproducibile: accesso in sola lettura, strumenti controllati, memoria versionata e validazione umana prima di qualsiasi modifica.
1. Ciò che afferma il ritorno di esperienza
Anthropic descrive un agente chiamato Claude Tag utilizzato come primo risponditore per gli incidenti legati all’integrazione e al deployment continui. Secondo i dati interni pubblicati, l’agente ha prodotto il primo rapporto di situazione in ogni incidente recente che ne possedeva uno, generalmente entro quindici minuti. La mediana annunciata per un’analisi basata su prove è di quattordici minuti e, nei casi più rapidi, una causa principale è stata identificata in quattro minuti.
Questi risultati provengono dall'ambiente di Anthropic e non costituiscono un benchmark indipendente. Mostrano comunque che parte del lavoro iniziale di reperibilità può essere strutturata: raccogliere i segnali, formulare ipotesi, citare gli elementi osservati e preparare una trasmissione.
2. Il ruolo giusto per un agente di reperibilità
Il primo obiettivo non è sostituire l’ingegnere reperibile. È ridurre il tempo perso ad aprire più strumenti, confrontare gli orari e ricostruire il contesto di un cambiamento.
Un agente ben progettato può recuperare gli avvisi, i recenti deployment, gli errori, i log e le discussioni associate. Può quindi proporre una cronologia, i servizi interessati, le ipotesi e le verifiche successive. L'essere umano mantiene la decisione, soprattutto quando un'azione può aggravare l'incidente.
Questa ripartizione è coerente con il principio di validazione umana dei sistemi IA : automatizzare la raccolta e la sintesi, ma mantenere una chiara responsabilità sugli atti ad alto impatto.
3. Un'architettura in due tempi
Il modello descritto separa il lancio deterministico dall’indagine agentiva. Gli avvisi e le regole classiche rilevano uno stato noto: fallimento della pipeline, tasso di errore, ritardo o saturazione. Successivamente avviano l’agente con un perimetro e un identificativo dell’incidente.
Un orchestratore può delegare più tracce a sotto-agenti: analizzare le metriche, esaminare le modifiche Git, leggere gli eventi Kubernetes o trovare incidenti simili. Ogni risultato deve mantenere i riferimenti che permettono all’ingegnere di verificarlo.
Questa separazione è essenziale. Il sistema di monitoraggio rimane responsabile della rilevazione e delle soglie. Il modello interviene nella ricerca, nell'interpretazione e nella comunicazione, là dove le regole rigide raggiungono i loro limiti.
4. Perché iniziare in sola lettura
Anthropic fornisce un kit di avvio che crea un ruolo iniziale in sola lettura. È l'approccio giusto per un primo dispiegamento. Un agente in grado di consultare le metriche e i registri porta già valore senza poter fermare un servizio o modificare una configurazione.
Il kit pubblico è presentato senza auto-rimedi: gli esseri umani decidono le azioni e le eseguono. Il sistema interno descritto da Anthropic comprende anche un agente distinto in grado di gestire implementazioni progressive dietro feature flag; questa capacità non deve essere confusa con l'ambito iniziale del kit.
I diritti devono essere attribuiti per strumento e per ambiente. Leggere gli eventi di un cluster di test non giustifica l'accesso ai segreti di produzione. Consultare una pull request non richiede il diritto di fonderla.
Ogni richiesta deve essere registrata con l'identità dell'agente, l'incidente, lo strumento, l'ambito e il risultato. Gli identificatori temporanei e i token a breve durata limitano l'impatto di una fuga.
5. L'accesso agli strumenti tramite MCP
Il resoconto delle esperienze menziona l'accesso a Datadog o Grafana, PagerDuty, GitHub, Kubernetes e Slack tramite MCP. Il protocollo facilita un'interfaccia comune, ma non costituisce di per sé un controllo di sicurezza.
Ogni server MCP deve esporre un sottoinsieme esplicito di azioni, convalidare i parametri e applicare i diritti lato servizio. Bisogna evitare strumenti generici del tipo “eseguire un comando arbitrario” o “fare una richiesta libera” quando una funzione più stretta è sufficiente.
Le risposte degli strumenti devono essere considerate come dati non affidabili. Un messaggio Slack o un nome di branch può contenere testo progettato per fuorviare l'agente. Il modello non deve mai trasformare un'istruzione trovata in una fonte in un'autorizzazione all'azione.
6. Memoria, istruzioni e apprendimento
Anthropic descrive una memoria alimentata da Slack, istruzioni permanenti in Markdown versionate in Git e un file di lezioni tratte dagli incidenti precedenti. Questa organizzazione è preferibile a un prompt opaco modificato in un'interfaccia.
Le istruzioni devono precisare l'ordine delle verifiche, le fonti affidabili, il formato del rapporto, le soglie di escalation e le azioni vietate. Qualsiasi modifica passa attraverso una revisione del codice e può essere collegata a un incidente specifico.
La memoria deve essere filtrata. Un postmortem contiene a volte segreti, dati personali o ipotesi diventate false. Conservate riassunti verificati e una data di scadenza piuttosto che un accesso illimitato a tutte le conversazioni storiche.
7. I paletti prima di un'azione
Quando un driver in sola lettura è controllato, possono essere proposte alcune azioni reversibili: aprire un ticket, preparare una pull request, rilanciare un job non distruttivo o generare un comando da convalidare.
La correzione descritta da Anthropic rimane revisionata, fusa e distribuita dall’ingegnere di turno. Questo confine deve essere esplicito nell’interfaccia. Un pulsante di conferma non è sufficiente se l’utente non comprende precisamente gli effetti.
Per un'azione automatica, richiedete almeno una politica deterministica, un ambito limitato, un registro firmato, un termine, una condizione di ritorno indietro e una prova di verifica dopo l'esecuzione.
8. Un piano di implementazione in quattro fasi
La fase 1 è offline: rigiocate gli incidenti chiusi e confrontate il rapporto dell’agente con il postmortem. La fase 2 è l’osservazione in tempo reale, senza notifica operativa. La fase 3 apre il rapporto alla reperibilità, sempre in sola lettura. La fase 4 autorizza alcune azioni preparatorie o reversibili.
A ogni fase, definite dei criteri di passaggio: tasso di citazioni corrette, assenza di accesso fuori dal perimetro, tempo di risposta, qualità delle ipotesi e carico di verifica umana.
Non passate direttamente alla correzione automatica. L’incidente è proprio il momento in cui il contesto è incompleto, i sistemi sono degradati e gli errori costosi.
9. Gli indicatori da seguire
Misurate il tempo fino al primo rapporto utile, il tempo fino alla causa radice, la precisione dei fatti, il numero di ipotesi confutate e il tempo di revisione umana. Monitorate anche gli incidenti in cui l’agente non ha apportato alcun valore.
Un buon sistema deve ridurre il tempo di comprensione senza aumentare il rischio. Il tasso di “buona diagnosi” da solo è insufficiente: un'analisi corretta ma non documentata può essere impossibile da utilizzare sotto pressione.
L’esperienza pubblicata da Anthropic mostra una direzione credibile per l’outsourcing e il SRE. La sua trasposizione richiede tuttavia un’architettura di permessi, strumenti specifici e una progressione misurata.
Partitech può accompagnare l'implementazione di un assistente di reperibilità: integrazione con gli strumenti, ruoli in sola lettura, sessioni di replay, cruscotti, validazione umana e procedura di rollback.