Un assistente aziendale può partire da una richiesta semplice e ritrovarsi, dopo molte interazioni, con preventivi, correzioni, risultati di ricerca e decisioni provvisorie nella stessa conversazione. Il problema non è soltanto quanto testo riesca a leggere: è capire quali informazioni debbano restare disponibili quando il lavoro prosegue. Per una PMI, perdere un vincolo di consegna o confondere una proposta con una decisione approvata può rendere inutile anche una risposta scritta bene.
Il 14 settembre 2026 Anthropic ha annunciato una nuova modalità di compattazione delle conversazioni su richiesta nella Claude API. È una novità per chi sviluppa applicazioni e agenti, non l’annuncio di una memoria permanente per ogni chat. Offre però uno spunto concreto: progettare meglio il passaggio di consegne fra le diverse fasi di un’attività automatizzata.
La novità: scegliere quando compattare la conversazione
Secondo le note di rilascio ufficiali di Anthropic del 14 settembre, la Messages API permette ora di richiedere una sintesi usando il parametro compaction, con l’header beta compact-2026-09-04. La risposta contiene un blocco firmato da utilizzare nelle richieste successive al posto dei messaggi sintetizzati.
Lo sviluppatore decide il momento della compattazione. La richiesta può essere eseguita in background e gli scambi più recenti possono restare integrali dopo la sintesi. Questa distinzione conta: non si tratta semplicemente di attendere che una conversazione diventi troppo lunga, ma di introdurre un passaggio controllato nel flusso applicativo.
Contesto, archivio e stato del lavoro sono cose diverse
Il contesto è il materiale disponibile al modello per formulare la prossima risposta. Un archivio conserva documenti recuperabili; lo stato applicativo registra invece ciò che è accaduto davvero. In un progetto ben impostato queste tre funzioni collaborano, senza essere confuse. La frase «abbiamo preparato il preventivo» non equivale a un record che dimostra quale versione sia stata salvata, dove si trovi e chi l’abbia approvata.
Anthropic aveva già descritto il problema nel suo approfondimento sul context engineering, pubblicato nel settembre 2025: un contesto più ampio non elimina la necessità di selezionare informazioni pertinenti. Quel testo costituisce il quadro tecnico di riferimento, non una seconda novità di questa settimana.
La nostra lettura pratica è questa: la compattazione può alleggerire il materiale conversazionale, ma l’azienda deve continuare a conservare separatamente gli elementi che non possono dipendere dalla qualità di un riassunto. Identificativi, importi approvati, versioni dei file ed esiti delle operazioni devono avere una fonte verificabile.
Un esempio: dal colloquio commerciale al preventivo
Immaginiamo una piccola azienda di servizi che usa un assistente per preparare proposte commerciali. Nella prima fase raccoglie obiettivi, tempi, materiali disponibili e dubbi del cliente. Nella seconda confronta due soluzioni. Nella terza prepara una bozza di offerta. Sono esempi progettuali, non risultati misurati su un’installazione UHD.
Fra la seconda e la terza fase si potrebbe introdurre un riepilogo operativo: soluzione preferita, alternative scartate e relativo motivo, informazioni mancanti, documenti di riferimento e prossima azione consentita. L’ultimo messaggio del cliente, che corregge una scadenza, dovrebbe invece essere mantenuto integralmente o recuperato dalla fonte prima della stesura finale.
Il controllo decisivo non sarebbe «il riassunto sembra plausibile», ma «la proposta mantiene tutti i vincoli confermati?». Se un budget era indicativo, non deve diventare un tetto contrattuale; se una data era da verificare, non deve diventare una promessa. Prima dell’invio, la bozza andrebbe confrontata con i campi approvati nel gestionale.
Un secondo caso: manutenzione di un sito WordPress
Consideriamo ora un intervento tecnico con molte prove: errore riprodotto, log esaminati, ipotesi eliminate, modifica su staging e test di regressione. In una conversazione lunga il rumore può crescere rapidamente. Un riepilogo di transizione potrebbe mantenere l’ambiente interessato, il sintomo iniziale, la modifica candidata e i test ancora da eseguire.
Il repository e il sistema di ticketing dovrebbero però restare le fonti dello stato effettivo. «Correzione preparata» non significa «rilasciata in produzione»; «test proposto» non significa «test superato». Chi integra l’assistente dovrebbe prevedere verifiche separate per questi passaggi, usando riferimenti a commit, ticket e risultati registrati.
Questa applicazione è diversa dal far navigare un agente nel sito: riguarda la continuità del lavoro fra una fase e l’altra. Per il tema dell’interazione con WordPress rimane pertinente il nostro approfondimento su WebMCP e WordPress. Le due componenti possono convivere, ma risolvono problemi distinti.
Cosa deve contenere un buon passaggio di consegne
Prima di integrare la funzione, consigliamo di definire un modello di stato leggibile anche da una persona. Non serve una relazione lunga: serve una struttura che renda evidenti decisioni, prove e incertezze. Una proposta iniziale può includere questi campi:
- Obiettivo attuale: risultato richiesto e condizioni per considerarlo completato.
- Vincoli confermati: limiti operativi, ambiente di lavoro e azioni autorizzate.
- Decisioni: scelta, fonte della conferma e data; ipotesi tenute separate.
- Materiali: identificativi e percorsi dei documenti, con versione utilizzata.
- Operazioni concluse: esito osservato e riferimento che permette di verificarlo.
- Questioni aperte: dati mancanti, conflitti e controlli necessari prima di continuare.
Questo schema è una raccomandazione applicativa di UHD, non un formato obbligatorio della Claude API. Il suo vantaggio è rendere testabile il comportamento: se il riepilogo omette un’approvazione o cambia il significato di un’incertezza, il problema diventa riconoscibile.
Come valutare la funzione prima di usarla con i clienti
Il primo esperimento dovrebbe riguardare un solo processo, usando conversazioni di prova o materiali adeguatamente anonimizzati. Conviene scegliere casi con correzioni successive, informazioni contraddittorie e azioni già completate: sono situazioni nelle quali la perdita di un dettaglio produce un errore osservabile. Non basta dimostrare che il modello ricorda il tema generale.
Una possibile prova consiste nel preparare due esecuzioni dello stesso caso: una con la cronologia disponibile e una con un passaggio di compattazione. Si confrontano i risultati rispetto a un elenco di requisiti scritto prima del test. Le risposte vanno valutate per correttezza, non soltanto per somiglianza testuale.
Le misure utili comprendono vincoli mantenuti, errori introdotti, richieste di chiarimento corrette, azioni ripetute e tempo necessario a completare il lavoro. Va registrato anche il costo complessivo del processo. Ridurre il testo inviato in una fase non dimostra, da solo, che l’intera procedura costi meno o risponda più velocemente.
Prima del test fisserei inoltre una condizione di arresto: se il sistema non distingue un invio già effettuato da uno ancora da fare, non deve poter operare autonomamente su comunicazioni reali. L’eventuale guadagno di efficienza non compensa una seconda email inviata per errore o una modifica applicata due volte.
I dettagli tecnici e i limiti da non trascurare
La documentazione della compattazione distingue la modalità su richiesta da quella attivata al raggiungimento di una soglia. Nel flusso con blocco firmato, il blocco sostituisce i messaggi sintetizzati: reinserire quella cronologia prima del blocco produce un errore. È quindi un’integrazione da gestire nel codice, non una frase da aggiungere al prompt.
La documentazione segnala inoltre che la compattazione comporta elaborazione aggiuntiva e contribuisce a consumi e fatturazione. Modello, versione beta e modalità di conservazione degli ultimi scambi richiedono una verifica tecnica prima del rilascio. Non proponiamo percentuali di risparmio: in questo articolo non abbiamo eseguito benchmark né chiamate API a pagamento.
Un riassunto non deve neppure trasformarsi in una nuova fonte di autorità. Se un documento esterno contiene istruzioni estranee al compito, sintetizzarle non le rende autorizzate. Restano valide le regole di sicurezza degli agenti AI: permessi proporzionati, controlli sulle azioni e registri verificabili.
Un ulteriore accorgimento progettuale è conservare una versione dello stato prima e dopo ogni sintesi. Se un controllo fallisce, l’applicazione può interrompersi e recuperare il materiale precedente, anziché proseguire sulla base di informazioni dubbie. Il registro dovrebbe indicare quali messaggi sono stati sintetizzati e quali operazioni esterne risultano già concluse. La gestione dei tentativi deve restare indipendente dal testo generato: il sistema decide se un’azione sia già stata eseguita consultando i propri record, non chiedendo al modello di ricordarlo.
Quando conviene e quando basta un flusso più semplice
La funzione merita una valutazione quando un assistente sviluppato su misura affronta conversazioni lunghe, numerose consultazioni di strumenti e passaggi di fase riconoscibili. È meno prioritaria per classificare una singola richiesta, riscrivere un testo breve o compilare un report da pochi dati già strutturati. In quei casi introdurla può aggiungere complessità senza un beneficio dimostrabile.
Per una PMI suggeriamo quindi di partire dal processo, non dalla funzione: individuare dove si perde il filo, quali informazioni devono sopravvivere e chi verifica l’esito. Solo dopo ha senso scegliere come compattare. La novità di Anthropic offre più controllo sul momento della sintesi; la continuità affidabile del lavoro dipende ancora da come vengono progettati dati, verifiche e recupero degli errori.
In sintesi: meno cronologia non deve significare meno responsabilità. Un buon assistente deve poter riprendere il lavoro sapendo cosa è confermato, cosa resta incerto e dove trovare le prove, senza inventare una memoria che il sistema non possiede.
