nome: deploy-production
descrizione: Verifica e distribuisci l'applicazione nell'ambiente di produzione.

Oltre i Prompt: L'approccio di Anthropic a Memoria, Sogni e Workflow Grafici per Agenti

1. Leggi checklist.md.
2. Esegui l'intera suite di test.
3. Conferma il piano di migrazione.
4. Esegui scripts/verify-release.sh.
5. Arresta il processo e richiedi l'approvazione umana prima della distribuzione.

Il meccanismo fondamentale è la **divulgazione progressiva**.

Claude vede una breve descrizione che lo aiuta a decidere se una competenza è pertinente. L'intero corpo della competenza e i file di supporto vengono caricati solo quando il processo è necessario.

Mukta ha paragonato questo a una libreria.

Una persona non ha bisogno di memorizzare ogni libro prima di iniziare una conversazione. Ha solo bisogno di sapere quale libro potrebbe contenere informazioni pertinenti e prenderlo al momento opportuno.

Le competenze aiutano a risolvere il problema del "file di contesto in continua crescita":

- I fatti stabili e di alto livello possono rimanere in `CLAUDE.md`.
- I processi dettagliati possono essere spostati nelle competenze.
- I materiali di supporto possono essere mantenuti al di fuori del contesto attivo finché non sono necessari.

La documentazione ufficiale delle competenze di Anthropic suggerisce di creare una competenza quando un team incolla ripetutamente le stesse istruzioni, liste di controllo o processi in più fasi nelle conversazioni, o quando una sezione di `CLAUDE.md` si è evoluta in un processo piuttosto che in un fatto conciso.

### Le competenze richiedono comunque una gestione umana

Le competenze sono riutilizzabili, ma qualcuno deve ancora decidere:

- Quali flussi di lavoro meritano di diventare competenze
- Come dovrebbe essere strutturato il processo
- Quali file dovrebbero essere inclusi
- Quando una competenza è obsoleta
- Chi ha il permesso di modificarla

Gli agenti possono aiutare a scrivere e mantenere le competenze, ma il sistema si basa ancora in parte sulla gestione umana.

Questo porta a un quarto approccio.

## Quarta generazione: trattare il file system come memoria

Mukta ha descritto la memoria basata su file system come il modello che Anthropic attualmente preferisce in molti sistemi di memoria per agenti.

La motivazione è molto pragmatica.

Gli agenti sono già competenti nel:

- Elencare file
- Cercare nomi di file
- Eseguire `grep`
- Leggere Markdown
- Sfogliare directory
- Modificare testo
- Confrontare versioni

Invece di inventare un'interfaccia di memoria altamente specializzata, i team possono organizzare la memoria come file e fornire agli agenti i normali strumenti del file system.

Una possibile struttura è la seguente:

```Plaintext
memoria/
├── organizzazione/
│   ├── principi.md
│   ├── terminologia.md
│   └── politica-di-sicurezza.md
├── team/
│   ├── ingegneria/
│   │   ├── architettura.md
│   │   └── processo-di-rilascio.md
│   └── supporto/
│       ├── regole-di-escrizione.md
│       └── stile-di-risposta.md
├── progetti/
│   └── ridisegno-fatturazione/
│       ├── decisioni.md
│       ├── problemi-noti.md
│       └── stato-attuale.md
└── agenti/
    └── agente-104/
        └── blocco-appunti.md

Questa struttura supporta diversi livelli di memoria:

• Regole a livello organizzativo
• Conoscenza del team
• Contesto del progetto
• Preferenze dell'utente
• Note di lavoro specifiche dell'agente

Riflette anche la divulgazione progressiva.

L'agente può cercare nelle directory e caricare solo i file pertinenti all'attività corrente.

I file sono un'interfaccia, non necessariamente uno storage fisico

Un'interfaccia in stile file system non richiede che ogni memoria aziendale esista come file non gestiti su un laptop.

L'implementazione sottostante può comunque utilizzare:

• Database
• Storage di oggetti versionato
• Servizi di controllo accessi
• Indici di ricerca
• Log di audit
• API transazionali

Il punto chiave è che l'agente riceve un'astrazione semplice e navigabile.

Nella sessione di domande e risposte, un membro del pubblico ha chiesto se questo equivalesse a reinventare il database.

Mukta ha riconosciuto che questa architettura torna a principi familiari di ingegneria del software. Una volta che il team ha capito quali comportamenti dovrebbero essere deterministici, possono essere spostati nel framework di controllo, invece di lasciare che il modello improvvisi ogni volta.

Quattro linee guida per una memoria di livello produttivo

Una cartella piena di file Markdown può funzionare per un singolo utente.

Ma quando migliaia di agenti possono aggiornare una memoria organizzativa condivisa, questo diventa pericoloso.

Mukta ha evidenziato quattro principi produttivi:

1. Versionamento
2. Controllo della concorrenza
3. Gestione dei permessi
4. Portabilità

1. Versionare ogni modifica della memoria

Ogni aggiornamento della memoria dovrebbe avere una cronologia.

I metadati utili includono:

• Versione precedente
• Nuova versione
• Timestamp
• Autore umano o agente
• Sessione di origine
• Verbale della conversazione di supporto
• Motivo della modifica
• Stato di approvazione

Le voci di memoria senza provenienza sono difficili da fidarsi.

Supponiamo che un agente aggiunga:

- Le distribuzioni di produzione del venerdì non richiedono approvazione.

Senza provenienza, revisore e cronologia delle revisioni, un altro agente potrebbe trattare questa affermazione come autorevole.

Il versionamento supporta:

• Revisione
• Rollback
• Audit
• Confronto
• Analisi delle cause radice

Un sistema di memoria versionato dovrebbe essere in grado di rispondere facilmente:

Quale interazione ha portato all'introduzione di questa regola?

2. Impedire che gli agenti concorrenti si sovrascrivano a vicenda

Due agenti potrebbero leggere la stessa memoria alle 10:00.

L'agente A scrive un aggiornamento alle 10:02.

L'agente B, ignaro di questa modifica, scrive la propria versione alle 10:03 e cancella accidentalmente l'aggiornamento dell'agente A.

Mukta ha descritto un modello di concorrenza basato su hash:

L'agente legge la memoria e registra hash A
        ↓
L'agente redige un aggiornamento
        ↓
L'agente rilegge la memoria e registra hash B
        ↓
Se hash A == hash B:
    Invia l'aggiornamento
Altrimenti:
    Ricarica, riallinea e riprova

Questo è il controllo ottimistico della concorrenza.

Il modello può decidere quali modifiche proporre, ma il framework di controllo dovrebbe impedire in modo deterministico che scritture obsolete sostituiscano versioni più recenti.

3. Distinguere tra permessi di lettura e scrittura

Non tutti gli agenti dovrebbero poter modificare ogni voce di memoria.

Un modello di permessi ragionevole potrebbe essere:

Ambito della memoria	Accesso tipico
Principi organizzativi	Solo lettura per la maggior parte degli agenti; scrittura solo tramite processo di approvazione
Politiche di sicurezza	Solo lettura per gli agenti pertinenti; scrittura limitata controllata da umani
Processi di team	Solo lettura per il team; scrittura da parte dei manutentori designati
Decisioni di progetto	Solo lettura per gli agenti del progetto; modifiche proposte soggette ad approvazione
Area di bozze degli agenti	Lettura e scrittura per il singolo agente
Preferenze utente	Accesso in base all'ambito dell'agente dell'utente
Contesto clienti sensibile	Accesso rigoroso basato sui ruoli

Un agente non dovrebbe poter trasformare un'osservazione incerta in una regola a livello organizzativo.

I confini dei permessi devono applicarsi anche al Dreaming. Le attività di consolidamento possono ricevere solo log di conversazione e memorie per cui la loro identità è autorizzata.

4. Rendere la memoria portabile

La memoria potrebbe diventare uno degli asset di IA più preziosi di un'organizzazione.

Contiene:

• Decisioni
• Correzioni
• Flussi di lavoro
• Preferenze
• Modalità di errore
• Conoscenza degli strumenti
• Istruzioni specifiche del dominio

Mukta ritiene che i team dovrebbero evitare di progettare questo asset in modo che funzioni esclusivamente all'interno di un singolo prodotto.

Un sistema di memoria portabile dovrebbe avere:

• API chiare
• Formati esportabili
• Schemi documentati
• Identificatori stabili
• Controllo degli accessi standard
• Provenienza indipendente dagli strumenti

La portabilità consente allo stesso contesto ben curato di supportare:

• Claude Code
• Agenti ospitati da Claude
• Strumenti interni
• Altri sistemi di agenti
• Flussi di lavoro documentali umani

Perché la memoria in-sessione non è sufficiente

Anche strumenti di memoria ben progettati presentano due limitazioni strutturali.

Limitazione uno: gli agenti sono soggetti a distrazione

L'agente deve completare l'attività e allo stesso tempo organizzare la memoria.

Scrivere nella memoria consuma risorse che altrimenti verrebbero utilizzate per l'obiettivo corrente.

L'agente potrebbe:

• Salvare troppo
• Salvare troppo poco
• Archiviare conclusioni non verificate
• Saltare il lavoro di memoria sotto pressione temporale
• Concentrarsi solo sui dettagli locali piuttosto che sui modelli più ampi

Limite 2: un agente vede una sola sessione

Un agente potrebbe notare che un comando è fallito una volta.

Non può vedere che lo stesso comando è fallito anche in altre 300 sessioni.

Un agente di supporto potrebbe vedere un cliente confuso riguardo una policy.

Non può vedere che la stessa confusione si ripresenta in tutta la regione.

Un meccanismo di apprendimento a livello di sistema richiede un processo con visibilità più ampia.

Questo processo è ciò che Anthropic chiama "Sogno" (Dreaming).

Sogno: un processo fuori banda per organizzare la memoria

Il sogno è un processo asincrono che esamina la cronologia degli agenti dopo il completamento del lavoro normale.

Le attuali note di rilascio dell'API di Anthropic descrivono la funzione di "sogno" per gli agenti ospitati di Claude come un'anteprima di ricerca.

Un "sogno" legge:

• L'archivio di memoria esistente
• I registri delle sessioni passate

Successivamente crea un archivio di memoria di output riorganizzato, in cui può:

• Unire voci duplicate
• Sostituire informazioni obsolete
• Far emergere intuizioni mancanti
• Riorganizzare i contenuti
• Proporre memorie migliorate

Non si tratta di un riaddestramento del modello.

I pesi del modello sottostante non cambiano.

Il miglioramento deriva dalla modifica del contesto persistente, rendendo questi contenuti recuperabili nelle sessioni future.

Analogia scolastica

Mukta ha usato una scuola per spiegare la differenza tra memoria normale e "sogno".

Immaginate:

• Gli studenti completano i compiti.
• Gli insegnanti correggono ogni compito.
• Un preside esamina i risultati complessivi della scuola.

Un insegnante può aiutare uno studente a correggere un errore.

Il preside può notare che ogni studente di geografia commette lo stesso errore, perché semplicemente il programma del corso non lo include.

La correzione a livello di sistema non consiste nel correggere ogni singolo compito.

Consiste nell'aggiornare il programma del corso.

Terminologia degli agenti:

• Compiti degli studenti = sessioni individuali
• Feedback dell'insegnante = aggiornamenti della memoria nella sessione
• Programma scolastico = archivio di memoria condiviso
• Revisione del preside = elaborazione del sogno (Dreaming)
• Aggiornamento del programma = modifiche alla memoria proposte

Questo consente al sistema di apprendere da modelli che un singolo agente non può rilevare.

Meccanica dell'elaborazione del sogno

Una pipeline semplificata dell'elaborazione del sogno è la seguente:

Diagramma di flusso TD
    A[Archivio di memoria esistente] --> D[Orchestratore del sogno]
    B[Registri delle sessioni] --> D
    C[Chiamate agli strumenti e metadati] --> D
    D --> E1[Agente di revisione 1]
    D --> E2[Agente di revisione 2]
    D --> E3[Agente di revisione 3]
    E1 --> F[Aggregatore di modelli]
    E2 --> F
    E3 --> F
    F --> G[Modifiche alla memoria proposte]
    G --> H{Approvazione umana}
    H -->|Accettata| I[Archivio di memoria aggiornato]
    H -->|Rifiutata| J[Mantieni memoria esistente]

Il processo di revisione può esaminare contenuti non limitati ai soli messaggi tra utente e assistente.

Le prove utili includono:

• Chiamate agli strumenti
• Errori degli strumenti
• Numero di tentativi
• Metadati di esecuzione
• Correzioni umane
• Punteggi di valutazione
• Output accettati e rifiutati
• Utilizzo delle competenze
• Versione del modello
• Latenza e costi

L'agente del sogno cerca quindi modelli come:

• Lo stesso comando fallisce ripetutamente.
• Più agenti fraintendono un termine interno.
• Una voce di memoria non è più valida.
• Due file contengono regole duplicate.
• Il team corregge ripetutamente lo stesso problema di formato.
• Una configurazione di uno strumento causa errori in più progetti.
• Manca una policy, costringendo gli agenti a fare supposizioni.

Mukta ha menzionato che il design di Anthropic può includere esempi di sessioni correlate e statistiche che mostrano la frequenza del modello.

Queste prove aiutano gli esseri umani a giudicare se la modifica alla memoria proposta è ragionevole.

L'elaborazione del sogno dovrebbe proporre suggerimenti, non riscrivere tutto in silenzio

Il processo di elaborazione del sogno ha accesso esteso e può influenzare il comportamento futuro dell'intero cluster di agenti.

Questo rende gli aggiornamenti automatici e non revisionati rischiosi.

Un flusso di lavoro più sicuro è:

1. Analizzare i registri delle sessioni autorizzate.
2. Identificare i modelli ricorrenti.
3. Collegare i modelli alle sessioni di supporto.
4. Redigere le modifiche alla memoria proposte.
5. Stimare la diffusione del problema.
6. Richiedere l'approvazione di un revisore umano o controllato da policy.
7. Inviare gli aggiornamenti approvati con registrazioni della fonte.
8. Misurare l'eventuale miglioramento delle prestazioni future.

Ad esempio:

## Aggiornamento della memoria proposto

**Obiettivo:** `teams/engineering/test-process.md`

**Problema osservato:**  
Gli agenti hanno usato il comando per test unitari per eseguire test di integrazione in 18 delle 63 sessioni correlate.

**Prove:**  
Sessioni `s-102`, `s-111`, `s-118`, `s-124`, …

**Aggiunta proposta:**  
- Utilizzare `npm run test:integration` per tutti i test che richiedono contenitori di database.
- Non usare `npm test` per i file in `tests/integration/`.

**Livello di confidenza:** Alto

**Decisione umana:** In attesa

Questo preserva la supervisione umana, consentendo al cluster di agenti di svolgere gran parte del lavoro di analisi.

Perché l'elaborazione del sogno riduce i costi nonostante utilizzi più token

L'elaborazione del sogno richiede chiamate al modello aggiuntive.

A prima vista, sembra un costo inutile.

Mukta sostiene che un archivio di memoria più pulito riduce i costi complessivi, perché gli agenti futuri hanno maggiori probabilità di completare correttamente le attività al primo tentativo.

Il primo tentativo.

Un confronto economico utile è:

Costo del sogno
contro
Costo di errori ripetuti, tentativi, rilavorazione e contesti eccessivamente lunghi

I risparmi potenziali possono derivare da:

• Meno tentativi
• Meno spiegazioni ripetute
• Meno contesto irrilevante
• Migliore selezione degli strumenti
• Maggiore precisione al primo tentativo
• Onboarding più rapido di nuovi agenti
• Meno correzioni umane ripetute

Anthropic non ha ancora pubblicato un benchmark universale che indichi quanto ogni organizzazione possa risparmiare. Il valore specifico dipende da:

• Grado di ripetizione delle attività
• Qualità della memoria
• Costo degli errori
• Numero di sessioni
• Progettazione della revisione
• Prezzi di modelli e strumenti

Quando molti agenti eseguono attività correlate e incontrano ripetutamente gli stessi modelli, il "sogno" ha maggiori probabilità di dare risultati.

Semplice processo di sogno settimanale senza agenti ospitati

Un team non deve attendere l'integrazione completa della piattaforma per testare questo concetto.

Una versione manuale può essere eseguita una volta alla settimana.

Passo 1: Esportare le sessioni pertinenti

Raccogliere solo i registri delle conversazioni che il revisore è autorizzato a vedere.

Organizzarli per:

• Progetto
• Team
• Flusso di lavoro
• Ambito delle autorizzazioni
• Periodo di tempo

Passo 2: Fornire la memoria corrente

Includere:

• CLAUDE.md
• Competenze pertinenti
• File di memoria del progetto
• Note del team
• Documentazione dei problemi noti

Passo 3: Richiedere proposte supportate da prove

Il prompt può essere il seguente:

Esamina questi registri di sessioni autorizzate e i file di memoria corrente.

Identifica errori ricorrenti, correzioni ripetute da parte dell'utente, istruzioni obsolete,
processi mancanti e voci duplicate.

Per ogni modifica proposta:
1. Indica il file di destinazione.
2. Fornisci gli ID delle sessioni di supporto.
3.

Spiegare la frequenza con cui si presenta questo schema.
4. Redigere la modifica minima efficace.
5. Non modificare direttamente i file.

Fase 4: Revisione della proposta

Rifiutare le seguenti modifiche:

• Basate su un singolo evento vago
• Prive di evidenze a supporto
• Di portata eccessivamente ampia
• Relative a questioni sensibili per la sicurezza
• Al di fuori delle competenze del revisore
• Più adatte a essere implementate con codice deterministico

Fase 5: Presentare le modifiche approvate

Utilizzare il controllo di versione e includere le prove delle fonti nel commit o nei registri di audit.

Fase 6: Misurare i risultati

Monitorare se gli stessi errori si riducono nelle sessioni successive.

Senza misurazione, il "sogno" diventa un esercizio di generazione di documenti, non un sistema di apprendimento.

Dalla memoria accumulata nel tempo alla struttura all'interno dell'attività

La memoria risponde alla domanda:

Cosa dovrebbe ricordare l'agente dal lavoro precedente?

L'ingegneria della struttura a grafo risponde a una domanda diversa:

Quali parti dell'attività corrente dipendono effettivamente l'una dall'altra?

L'articolo originale di BAAI collega il tema della memoria a una guida sull'ingegneria dei grafi circolante nella comunità dello sviluppo dell'IA.

La tesi centrale della guida è che molti "workflow" sono già intrinsecamente grafi — solo progettati male.

I workflow scritti come elenchi tendono a diventare artificialmente processi seriali:

Ricerca
    ↓
Sintesi
    ↓
Confronto
    ↓
Verifica dei fatti
    ↓
Scrittura

Alcuni di questi passaggi potrebbero effettivamente dipendere dall'output del precedente.

Altri potrebbero attendere inutilmente.

Nodi, archi e flusso di dati reale

Nel grafo del workflow:

• Nodo rappresenta un'attività.
• Arco rappresenta una dipendenza reale.
• I dati scorrono lungo gli archi.

Ad esempio:

Il nodo di ricerca produce risultati di ricerca.

Il nodo di scrittura consuma questi risultati e produce una bozza.

Il nodo di verifica consuma la bozza e produce un risultato verificato.

Queste frecce sono sensate perché ogni nodo a valle richiede l'output del nodo a monte.

Test del falso arco

La guida comunitaria propone un semplice test per ogni freccia:

Il compito successivo richiede davvero l'output del compito precedente?

Se la risposta è no, allora quella dipendenza è una falsa dipendenza.

Considera il seguente workflow:

Ricerca concorrente A
    ↓
Ricerca concorrente B
    ↓
Ricerca concorrente C
    ↓
Redazione rapporto comparativo

La ricerca sul concorrente B di solito non richiede l'output della ricerca sul concorrente A.

La ricerca sul concorrente C di solito non richiede l'output della ricerca sul concorrente B.

Queste attività possono essere eseguite in parallelo:

flowchart TD
    A[Definire criteri di confronto] --> B1[Ricerca concorrente A]
    A --> B2[Ricerca concorrente B]
    A --> B3[Ricerca concorrente C]
    B1 --> C[Redazione rapporto comparativo]
    B2 --> C
    B3 --> C

Rimuovere i falsi archi riduce i tempi di attesa.

Se le tre attività di ricerca richiedono rispettivamente 10, 12 e 15 minuti:

• L'esecuzione sequenziale richiede circa 37 minuti.
• L'esecuzione parallela richiede circa 15 minuti di attesa, più i costi di orchestrazione.

Il grafo non rende più veloce nessun singolo agente.

Cambia la pianificazione.

Schema a diamante

Dopo aver rimosso i falsi archi, emerge una forma comune:

1. Un'attività si suddivide in rami indipendenti.
2. Questi rami vengono eseguiti in parallelo.
3. I risultati convergono.
4. Un nodo finale sintetizza i risultati.

Questo viene spesso chiamato diamante.

Un esempio di ricerca potrebbe essere il seguente:

flowchart TD
    A[Domanda di ricerca] --> B1[Dati di mercato]
    A --> B2[Evidenze dai clienti]
    A --> B3[Analisi concorrenti]
    B1 --> C[Verificatore]
    B2 --> C
    B3 --> C
    C --> D[Sintesi finale]

Il tempo totale è determinato principalmente dal ramo più lento, non dalla somma dei tempi di tutti i rami.

Il lavoro parallelo richiede un verificatore

Il parallelismo introduce un nuovo

rischio.

Un worker potrebbe produrre un output debole, obsoleto o non supportato.

Se il sistema unisce tutto senza verifica, un singolo ramo difettoso può contaminare la risposta finale.

Pertanto, la guida sul grafo colloca un controllore prima della sintesi.

Un verificatore può chiedere:

• Questa affermazione è supportata?
• La fonte è aggiornata?

L'output è conforme al formato richiesto?

• Il thread di lavoro ha completato il compito assegnato?
• Il codice supera i test?
• Il risultato è in conflitto con altri rami?
• Esistono dati sensibili?
• Questo output può essere proseguito in sicurezza?

Un controllore utile dovrebbe avere criteri di accettazione chiari.

Ad esempio: