Blog

Perché le decisioni prese nelle chat con l’IA si perdono, e dove conservarle

Le decisioni prese in ChatGPT o Claude spariscono quando la chat scorre via: registrale sulla bacheca, legate all’attività, e la sessione IA successiva le legge prima.

Weft è il gestore di attività con IA per chi fonda da solo e i piccoli team.

Tutti gli articoli

Di Andrei Finogeev ·

Le decisioni prese in una conversazione con ChatGPT o Claude si perdono perché una chat non ha stato. Niente al suo interno segna una riga come “questo è ciò che abbiamo deciso”, niente lega quella riga al lavoro che riguarda, e una nuova chat parte vuota. La soluzione è far scrivere la decisione all’IA nel posto dove vive il lavoro, come un breve registro con le sue ragioni, e far leggere quei registri alla sessione successiva prima che agisca.

Weft lo facciamo noi. Le informazioni sugli altri prodotti vengono dalle loro pagine ufficiali, verificate il 27 ottobre 2026. L’idea che un thread “non abbia stato” viene dall’articolo di Hypertask sui thread di Slack. Questa guida la applica alle chat con l’IA.

Perché spariscono le decisioni prese con ChatGPT o Claude?

Passi quaranta minuti con un assistente a valutare due fornitori di database, due modelli di prezzo o due modi di strutturare un’API. Ne scegli uno. Il ragionamento è buono, l’assistente è d’accordo, e passi alla cosa successiva.

Una settimana dopo la conclusione è ancora in quella chat, da qualche parte sopra altri duecento messaggi. Una nuova chat non ne sa niente. Un collega non l’ha mai vista. E se il giorno dopo apri un altro client IA, per esempio un agente di programmazione nel terminale, quel client parte da zero e può tranquillamente proporti l’opzione che avevi scartato.

Non è un problema di disciplina. Una conversazione è una sequenza di messaggi. Non ha un campo “deciso”, non ha un responsabile, non ha un collegamento a un’attività e non ha modo di dire “questo sostituisce ciò che avevamo detto martedì”. Una domanda decisa e una abbandonata sembrano uguali una volta che scorrono via.

La memoria della chat non risolve già il problema?

Non per questo compito. Molti assistenti ora possono ricordare cose su di te tra una chat e l’altra, ed è utile per preferenze e contesto. Ma quella memoria appartiene a un solo prodotto e a un solo account. È scritta perché la usi quell’assistente, non come un registro che una persona può rivedere riga per riga, e un altro client IA non può leggerla. Inoltre non dice a quale attività si riferiva una scelta né quale scelta precedente ha sostituito.

Un registro delle decisioni ha requisiti diversi. Deve essere trovabile dalle persone e dagli agenti che lavorano al progetto, leggibile da qualunque client IA prenda in mano il lavoro dopo, legato a quel lavoro e onesto sulla storia: quando una decisione cambia, quella vecchia dovrebbe restare visibile con il motivo per cui è stata sostituita.

Cosa conta come decisione da registrare?

Registra una scelta quando qualcuno avrebbe potuto ragionevolmente scegliere diversamente e la scelta influenzerà il lavoro successivo. Buoni esempi:

  • Scegliere uno strumento, un fornitore o una libreria invece di un altro.
  • Rinunciare a qualcosa di proposito (“niente programma di referral in questo trimestre”).
  • Fissare una regola che il lavoro deve seguire (“nell’UE tutti i prezzi sono mostrati IVA inclusa”).
  • Cambiare una scelta precedente, con il motivo.
  • Una lezione imparata a proprie spese (“non eseguire la migrazione in orario lavorativo”).

Non registrare:

  • Idee che hai buttato lì e non hai adottato.
  • I passi del lavoro stesso (quelli stanno nell’attività e nel suo risultato).
  • Qualsiasi cosa su cui la persona non si è ancora detta d’accordo, a meno che non sia chiaramente segnata come proposta.
  • Fatti che chiunque può ritrovare in un minuto.

Un test utile: se una nuova sessione IA stesse per disfare questa scelta, vorresti che si fermasse a leggere perché? Se sì, registrala.

Com’è fatto un buon registro di decisione?

Tienilo breve e conserva le ragioni. Il formato qui sotto è una versione leggera di MADR (Markdown Architectural Decision Records), che è ciò che usa lo strumento record_decision di Weft:

Title:        Caricamento file: object storage, non il database
Outcome:      I file caricati vanno nell’object storage; il database conserva
              solo la chiave del file e i metadati.
Status:       accepted
Context:      Gli utenti allegano file fino a 50 MB. Tenerli nel
              database renderebbe i backup lenti e pesanti.
Options:      1. Object storage  + economico, i backup restano piccoli
                                 - un servizio in più da configurare
              2. Colonna del database + un solo posto per tutto
                                 - i backup crescono a ogni caricamento
Consequences: Servono URL firmati per i download.
              Eliminare un’attività deve eliminare anche i suoi file.
Revisit when: Avremo bisogno di cercare dentro il contenuto dei file.
Task:         Caricamento file
  • Title dà un nome alla decisione, così puoi trovarla scorrendo.
  • Outcome è una frase su cui chi arriva può agire.
  • Context è ciò che era vero in quel momento. È la parte che sparisce per prima dalla memoria.
  • Options elenca solo ciò che è stato davvero valutato, non alternative inventate dopo.
  • Consequences include gli svantaggi che hai accettato, così nessuno li “scopre” più tardi come bug.
  • Revisit when dice cosa renderebbe sbagliata la scelta.

Come conserva un registro di decisione Weft?

Weft è una bacheca di attività che i tuoi client IA raggiungono tramite MCP su https://letsweft.com/api/mcp. Tre dei suoi 32 strumenti gestiscono le decisioni:

  • record_decision riceve un titolo e un esito, più contesto, fino a cinque opzioni con pro e contro, conseguenze e la condizione per riconsiderarla. Può essere collegato a un’attività (taskId) o a un progetto. I registri sono immutabili: per cambiarne uno, l’IA registra una nuova decisione con supersedesId che punta a quella vecchia, e il vecchio registro resta, marcato come sostituito.
  • get_context restituisce le decisioni e le lezioni in vigore nello spazio di lavoro, dalle più recenti, entro un budget di token (800 token come impostazione predefinita). Si può restringere a un progetto o a un’attività. Ogni riga porta la sua data, una decisione sostituita non compare mai, e le righe che non ci stavano vengono contate invece che nascoste.
  • get_task_history in modalità decisions elenca ogni decisione registrata su un’attività, compresi i verdetti di revisione e le loro motivazioni.

record_decision ha un secondo uso: riportare un verdetto che la persona ha dato in conversazione su un lavoro in attesa della sua revisione (accettato, da rifare, scartato o rinviato). La descrizione dello strumento dice all’IA che qui è il messaggero, non chi decide, quindi non deve mai usarlo per accettare il proprio lavoro.

Siccome i registri non vengono mai modificati sul posto, la storia resta onesta. Se a marzo cambi fornitore, la decisione di gennaio è ancora lì, marcata come sostituita, e il registro di marzo dice perché.

Come chiedo alla mia IA di registrare le decisioni?

Collega Weft al tuo client IA, poi incolla un’istruzione come questa all’inizio di una chat, o nelle istruzioni personalizzate del client o nel suo file di progetto, se ne ha uno:

Quando in questa chat facciamo una scelta vera (scegliamo un’opzione invece di un’altra,
rinunciamo a qualcosa o cambiamo una scelta precedente), registrala in Weft con
record_decision prima di andare avanti:
- title: la decisione, in poche parole
- outcome: la scelta in una frase
- context: cosa era vero e ci ha costretti a scegliere
- options: solo le opzioni che abbiamo davvero valutato, con pro e contro
- consequences: cosa ne segue, nel bene e nel male
- confirmation: quando dovremmo riconsiderarla
- taskId o project: l’attività o il progetto a cui si riferisce
Se cambia una decisione precedente, passa supersedesId invece di modificarla.
Non registrare chiacchiere, ipotesi o cose su cui non mi sono detto d’accordo.
Se non mi sono ancora impegnato, usa lo status "proposed".
All’inizio di qualsiasi lavoro non banale, chiama prima get_context e dimmi
quali decisioni passate si applicano.

Collegarsi richiede un minuto. In ChatGPT, Weft è un’app pubblicata nella directory dei plugin, disponibile su ogni piano, gratuito compreso (configurazione). In Claude Code basta un comando (configurazione). Claude.ai e Claude Desktop lo aggiungono come connettore personalizzato. L’accesso è OAuth nel browser, quindi non c’è nessuna chiave da copiare, e Weft rilascia refresh token, quindi il client rinnova l’accesso da solo. Le pagine di configurazione per gli altri client, tra cui Cursor e Codex, sono nella documentazione.

Cosa succede quando il giorno dopo passo da ChatGPT a Claude Code?

Ecco il caso per cui è pensata l’istruzione.

  1. Lunedì pianifichi una funzione in ChatGPT. Decidi di salvare i caricamenti nell’object storage invece che nel database, e ChatGPT chiama record_decision con il contesto, entrambe le opzioni e le conseguenze, collegato all’attività “Caricamento file”.
  2. Martedì apri Claude Code nel repository. Se non l’hai ancora collegato: claude mcp add --transport http weft https://letsweft.com/api/mcp.
  3. Gli chiedi di prendere l’attività dei caricamenti. Prima di scrivere codice chiama get_context per quell’attività, o get_task_history in modalità decisions, e riceve il registro di lunedì.
  4. Costruisce sull’object storage invece di riaprire la questione. Se trova un motivo reale per cui la scelta è sbagliata, può proporre una nuova decisione che sostituisce quella di lunedì, e decidi tu.

Entrambi i client leggono la stessa bacheca e le stesse decisioni, perché il registro vive in Weft, non in una delle due chat. Ogni connessione OAuth è un attore a sé, e la bacheca mostra il nome con cui si è registrato ciascun client, così puoi vedere quale connessione ha creato quale attività. Per far lavorare più agenti su una bacheca senza collisioni, vedi più agenti IA, una sola bacheca.

Dove dovrebbero finire le decisioni prese in ChatGPT?

Quattro posti comuni, confrontati su ciò che serve a un registro delle decisioni:

Dove finisce la decisioneRitrovabile dopoLeggibile da un’altra IALegata al lavoroSostituibile con una motivazione
Cronologia della chatSolo se ti ricordi quale chat, e la ricerca la trovaNo, un altro client non può aprirlaNoNo, un messaggio successivo la contraddice senza segnarlo
Documento o pagina di appuntiSì, se qualcuno l’ha messa per iscrittoSolo se quell’IA è collegata al documentoVagamente, tramite linkDi solito modificandola, il che tende a cancellare il vecchio ragionamento
Commento su un’attivitàSì, su quell’attivitàSe l’IA può leggere i commenti del trackerSìNon esplicitamente, i commenti più nuovi non segnano come sostituiti quelli vecchi
Registro di decisione sulla bacheca WeftSì, tramite get_context e get_task_historySì, qualsiasi client collegato allo spazio di lavoro via MCPSì, per attività o progettoSì, supersedesId conserva il vecchio registro, marcato come sostituito

Il punto non è che chat o documenti siano cattivi. La chat è dove pensi. La decisione va copiata fuori dalla chat in qualcosa che ha uno stato, nel momento in cui viene presa, da chi è già nella conversazione: l’IA.

Sostituisce i nostri documenti o la nostra wiki?

No. Weft non ha documenti né wiki, e non cerca di esserlo. Spiegazioni lunghe, guide di onboarding e documenti di design stanno nel tuo strumento per i documenti. Un registro di decisione è volutamente piccolo: una scelta, le sue ragioni e cosa l’ha sostituita. Se il tuo team tiene già i registri delle decisioni in una wiki e ogni client IA che usi può leggerla, può bastare. Weft è utile quando le decisioni vengono prese nelle chat con l’IA e chi legge dopo è spesso un’altra IA. Se stai valutando Notion per questo, vedi alternative a Notion per le attività con l’IA.

Altri due limiti onesti. Weft non legge le tue chat: una decisione viene registrata solo quando l’IA chiama record_decision, ed è per questo che l’istruzione qui sopra conta. E l’IA può valutare male cosa conta come decisione, quindi leggi get_context ogni tanto e sostituisci ciò che ha sbagliato.

Quanto costa?

Registrare e leggere le decisioni funziona sul piano gratuito, che include 50 attività attive e 200 chiamate agli strumenti IA al mese. Ogni chiamata a record_decision o get_context conta come una chiamata. Pro costa 7 $ per postazione al mese o 60 $ per postazione all’anno, con attività e chiamate illimitate (prezzi). Weft non ha crediti IA: il ragionamento avviene nel tuo client IA, e Weft conserva solo la bacheca e i suoi registri.

Non posso semplicemente chiedere a ChatGPT di riassumere le decisioni alla fine di una chat?
Puoi, e aiuta. Ma il riepilogo vive comunque in quella chat o dove lo incolli. Non è legato all’attività, un altro client IA non può leggerlo, e quando la decisione cambia non resta traccia di cosa ha sostituito. Registrare ogni decisione nel momento in cui viene presa evita tutte e tre le cose.
L’IA registrerà le decisioni senza che glielo chieda?
La descrizione dello strumento record_decision dice all’IA di usarlo ogni volta che l’utente fa una scelta vera in conversazione, quindi alcuni client lo faranno. Non contarci. L’istruzione incollata lo rende esplicito, e puoi sempre dire “registra quella decisione”.
Si può modificare una decisione registrata male?
Non sul posto. I registri sono immutabili. Registra una decisione corretta con supersedesId che punta a quella sbagliata. Il vecchio registro resta, marcato come sostituito, e get_context smette di mostrarlo.
Le decisioni hanno bisogno di un’attività?
No. Una decisione può essere collegata a un’attività, a un progetto o a nessuno dei due. Collegarla a un’attività fa sì che get_task_history la mostri accanto a quel lavoro, e get_context si può restringere a essa.
È la stessa cosa della memoria di lavoro di Weft?
No. La memoria di lavoro (brevi note apprese) è una funzione Pro separata. I registri di decisione vengono da record_decision, e il codice non li limita a Pro.
E se uso più di un client IA?
È il motivo principale per farlo. ChatGPT, Claude Code, Cursor o Codex collegati allo stesso spazio di lavoro Weft leggono tutti le stesse decisioni tramite get_context, così il secondo client non riapre questioni che il primo ha già chiuso.