CLAUDE.md, MEMORY.md, INDEX.md, STATE.md, TASKS.md e log.md: come collaborano perché l’AI non perda mai il filo e trovi la cosa giusta in due letture, non in tremila.

Ogni mattina la mia AI dimentica tutto. E ogni mattina ritrova il filo in venti secondi.

Lunedì, le otto e mezza, il caffè ancora caldo. Apro una sessione nuova, di quelle che non sanno niente di ieri, niente di me, niente di cosa stavo facendo venerdì. Scrivo una riga: “dove siamo col Personal Brand, cosa devo decidere oggi”. L’agente legge un file solo, corto, e in venti secondi mi dice a che punto è lo sprint, quali sono gli alert accesi, quanti iscritti ho sul Substack e qual è la cosa che rischia di cadere questa settimana. Poi mi chiede se voglio partire da lì.

Non gli ho incollato niente. Non gli ho ricaricato il contesto. Quella sessione è nata vuota come tutte le altre, eppure sapeva dov’eravamo. Il vault sotto ha quasi cinquemila file e qualcosa come tre milioni di parole. Lui ne ha lette meno di cinquecento, ed era orientato.

La settimana scorsa ti ho raccontato due di quei file, STATE.md e TASKS.md, e come bastano a far orientare Claude. Oggi ti do il sistema intero: i sei file che si passano la palla perché l’AI non perda mai memoria e, allo stesso tempo, non bruci un patrimonio di token per ricordarsela. Perché è lì che quasi tutti sbagliano, e ti spiego subito perché.

In sintesi. Un second brain con memoria persistente non è un megafile, sono sei file di testo con ruoli distinti. CLAUDE.md tiene le regole, MEMORY.md la conoscenza stabile, STATE.md la fotografia di adesso, TASKS.md cosa è aperto, INDEX.md la mappa per navigare, log.md cosa è successo. L’agente ne legge pochi e mirati: ritrova il filo in qualche centinaio di parole invece di caricare i milioni del vault. Così non perde memoria e non spreca token.

Questo post è il seguito diretto di quello su STATE.md e TASKS.md di mercoledì scorso. Lì c’è cosa sono i due file di stato e i template. Qui li rimetto al loro posto dentro il sistema completo, insieme agli altri quattro. Se non l’hai letto, parti da quello, questo lo capisci meglio.

2 file che orientano il mio Second Brain

Il problema, l’AI ha due amnesie e tu ne conosci una sola

Quando lavori con un’AI per qualcosa di serio, contro la memoria sbatti due volte, non una.

La prima amnesia la conosci: ogni conversazione nuova riparte da zero. L’AI non si ricorda cosa avete deciso ieri, come parli, chi sono i tuoi clienti, a che punto era il progetto. Ogni volta ricominci a spiegare. È il motivo per cui dopo un po’ molti mollano: passano più tempo a fare il riassunto della propria vita che a lavorare.

La seconda amnesia non la vede quasi nessuno, ed è quella che ti costa di più. Per dare memoria all’AI, la soluzione istintiva è una sola: dargliela tutta. Incollo tutto, le carico l’intero archivio, metto ogni cosa in un megafile così “sa tutto”. Sembra la mossa giusta. È la trappola. Più contesto le versi addosso, più la confondi, più rallenta, e più paghi. Ogni parola che legge è un token, e i token costano, in soldi e in attenzione. Un’AI sommersa da tre milioni di parole non è un’AI con buona memoria. È un’AI che annega.

Quasi tutti i contenuti sul second brain si fermano a metà del problema. Ti spiegano come accumulare: nota qui, cartella lì, metti tutto in Obsidian, dallo in pasto a Claude. La parte difficile non è accumulare la conoscenza. È farle trovare la cosa giusta senza leggere tutto il resto. La memoria che serve non è “l’AI sa tutto”. È “l’AI trova quello che le serve adesso, in due letture, e ignora il resto”.

Il principio, la memoria è un’architettura, non un file

La svolta arriva quando smetti di pensare alla memoria come a un contenitore e inizi a pensarla come a un ufficio organizzato.

In un ufficio organizzato nessuno tiene tutto sulla scrivania. C’è una lavagna con su scritto a che punto siamo questa settimana, ci sono gli schedari per le cose che servono ogni tanto, c’è un registro di cosa è stato fatto, c’è un cartello all’ingresso che dice dove sta ogni cosa. Tu, quando entri, guardi la lavagna. Apri lo schedario solo se ti serve davvero quella pratica. Non ti rileggi tutto l’archivio ogni mattina per sapere cosa fare oggi.

Il mio second brain funziona così, e i mobili dell’ufficio sono sei file di testo. Ognuno ha un compito diverso e una velocità diversa: alcuni cambiano ogni giorno, altri quasi mai. La regola che tiene insieme tutto è una sola, e vale la pena tatuarsela: ogni informazione vive in un posto solo, e l’agente sa in quale ordine guardare. Niente duplicati, niente “lo metto sia qui che lì per sicurezza”. I duplicati sono il modo più veloce per ritrovarti due verità diverse e un’AI che non sa a quale credere.

È questa separazione che fa il miracolo dei token. L’agente non carica i sei file insieme, e tantomeno il vault. Ne legge uno corto per orientarsi, e poi va a prendere solo il pezzo che gli serve, seguendo i collegamenti. Pochi passaggi, poche parole, la risposta giusta.

I sei file e come si passano la palla

Ti presento i mobili dell’ufficio uno per uno, con il loro mestiere e con quanto pesano davvero nel mio vault, perché la dimensione è metà del punto.

STATE.md, la lavagna all’ingresso. È il file più corto e il più fresco. Da me sta in meno di cinquecento parole e lo aggiorno ogni venerdì. Dentro c’è solo la fotografia di adesso: lo sprint in corso, i numeri dei canali, gli alert accesi, e in cima un riassunto da trenta parole. È il primo file che l’agente legge sempre, perché in una lettura sola sa dov’è. Non spiega niente in profondità, rimanda. È la lavagna, non l’enciclopedia.

INDEX.md, il cartello che dice dove sta ogni cosa. Questo è il file che fa risparmiare i passaggi. È organizzato per compiti: “devo pubblicare un’issue Substack”, “devo girare un reel”, “devo preparare il piano editoriale”. Sotto ogni compito c’è la sequenza esatta di file da aprire, in ordine. Quando so cosa devo fare ma non so quali pezzi del vault servono, l’agente guarda qui e va dritto, invece di frugare. Senza l’INDEX, ogni richiesta diventa una caccia al tesoro a pagamento.

CLAUDE.md, il regolamento appeso al muro. Sono le regole di come si lavora in quest’area: il tono di voce, le cose da non fare mai, le scorciatoie, le convenzioni. Da me è poco meno di duemila parole. La cosa importante è che questo file si carica da solo a ogni sessione, senza che io lo chieda. È il contesto che l’agente ha sempre in tasca: non deve andarlo a cercare, ce l’ha addosso. Per questo dentro ci stanno le regole, non i dati che cambiano.

MEMORY.md, lo schedario delle cose stabili. È il file più denso, da me quasi quattromila parole. Qui vive quello che non cambia ogni settimana: chi sono, come parlo, le decisioni prese e il perché, la storia che non si tocca. È pesante apposta, ed è anche il file che l’agente apre meno spesso, solo quando gli serve davvero la conoscenza profonda. La lavagna ti dice dove sei oggi. Lo schedario ti dice chi sei sempre.

TASKS.md, la lista di cosa è aperto. Il backlog, diviso in tre scaffali: quello che è caldo adesso, quello che viene dopo, quello che resta per più avanti. È la fonte unica di cosa c’è da fare, così non finiscono task sparse in dieci posti diversi. STATE ti dice qual è la priorità della settimana, TASKS ti dice tutto il resto che aspetta.

log.md, il registro di cosa è successo. Qui finisce ogni operazione fatta, con la data, una riga su cosa e una su com’è andata. Tiene gli ultimi trenta giorni, il resto va in archivio per mese. È il file che cuce insieme le sessioni: quando ne apro una nuova e vuota, è leggendo qui che sa cosa ha fatto quella di ieri. Senza il log, ogni mattina l’AI riscopre l’acqua calda.

Adesso guarda come si passano la palla, perché è qui che sta il sistema e non nei singoli file. Una sessione nuova legge STATE per sapere dov’è. Le regole le ha già addosso col CLAUDE. Se le serve sapere dove mettere le mani, guarda l’INDEX e segue la sequenza. Apre MEMORY solo se le serve la conoscenza stabile, TASKS solo se deve lavorare sul backlog, il log solo se deve capire cosa è già stato fatto. Quattro file su sei restano chiusi quasi sempre. È questo che intendo per few-step retrieval: il percorso più corto dall’entrare in ufficio al fare la cosa giusta.

Perché tutto questo risparmia token, coi numeri

Ti do i numeri veri del mio vault, perché senza sembra una bella teoria e basta.

L’archivio sotto è grosso: quasi cinquemila file, qualcosa come tre milioni di parole. Caricarlo tutto in una sessione non è solo impossibile, sarebbe la cosa più stupida che potrei fare: pagherei una fortuna in token per comprarmi confusione. I sei file di sistema, invece, messi insieme, stanno sotto le diecimila parole. E l’agente non li legge nemmeno tutti: per orientarsi gli bastano i meno di cinquecento di STATE.

Mettila come una proporzione e si capisce da sola. Da un lato tre milioni di parole. Dall’altro le quattrocentosettanta che l’agente legge per sapere dov’è. È la differenza tra entrare in biblioteca e leggere il cartello “sei qui” all’ingresso, e entrare in biblioteca e cominciare a sfogliare tutti i libri per scoprire in che sala stai. Stessa orientazione, una frazione del costo.

E il bello è che funziona anche al contrario. Quando una sessione finisce, non butto via quello che ha imparato: lo scrivo nel file giusto. Una decisione va in MEMORY, una cosa fatta va nel log, lo sprint aggiornato va in STATE. La sessione dopo nasce vuota, ma il vault è già aggiornato, e in meno di cinquecento parole è di nuovo sul pezzo. La memoria non sta nella sessione, che muore ogni volta. Sta nei file, che restano.

Gli errori che ho fatto, così non li fai tu

Tre errori, tutti miei, tutti già pagati.

Il primo: il megafile unico. All’inizio avevo un solo CLAUDE.md gigante con dentro tutto, regole, stato, storia, cose da fare. Cresceva ogni settimana. A un certo punto era così lungo che l’agente ci metteva un’eternità a leggerlo, e dentro ci trovava informazioni vecchie mischiate a quelle nuove. Un file solo che sa tutto diventa un file che non serve a niente. La memoria va spezzata per velocità, non per ordine estetico.

Il secondo: gli stessi dati in più file. Per comodità tenevo i numeri dei canali sia in STATE che in MEMORY che in un terzo posto. Poi ne aggiornavo uno e dimenticavo gli altri, e mi ritrovavo l’agente che mi citava un numero di iscritti vecchio di tre settimane con la stessa sicurezza di uno giusto. Da lì la regola dura: ogni informazione in un posto solo, gli altri file ci rimandano con un link. Un fatto, un indirizzo.

Il terzo, il più subdolo: non aggiornare. Un file di stato vecchio è peggio di nessun file di stato, perché l’AI legge una fotografia scaduta e ci lavora sopra con fiducia. Per questo ogni file ha la sua frequenza: STATE lo tocco ogni venerdì, il log a ogni operazione, MEMORY quando cambia qualcosa di stabile. Tengo perfino scritto, in cima ai file, quando li ho aggiornati l’ultima volta, così se uno è fermo da troppo lo vedo e lo rinfresco prima che faccia danni.

La differenza che conta

C’è una distanza precisa tra avere un second brain e avere un second brain che si ricorda, ed è la stessa che separa chi accumula note da chi costruisce un sistema.

Il second brain che accumula è alla portata di chiunque, ed è quello di cui parlano tutti in queste settimane: prendi Claude, prendi Obsidian, butti dentro le note, dici che hai la tua memoria esterna. Va benissimo come primo passo, l’ho fatto anch’io. Ma è anche il passo che, da solo, ti dà un magazzino e non una memoria: tanta roba dentro, e un’AI che per trovarne una deve scartabellarle tutte, lentamente e a caro prezzo.

Il second brain che si ricorda è un’altra cosa, e non si fa con un tool in più. Si fa decidendo dove vive ogni tipo di informazione e in che ordine si legge, così che l’agente trovi il filo in poche centinaia di parole e lasci chiuso tutto il resto. Sei file di testo, ognuno al suo posto. Il valore non è nella quantità di cose che ci metti dentro, è nell’architettura che decide cosa leggere e cosa ignorare. E quell’architettura, a differenza dell’archivio, è fatta su misura del tuo lavoro: nessuno te la può copiare, perché è il tuo modo di pensare messo in sei file.

Da qui in poi entriamo nella parte operativa: cosa scrivere esattamente dentro ognuno dei sei file, la regola “un fatto, un posto” per non creare duplicati, e il prompt che fa aggiornare lo stato all’agente da solo a fine sessione, così la memoria si mantiene senza che ci pensi tu. Resta aperta a tutti ancora per pochi giorni, poi chiude dietro il paywall. Se la vuoi intera, leggila adesso.

Iscriviti ora

[PAYWALL] Deep dive, cosa scrivere nei sei file (e come tenerli vivi)

Quello che hai letto è il perché e il principio. Questa è la parte copia-incolla: cosa va dentro ogni file, cosa NON va, e il sistema che li tiene aggiornati senza fatica. Adattalo al tuo lavoro, che sia un’agenzia, un negozio o la tua testa.

Cosa va in ciascun file, in una riga

La regola madre, prima di tutto: un fatto vive in un posto solo. Se ti viene voglia di scriverlo in due file, fermati e scegline uno, l’altro ci rimanda con un link. Detto questo, ecco il confine netto di ognuno.

STATE.md tiene solo il presente che cambia ogni settimana: sprint corrente, numeri aggiornati, alert, una priorità. Trenta parole di riassunto in cima. Se una cosa è vera da mesi, non va qui, va in MEMORY.

MEMORY.md tiene lo stabile: chi sei, voce, decisioni prese e perché, storia. Niente numeri che cambiano ogni settimana, niente task. È lo strato lento.

CLAUDE.md tiene le regole di come si lavora: tono, vincoli, cose da non fare mai, convenzioni. È quello che si carica in automatico, quindi qui niente dati volatili, solo istruzioni.

TASKS.md tiene il backlog in tre livelli: caldo adesso, prossimo, più in là. Ogni task con un esito atteso, così si capisce quando è chiusa.

INDEX.md tiene le mappe per compito: “se devi fare X, apri questi file in quest’ordine”. È il file che decide il percorso più corto.

log.md tiene la cronologia: data, cosa, com’è andata, cosa resta aperto. Una entry per operazione. Oltre i trenta giorni, in archivio mensile.

Il frontmatter che li tiene onesti

In cima a ogni file metto poche righe nascoste che dicono quanto è fresco e chi l’ha toccato l’ultima volta. Servono a far suonare l’allarme quando un file è fermo da troppo.

---
tipo: state
freschezza: 2026-06-14
ultimo-aggiornamento-di: rito-del-venerdi
ultimo-aggiornamento-perche: "chiuso sprint, nuovo alert competitor"
---

Quel “perché” è la riga che salva. Tra sei mesi, riaprendo un file, non ti chiedi “ma questo è ancora valido?”: leggi perché è stato toccato l’ultima volta e lo sai in un secondo.

La frequenza di aggiornamento, file per file

Ogni file ha una sua velocità, e mescolarle è l’errore che li fa marcire. STATE lo aggiorni ogni settimana, sempre lo stesso giorno, è un rito. Il log lo aggiorni a ogni operazione, mentre la fai, non dopo. MEMORY lo tocchi solo quando cambia qualcosa di stabile, una decisione, un pezzo di identità. TASKS quando apri o chiudi qualcosa. CLAUDE e INDEX quasi mai, solo quando cambiano le regole o la struttura. La regola pratica: se ti accorgi che stai aggiornando STATE tre volte al giorno, dentro c’è roba che non è “stato”, è “task” o “log”.

Il prompt che fa mantenere la memoria all’agente

Questo è il prompt che do a fine sessione, perché la memoria si aggiorni da sola invece che dipendere dalla mia disciplina. Lo trovi completo in fondo al post, qui ti spiego cosa fa: rilegge cosa è successo nella sessione, decide cosa va salvato e in quale dei sei file, scrive le modifiche e aggiorna la freschezza. Il punto delicato è uno solo: deve chiederti conferma prima di scrivere, mai modificare la memoria di testa sua. La memoria sbagliata è peggio della memoria mancante.

Come parti da zero, in tre passi

Se vuoi costruirtelo, non partire dai sei file insieme. Parti da STATE e basta: scrivi in mezza pagina dove sei adesso, e fai leggere quello all’agente prima di ogni sessione. Quando STATE inizia a gonfiarsi di cose stabili, sposta quelle in MEMORY. Quando ti accorgi che ripeti all’agente dove trovare le cose, nasce l’INDEX. Il sistema cresce per necessità, un file alla volta, non perché te l’ha detto un post. Compreso questo.

Chiudo tornando alla scena dell’inizio, perché il punto è tutto lì.

Quella sessione di lunedì è nata vuota come tutte le altre. Non si ricordava niente di me, e va benissimo così: non è il suo lavoro ricordare. È il mio lavoro tenere la memoria nei posti giusti, e il suo leggerne il minimo per sapere dove siamo. Tre milioni di parole sotto, meno di cinquecento per orientarsi. Non ho reso l’AI più intelligente. Ho organizzato quello che le do da leggere, e ho smesso di pagarla per annegare.

E credo sia questa la domanda vera di chi costruisce sistemi invece di rincorrere l’ultimo trucco: non “quanta roba riesco a darle in pasto”, ma “quanto poco le basta leggere per fare la cosa giusta”. La prima la stanno facendo tutti, e si stupiscono che l’AI rallenti. La seconda la fanno in pochi, ed è quella che trasforma un magazzino in una memoria.

Se queste cose ti servono, iscriviti: ogni mercoledì esce un sistema completo come questo, gratis per i primi giorni. Dal 1° luglio i deep dive operativi diventano roba da Maikers Paganti, cinque euro al mese, e chi entra prima parte col prezzo migliore.

Iscriviti ora

Tu come tieni la memoria del tuo lavoro quando usi l’AI? Un megafile, dieci note sparse, niente? Scrivimelo nei commenti, i casi più interessanti li riprendo in un prossimo post.

Lascia un commento

E se conosci qualcuno che ha buttato tutto dentro Obsidian e adesso non ci trova più niente, manda questo post: è esattamente per chi è in quella fase.

Condividi

Ivan Mosetti · Marketers di Giorno · Nerd AI di Notte · ivanmosetti.ai

PROMPT PER FAR AGGIORNARE LA MEMORIA ALL’AGENTE DOPO IL PAYWALL

Read more

Due file. Meno di tremila parole. Dentro un second brain che di parole ne contiene più di tre milioni.

Questo post è la storia di quei due file, STATE.md e TASKS.md. Se mi leggi da un po’ conosci già i tre file che fanno funzionare un agente AI, CLAUDE.md con le regole, MEMORY.md con l’identità, log.md con la storia. Questi due non li sostituiscono e non valgono di più: sono il quarto e il quinto della stessa famiglia, e il loro mestiere specifico è tenere il contesto aggiornato e dettagliato, settimana per settimana, giorno per giorno.

In sintesi. STATE.md è la fotografia dello stato corrente del tuo second brain: decisione strategica, sprint, alert. TASKS.md è il backlog operativo: cosa è urgente ora, cosa viene dopo, cosa è stato chiuso. Un agente AI tipo Claude li legge per primi a ogni sessione e si orienta in meno di tremila parole, senza rileggere il vault intero.

Questo post è figlio della guida completa a Cowork che ho pubblicato a inizio mese: lì c’è la mappa di tutto il sistema, qui scendiamo in una stanza precisa. Se non l’hai letta, parti da lì.

La guida completa a Cowork (2026)

Il problema, ogni sessione nuova ricominciava da zero

Ti racconto dove ero a inizio maggio, perché se hai un second brain che cresce ci arriverai anche tu.

Il mio vault oggi conta quasi cinquemila file markdown. Clienti, progetti, decisioni, log, strategie, bozze. Tre milioni e duecentomila parole, le ho contate. Ed era tutto in ordine: cartelle PARA, note che si linkano, niente caos. Il problema non era l’ordine. Il problema era che un modello AI, davanti a tutto quell’ordine, non sa da dove cominciare.

Perché c’è un fatto tecnico che dimenticano tutti nei tutorial sul second brain: la finestra di contesto di un modello è finita. Claude arriva a gestire fino a un milione di token, che letti così sembrano infiniti. Il mio vault, convertito in token, ne occupa più di quattro volte tanto. Non ci sta. E c’è il dettaglio che conta ancora di più: la finestra non conviene nemmeno riempirla, perché già intorno al 70% di riempimento l’output comincia a degradare. Più contesto inutile dai al modello, più diluisci quello che conta, e le risposte peggiorano invece di migliorare.

Quindi ogni sessione nuova faceva la stessa scena. Claude apriva l’indice, poi la memoria generale, poi un log, poi un altro log, e dopo qualche minuto di esplorazione mi chiedeva conferma di cose che nel vault erano già scritte. Ogni chat ripartiva da zero, come un collaboratore nuovo al primo giorno, ogni giorno. I token se ne andavano in orientamento invece che in lavoro. E io pagavo due volte: in attesa e in qualità.

La cosa che mi ha fatto scattare la decisione è stata accorgermi che stavo rispiegando a Claude lo stato dei miei clienti per la quarta volta in una settimana. Quando rispieghi la stessa cosa quattro volte, il problema non è il modello. È che manca un sistema.

Il principio, la memoria ha tre velocità

La soluzione l’ho costruita partendo da un’osservazione semplice: non tutta la conoscenza di un second brain invecchia alla stessa velocità.

C’è la conoscenza stabile. Chi sono, come lavoro, chi sono i miei clienti, le regole del vault. Cambia ogni mese, forse. Nel mio sistema vive in MEMORY.md, e di quella ho già scritto: è uno dei tre file del PDF che regalo ai nuovi iscritti.

Poi c’è lo stato. Qual è la priorità di questo trimestre, a che punto è lo sprint di questa settimana, quali allarmi sono accesi. Cambia ogni settimana. E prima non viveva da nessuna parte: era spalmato nei log, nelle chat vecchie e nella mia testa.

Poi c’è l’azione. Cosa devo fare oggi, cosa può aspettare, cosa ho chiuso ieri. Cambia ogni giorno.

Tre velocità diverse. E se metti informazioni a tre velocità nello stesso file, succede quello che succedeva a me: per trovare la cosa che cambia ogni giorno, il modello rilegge anche tutto quello che non cambia mai. Il sistema PARA che uso per le cartelle l’ho raccontato in [Claude + Obsidian + PARA](URL post 27/4): quella è la libreria, ed è perfetta per archiviare. Ma una libreria non ti dice a che pagina eri rimasto. Serviva un livello sopra.

Così ho aggiunto due file alla radice del vault, uno per velocità mancante.

STATE.md è la fotografia del presente. Risponde alla domanda “dove siamo adesso”. Dentro ci sono cinque cose, sempre le stesse: la decisione strategica corrente, lo snapshot delle aree di lavoro, lo sprint della settimana, le lezioni più importanti che ho imparato, gli alert attivi. Non è un diario: si sovrascrive. La versione vecchia non interessa a nessuno, per la storia ci sono i log.

TASKS.md è il backlog operativo. Risponde alla domanda “cosa devo fare”. Quattro sezioni: Now, le cose dello sprint corrente. Next, le prossime settimane. Later, il trimestre e oltre. Done, quello che ho chiuso negli ultimi sette giorni, poi si cancella e la storia resta nei log.

E poi c’è la regola che tiene insieme tutto, la più importante: questi due file sono always-load. Qualsiasi sessione, mia o di un agente, li legge prima di fare qualsiasi cosa. Sempre. È scritto nelle istruzioni del vault. Due letture, e il modello sa dove siamo e cosa serve. Solo dopo, se la richiesta lo richiede, scende in profondità nelle cartelle giuste.

Cos’è STATE.md, la fotografia del presente

STATE.md è un file markdown che vive alla radice del second brain e contiene lo stato corrente del sistema: la decisione strategica in vigore, lo sprint della settimana, gli allarmi aperti. Un agente AI lo legge a inizio sessione e sa dove si trova, senza esplorare il resto del vault.

Ti faccio vedere come è fatto il mio, anonimizzando quello che va anonimizzato.

In testa c’è la decisione master corrente: la priorità strategica che ho scelto e l’ordine delle cose. Una decisione presa una volta, scritta una volta, che ogni sessione rispetta senza che io la ripeta. Quando a fine maggio ho cambiato priorità tra i miei progetti, l’ho cambiata lì, una riga, e da quel momento ogni chat ragionava con la testa nuova.

Poi lo snapshot delle aree: una tabella corta, un’area per riga, status e focus corrente. La mia agenzia, il laboratorio AI, il personal brand, il personale. Quattro righe.

Poi lo sprint corrente: la settimana in corso, cosa è partito, cosa è in attesa, cosa è arrivato. È la sezione che cambia di più e quella che vale di più: è la differenza tra un assistente che sa cosa è successo e uno a cui devi fare il riassunto a voce.

Poi le lezioni top: le dieci cose più care che ho imparato, distillate in una riga ciascuna. Tipo che un lead silenzioso da quattordici giorni va archiviato senza pietà, o che i dati di fatturato dichiarati a memoria divergono sempre da quelli del conto. Sono lì perché il modello le applichi, non perché io le rilegga.

E infine gli alert: i rischi accesi adesso. Nel mio, oggi, c’è un cliente importante in pausa per cause di forza maggiore, con l’impatto sul fatturato ricorrente scritto in chiaro. E c’è il fatto che tre clienti pesano i tre quarti del ricavo mensile dell’agenzia, che è un rischio di concentrazione che ogni nuova decisione commerciale deve tenere a mente. Quando è scoppiato il caso del cliente in pausa, l’ho scritto una volta nell’alert: da lì in poi ogni sessione, anche quelle aperte dai miei soci, lo sapeva. Nessun passaggio di consegne, nessun “ah ma non te l’avevo detto”.

Il mio STATE.md è lungo milleottocento parole. Tutto qui. È il file più denso del vault e probabilmente il più letto.

Cos’è TASKS.md, il backlog che l’AI legge prima di lavorare

TASKS.md è il secondo file, e funziona da unica fonte di verità per le cose da fare. Quattro sezioni in ordine di urgenza, e ogni task scritta in un modo preciso: non solo il titolo, ma il perché esiste e che risultato deve produrre.

Questa è una task vera del mio file di questa settimana, leggermente ripulita:

- [ ] T4, Consolidare fatturato YTD 2026 per monitor target annuale · scadenza 7/6
  - Why: la review mensile è fatta, ma senza il dato da inizio anno
    il target resta non monitorabile
  - Esito atteso: riga YTD vs target dentro la memoria finanza

Il “why” e l’”esito atteso” non sono burocrazia. Sono lì per il modello: una task con il perché dentro è una task che un agente può portare avanti da solo senza farmi domande a cui ho già risposto. E quando una task è chiusa, va in Done, ci resta sette giorni perché le sessioni della settimana la vedano, e poi sparisce. La storia completa vive nei log delle cartelle, non nel backlog. Un backlog che accumula storia diventa un archivio, e un archivio che si finge backlog è il modo più veloce per smettere di guardarlo.

C’è un’ultima regola che ho aggiunto da poco, dopo essermi accorto che certi task giravano nella sezione Now per giorni senza che succedesse niente: se una task sta in Now da tre giorni, scatta una decisione forzata. O la chiudo entro ventiquattro ore, o la sposto giù. Niente terza via. Il sistema me lo segnala da solo con un piccolo flag, ed è una delle automazioni più stupide e più utili che ho.

Come li ho costruiti, passo passo

Adesso la parte pratica, perché questi due file li puoi creare oggi pomeriggio. Non serve codice, non serve nessun tool particolare: serve un editor di markdown e mezz’ora di onestà su come stanno le cose.

Il primo passo è creare STATE.md alla radice del tuo vault, o della cartella dove lavori con l’AI. Cinque sezioni, quelle che hai visto sopra: decisione corrente, snapshot delle aree, sprint della settimana, lezioni, alert. La prima compilazione è la più faticosa perché ti obbliga a rispondere a domande che di solito rimandi: qual è davvero la priorità adesso? quali rischi sono accesi? Scrivilo come lo diresti a un socio che torna da un mese di ferie.

Il secondo passo è TASKS.md, stessa posizione. Quattro sezioni: Now con le cose di questa settimana, e tienile poche, tre o cinque, non quindici. Next col mese. Later col trimestre. Done vuota, si riempie da sola. Ogni task con il suo why e il suo esito atteso.

Il terzo passo è la regola di carico, ed è quello che trasforma due file in un sistema. Nelle istruzioni che il tuo agente legge sempre (in Cowork è il CLAUDE.md della cartella, ma il principio vale ovunque) scrivi che STATE.md e TASKS.md vanno letti prima di qualsiasi operazione, e che l’orientamento deve costare al massimo quelle due letture. Io l’ho scritta così, e da quel momento ogni sessione parte già calda.

Il quarto passo sono le cadenze, perché un file di stato non aggiornato è peggio di nessun file: mente con autorevolezza. La mia regola è semplice: STATE.md si aggiorna la domenica, al check-in settimanale, e ogni volta che cambia una decisione importante. TASKS.md si tocca quando le priorità cambiano, anche tutti i giorni. La domenica sono dieci minuti, non di più, perché stai sovrascrivendo una fotografia, non scrivendo un report.

Il quinto passo arriva solo quando il sistema cresce, e te lo dico per completezza: i file di stato si possono moltiplicare per livello. Nel mio vault oggi ci sono quattordici STATE.md e sedici TASKS.md: uno alla radice, uno per area di lavoro, uno per ogni cliente importante. Quello alla radice tiene solo le cose trasversali, quelli di area tengono la loro parte di mondo. Ma questo è il passo cinque, non il passo uno. Se il tuo vault ha cento file, il root basta e avanza.

In fondo al post, prima del paywall che arriva tra qualche giorno, trovi il prompt completo che puoi dare a Claude per generare la prima versione dei due file leggendo il vault che hai già.

Il caso, orientarsi in tremila parole dentro tre milioni

Ti do i numeri veri, misurati sul mio vault sabato mattina, perché senza numeri questo resta un discorso di filosofia della produttività.

Il vault: 4.964 file markdown, 3.218.798 parole. Il mio STATE.md di root: 1.822 parole. Il TASKS.md: 908. Totale dell’orientamento: 2.730 parole, circa tremilacinquecento token. Vuol dire che una sessione nuova si orienta consumando una frazione minuscola della finestra, lontana anni luce da quel settanta per cento oltre il quale la qualità cala, e tutto il resto rimane libero per il lavoro vero.

Prima di questi due file, l’orientamento passava da tre letture diverse, l’indice, la memoria generale, le regole operative, e dopo quelle tre letture il modello sapeva chi ero ma non sapeva ancora dove eravamo: lo stato della settimana stava sparso nei log, e per ricostruirlo doveva aprirne due o tre, col rischio di pescare quello vecchio. Adesso la sequenza è: due file, poi dritto al lavoro.

Ma il risparmio di token, te lo dico onestamente, è il beneficio minore. Il beneficio maggiore è la qualità delle risposte. Un modello che parte da un contesto piccolo, denso e aggiornato sbaglia meno di uno che parte da un contesto grande, diluito e di cui non sa cosa è ancora valido. Quando ho chiesto a Claude di valutare un preventivo nuovo, la risposta ha tenuto conto da sola del rischio di concentrazione scritto nell’alert. Non gliel’ho ricordato io. L’ha letto, perché stava nel posto dove legge sempre.

E c’è il beneficio che non avevo previsto: i due file funzionano anche per gli umani. Quando torno da tre giorni fuori, la domenica sera, leggo il mio stesso STATE.md e mi rimetto in carreggiata in cinque minuti. Il file che avevo scritto per l’AI è diventato il modo in cui io stesso rientro nel mio lavoro.

Gli errori che ho fatto, così non li fai tu

Quattro errori, tutti miei, tutti già pagati.

Il primo: all’inizio STATE.md mi è cresciuto in mano come un secondo MEMORY.md. Ci finiva l’identità, la storia, il contesto dei clienti, tutto. Sbagliato. La regola che mi ha salvato è brutale: ogni informazione vive in un solo file, gli altri al massimo la linkano. Se un fatto sta sia in STATE che in MEMORY, è un bug, e prima o poi le due versioni divergono e il modello pesca quella sbagliata. STATE tiene solo quello che cambia ogni settimana.

Il secondo: trattarlo come un diario. Le prime settimane aggiungevo righe sotto le righe vecchie, e il file si allungava invece di restare una fotografia. Un file di stato si sovrascrive. Fa male le prime volte, sembra di buttare via lavoro, poi capisci che la storia non è persa: sta nei log, che esistono apposta.

Il terzo: il backlog che non si svuota. Task chiuse che restavano in Done per settimane, task aperte che galleggiavano in Now senza decisione. Un backlog sporco è un backlog che il modello smette di rispettare, perché impara che metà delle cose scritte lì non contano. Da qui le due regole: Done si pulisce dopo sette giorni, e la task ferma in Now da tre giorni esige una scelta.

Il quarto, il più subdolo: aggiornare “quando mi ricordo”. Ho avuto un periodo in cui lo snapshot girava vecchio di dieci giorni, e me ne sono accorto solo quando le risposte hanno cominciato a basarsi su uno stato superato. Per questo la cadenza è fissa, la domenica, agganciata a un rito che esiste già. Un file di stato è buono quanto la sua data di aggiornamento, e infatti la data sta scritta in cima al file, la prima cosa che si vede.

Da qui in poi entriamo nella parte operativa pura: i template completi di STATE.md e TASKS.md, sezione per sezione con i commenti su come compilarli, le regole di aggiornamento e come adattarli se lavori da solo o con un team. È la parte che tengo per chi sostiene questo lavoro. Resta aperta a tutti ancora per pochi giorni, poi chiude dietro il paywall, quindi se la vuoi leggere intera fallo adesso.

Iscriviti ora

Deep dive, i template completi di STATE.md e TASKS.md

Quello che hai letto fin qui è il perché e il come ad alto livello. Questa parte è il copia-incolla: i due template che uso davvero, commentati riga per riga, più le regole per tenerli vivi. L’obiettivo è che stasera i due file esistano nel tuo vault.

Read more

Il gestionale di Mainstream parla con la squadra in linguaggio naturale. Cos’è, come l’ho collegato, il protocollo che uso per non fare danni.

Lunedì ti ho portato dentro Cowork e ti ho fatto vedere la teoria: cos’è, come ci ragiono, i cinque sistemi che ci faccio girare ogni giorno. Era la mappa. Oggi scendo in uno dei territori, quello più scomodo da spiegare e più utile da capire, e ti faccio vedere come funziona davvero un sistema dall’inizio alla fine.

Il sistema è questo: ho collegato il gestionale operativo della mia agenzia a Claude, dentro Cowork, costruendo un connettore MCP tutto mio. Lo uso ogni mattina. Lo usano i miei soci. Lo usano i collaboratori. E la cosa interessante non è “Claude apre il gestionale”, quella è la copertina. La cosa interessante è quello che succede sotto, quando il contesto del lavoro smette di vivere nella mia testa e nella mia cartella e diventa una cosa che la squadra può operare parlando.

Se non hai letto la guida Cowork di lunedì, parti da lì, questo post è il piano di sotto di quella casa.

Lunedì ho scritto la mappa completa di come uso Cowork, con i cinque sistemi e la regola dei permessi. Se sei capitato qui prima, leggi quella, così oggi non ti perdi nei dettagli.

Guida Completa a Cowork >

Il problema, il tuo second brain muore nella tua testa

Ti racconto dove eravamo, perché il problema lo conosci anche tu se hai mai provato a far funzionare un sistema personale dentro un team.

Per mesi ho avuto il mio second brain in ordine. Cartelle PARA, ogni cliente al suo posto, note che si linkano, decisioni tracciate. Funzionava benissimo. Per me. Il guaio è che un second brain personale è esattamente quello che dice il nome: personale. Vive in due posti, la mia testa e il mio Obsidian, e nessuno dei due è un posto dove un socio può entrare alle nove del mattino e capire a che punto è un cliente.

Così succedeva la cosa classica. Il dato operativo vero, lo stato di un preventivo, chi sta seguendo quel task, a che stage è quel lead, viveva in un terzo posto ancora: il gestionale dell’agenzia. E tra il mio cervello, la mia cartella e il gestionale c’era un buco. Io sapevo le cose ma le sapevo a modo mio. Il gestionale aveva i numeri ma bisognava andarci dentro, cliccare, filtrare, esportare. La squadra aveva metà del quadro ciascuno.

Il problema non era la mancanza di strumenti. Di strumenti ne avevo troppi. Il problema era che il contesto non era condiviso e non era operabile. Per sapere come stava un cliente prima di una call dovevo aprire quattro schede e ricostruire la storia a mente. Per fare un preventivo dovevo saltare dal listino alla mail al gestionale. Ogni volta la conoscenza la ricostruivo, non la consultavo.

E quando una cosa la ricostruisci ogni volta, quella cosa non è un sistema. È una fatica che si ripete.

Cos’è Agency OS, il posto dove vive il lavoro

Partiamo dalle basi, così ci capiamo.

Agency OS è il gestionale operativo di Mainstream, la mia agenzia a Roma. Non è un tool che ho comprato e basta, è il posto dove vive il lavoro: tiene nove domini, e dentro quei nove domini c’è praticamente tutto quello che fa girare un’agenzia. L’agenzia e gli utenti, i clienti, i progetti, i task, il listino dei servizi, i preventivi, i lead con la loro pipeline, le call, e una inbox operativa.

Tradotto: è il database della verità. Quando un preventivo è stato accettato, è scritto lì. Quando un task passa a un collaboratore, è lì. Quando un lead si muove di stage, è lì. Non nella mia testa, non in una nota, non in una chat persa. Lì.

Il punto debole, come ti dicevo, era l’accesso. Un gestionale è preciso ma è muto. Ti dà i dati se vai a prenderli con il mouse, uno alla volta, nel suo linguaggio. E un sistema che parla solo se lo interroghi a mano è un sistema che la squadra usa poco, perché costa attenzione. Volevo che il gestionale rispondesse quando gli parli normale. “Come sta questo cliente.” “Cosa ho oggi.” “Fammi il preventivo partendo dal listino.” In italiano, non a clic.

Per quello serviva un ponte. E il ponte è un MCP.

Come l’ho collegato, un plugin MCP non un wrapper artigianale

Qui entriamo nella parte costruttiva, quella che mercoledì ci piace.

Ho costruito un plugin per Cowork che si chiama agency-os. Non opera il gestionale facendo finta di essere un umano che clicca, lo opera via un server MCP remoto, ospitato su un indirizzo della mia agenzia. MCP, se lunedì te lo sei perso, è il protocollo che fa parlare Claude con un sistema esterno in modo strutturato: niente automazioni fragili che si rompono quando l’interfaccia cambia, ma una superficie di strumenti precisi che il modello sa chiamare.

Tre cose lo rendono solido, e sono le tre cose che alzano la qualità da “smanettone” a “sistema”.

La prima è l’autenticazione. Niente API key da copiare e incollare e tenere in giro come una chiave sotto lo zerbino. È OAuth: ti colleghi una volta, autorizzi, e da quel momento Cowork parla col gestionale a nome tuo, con i tuoi permessi. È la differenza tra dare a qualcuno una copia della chiave di casa e fargli usare il citofono.

La seconda è la superficie. Il plugin espone cinquantacinque strumenti, tutti con lo stesso prefisso mcp__agency-os__, divisi nei nove domini di prima. Ci sono le letture, quelle che cominciano con list_ e get_, che ti restituiscono lo stato delle cose. E ci sono le scritture, create_, update_, send_quote, accept_quote, quelle che cambiano qualcosa di vero. Tienile a mente queste due famiglie, perché tra un attimo è su quella distinzione che si gioca tutta la sicurezza del sistema.

La terza è la cosa che fa la differenza, ed è il motivo per cui dico che è un plugin e non un mucchio di strumenti grezzi. Insieme ai cinquantacinque tool ho impacchettato un bundle. Tre skill, che sono il manuale di comportamento del sistema: una si chiama agency-os-expert e contiene gli enum reali del database, i permessi, i workflow corretti, e Claude la consulta prima di scrivere qualsiasi cosa, così non inventa campi che non esistono; una fa i preventivi end-to-end dal listino fino al link pubblico; una genera il report aggregato di un cliente mettendo insieme salute, progetti, task aperti, call e preventivi. Poi c’è un subagent, l’operatore, che esegue i task multi-step da solo dall’inizio alla fine. E sei comandi rapidi che richiamo a colpo: agenzia, cliente, daily, listino, pipeline, task.

Non è un wrapper. È la stessa lezione che ho raccontato a maggio quando ho scritto della fine dei wrapper: il valore non è nascondere un’API dietro un bottone, è dare al modello il contesto, le regole e i workflow per usarla bene. Un wrapper esegue. Un bundle ragiona.

A maggio ho scritto perché l’era dei wrapper artigianali è finita e cosa la sostituisce. Agency OS è esattamente quel principio applicato a un gestionale vero. Se vuoi capire da dove arriva questo modo di costruire, leggi quello prima, è la teoria sotto a questo caso.

Leggi “Meta Ads MCP” →

Come lo uso, il protocollo che mi impedisce di fare danni

Adesso la parte che conta più di tutte, perché qui non stiamo giocando con un blog di prova. Qui si tocca roba che ha conseguenze: preventivi che vanno a clienti veri, task assegnati a persone vere, stati di lead che spostano la pipeline commerciale.

Quando un sistema può scrivere su cose vere, la domanda non è più “funziona”, è “funziona senza che io mi svegli una mattina con un preventivo sbagliato già partito”. E la risposta è un protocollo. Lo chiamo bozza, approvazione, import, e gira sempre uguale, quattro passi, nessuno saltabile.

Primo passo, raccolgo i campi. Se manca un prezzo, una data, una partita IVA, un owner, Claude me li chiede, una domanda alla volta. Non si inventano. Un gestionale popolato di numeri immaginati è peggio di un gestionale vuoto, perché il vuoto lo vedi e il falso no.

Secondo passo, la bozza. Prima di toccare il gestionale, il sistema scrive un file markdown nel second brain, nella cartella giusta del cliente o del lead, con tutti i campi valorizzati e accanto la chiamata MCP che intende fare. È la cosa che sta per succedere, scritta nero su bianco, prima che succeda. E aggiorno il log, così resta traccia.

Terzo passo, l’approvazione. Quella bozza la guardo io. Niente import senza un ok chiaro e mio. Non un “vai bene”, un sì esplicito su una bozza che ho letto.

Quarto passo, l’import. Solo dopo l’ok il sistema esegue le chiamate, crea le cose, e annota gli id generati tornando ad aggiornare il log. Così a fine giornata so esattamente cosa è entrato, quando, e partendo da quale bozza.

Sembra macchinoso quando lo scrivo. Nella pratica sono trenta secondi di lettura in cambio di non dover mai disfare un errore su un cliente. È il rapporto di scambio migliore che conosca.

E poi ci sono gli usi quotidiani, quelli leggeri, che non scrivono niente e quindi non hanno bisogno di tutto questo. La mattina lancio il comando daily e ho il riepilogo della giornata, task, scadenze, segnali, senza aprire niente. Prima di una riunione commerciale lancio pipeline e vedo lo stato dei lead, gli stage, i preventivi in giro. Prima di una call con un cliente lancio il report cliente e ho la storia aggregata in un foglio solo, invece delle quattro schede da ricostruire a mente. E quando serve un preventivo, parto dal listino e arrivo ai line item con i testi già scritti, il link pubblico pronto, il monitoraggio attivo, dentro lo stesso flusso bozza, ok, import.

La regola sotto a tutto è semplice ed è la stessa di lunedì. Leggere è libero. Scrivere chiede conferma. Solo che qui, dove le scritture toccano clienti veri, la regola è ancora più rigida: ogni create_, ogni update_, ogni send, ogni accept passa dal protocollo. È la versione agenzia della lezione che ti ho raccontato sulla mappa. Lì era una buona abitudine. Qui è la cosa che tiene in piedi la fiducia tra me e il sistema.

Il caso, quando il gestionale ha smesso di essere solo mio

Ti porto un numero, perché senza numeri questi discorsi restano belle parole.

Nelle ultime settimane sono passati per il flusso MCP 27 task operativi, creati e assegnati alla squadra parlando invece che cliccando. Non è il numero in sé a contare, un gestionale di task li conta da solo. Conta dove sono stati creati: dentro la stessa conversazione in cui stavo ragionando sul cliente. Mentre preparavo una review, i task di follow-up nascevano dal ragionamento, non da un secondo momento amministrativo in cui mi ricordo di aprire il gestionale e battere a mano quello che avevo già deciso.

Questo ha cambiato una cosa precisa. Prima il lavoro amministrativo era una tassa che pagavo dopo aver pensato. Decidi le cose nella testa, poi le trascrivi nel sistema. Due fasi, e la seconda la rimandi, e quando la rimandi il sistema si svuota di verità. Adesso pensare e registrare sono la stessa fase. Decido e il sistema lo sa, perché l’ho deciso parlando con il sistema.

Ma il salto vero non sono i task. È che i miei soci e i collaboratori lavorano sullo stesso identico contesto. Quando uno di loro lancia il report di un cliente, vede quello che vedo io, aggiornato, senza che io abbia dovuto fare un passaggio di consegne. La conoscenza ha smesso di morire nella mia cartella. È diventata un posto in cui si entra, si chiede, si opera, in linguaggio naturale, tutti.

Il second brain personale risolveva un problema mio. Questo risolve un problema della squadra. È la differenza tra avere ordine in testa e avere ordine condiviso.

Gli errori che ho fatto, così non li fai tu

Tre cose le ho sbagliate prima di arrivare al protocollo pulito, e te le dico perché sono esattamente le tre in cui cadrai se provi a fare la stessa cosa.

Il primo errore è stato dare al sistema il permesso di scrivere subito, senza la bozza in mezzo. La tentazione è fortissima: funziona, perché non lasciarlo fare. Il guaio è che quando funziona al novanta per cento, il dieci per cento sbagliato finisce su un cliente, e disfare una scrittura su un sistema operativo è molto più costoso del leggere una bozza di trenta secondi. La bozza non è burocrazia, è l’unico punto in cui un errore costa zero perché non è ancora successo.

Il secondo errore è stato lasciare che inventasse i campi mancanti. Un modello, se non gli chiedi di fermarsi, riempie i buchi con qualcosa di plausibile. E un dato plausibile e falso in un gestionale è una bomba a orologeria, perché ha l’aria di essere vero. La regola “una domanda alla volta, non si inventa niente” non è gentilezza verso l’utente. È igiene del dato.

Il terzo errore è stato pensare che bastassero i tool. I cinquantacinque strumenti da soli sono un cassetto di chiavi inglesi senza istruzioni. Senza la skill che contiene gli enum reali e i workflow corretti, il sistema usava lo strumento giusto nel modo sbagliato. Il bundle, le skill, il subagent, non sono un di più, sono la parte che fa la differenza tra uno strumento e un sistema.

Da qui in poi entriamo nella sala macchine: la struttura completa del plugin agency-os, come è fatto dentro, e come puoi costruirne uno tuo sopra il tuo gestionale. È la parte che tengo per chi sostiene questo lavoro. Resta aperta a tutti ancora per pochi giorni, poi chiude dietro il paywall, quindi se la vuoi leggere intera fallo adesso.

Iscriviti ora

[PAYWALL] Deep dive, la struttura completa del plugin agency-os

Quello che hai letto fin qui è il “cosa” e il “perché”. Questa parte è il “come è fatto dentro”, e serve per una cosa sola: che tu possa costruire un plugin MCP sopra il tuo gestionale, qualunque sia, senza ripartire dai miei stessi errori. Per leggerla serve essere abbonati a pagamento.

Read more

A sinistra ho un terminale aperto con Claude Code. Sta facendo un commit di quattordici file modificati nelle ultime quattro ore, sta aggiornando tre log.md di area, sta pushando tutto su GitHub. A destra ho Cowork Desktop aperto su un Project che si chiama “ Bozze Substack”, dove sto leggendo l’idea della settimana che è arrivata nel calendario stamattina. I due strumenti non si parlano. Non devono.

Per cinque mesi li ho usati a caso. Aprivo Cowork per scrivere e poi mi accorgevo che dovevo fare un backup su github, e iniziavo a copiare comandi nella chat. Aprivo Claude Code per riorganizzare una cartella e dopo dieci minuti mi ritrovavo a fargli scrivere bozze di articoli che poi dovevo riportare a mano nel vault. Risultato: chat sparse, contesto sbagliato, scaffolding perso, tempo bruciato a fare due lavori dentro un solo strumento.

Oggi ti racconto la regola che uso da una settimana. È breve, è scomoda, è la prima che funziona davvero per me. E ti faccio vedere il pezzo di codice che la rende “invocabile” con uno slash /.

Il problema vero, prima della regola

C’è un equivoco di base che ho visto fare a tutti i marketer italiani che provano a portare l’AI nel proprio lavoro, me compreso fino a maggio. L’equivoco è pensare che “Claude” sia uno strumento. Non lo è. Anthropic ha fatto una scelta architetturale precisa nel 2026 e ha rilasciato tre interfacce diverse sopra lo stesso modello: Claude.ai per la chat web, Cowork Desktop per il lavoro continuativo sul filesystem, Claude Code nell’app desktop o come terminale agentico. Sembrano la stessa cosa perché sotto c’è lo stesso cervello. Ma fanno mestieri diversi, hanno strutture dati diverse, vivono in posti diversi del tuo Mac. Trattarli come intercambiabili è come usare il martello al posto del cacciavite perché sotto sotto sono entrambi attrezzi.

Lo dico perché l’ho fatto. Ho passato le prime settimane aprendo l’uno o l’altro a casaccio. Apri quello che hai in dock. Apri quello che ti suggerisce il browser. E ti accorgi che stai facendo lo stesso lavoro dentro due interfacce diverse, perdendo metà del valore di entrambe.

Il momento in cui ho dovuto smettere è arrivato verso fine aprile, una sera. Stavo preparando il materiale per una cliente Academy, una consulente del lavoro che doveva avere il suo Second Brain montato in due ore di sessione live. Per giorni avevo redatto il programma dentro un Project Cowork. Bello, ragionato, anche bene strutturato. Però il giorno dell’erogazione mi sono accorto che il programma chiedeva alla cliente di copiare diciotto comandi mkdir in un terminale, e in quel terminale c’era Claude Code. Il programma costruito dentro Cowork descriveva un workflow che usava Claude Code. Due ore di sessione live impostate su uno strumento che il mio strumento non sapeva eseguire.

L’ho riscritto in una sera. Ho cambiato lo stack: niente più comandi mkdir da copiare a mano, Claude Code scrive direttamente il filesystem, la cliente vede i file comparire dentro Obsidian aperto a fianco, in tempo reale. Niente più Project Cowork in cui ragionare di filesystem. Cowork resta per le chat focalizzate per area, Claude Code prende il filesystem.

La regola è uscita da lì. La scrivo qui asciutta, prima di entrare nei dettagli.

Claude Code costruisce. Cowork pensa.

Tutto il resto è applicazione di questa frase.

La tabella secca

Tieni questa a portata. È il filtro pratico che uso ogni volta che sto per aprire uno dei due strumenti. Quando devo fare qualcosa, mi chiedo prima a quale famiglia appartiene: è un’azione concreta sui file e sui comandi del computer, oppure è un ragionamento, una scrittura, una decisione? Da lì la scelta diventa automatica.

Tutto quello che mette le mani sul vault va in Claude Code. Creare cartelle, spostare file, cancellare roba vecchia, scrivere su un file, lanciare uno script Python, fare un commit su Git, installare una skill, generare un PDF brandizzato con uno script Python. Sono le operazioni in cui c’è un risultato tangibile sul disco, oppure un comando da eseguire nel terminale. Claude Code ha le mani per farlo, e le sa usare bene.

Tutto quello che gira intorno al pensare, allo scrivere, al decidere va in Cowork. Il drafting di un articolo Substack o di un post LinkedIn. Il ragionamento sulla strategia di un’area, che sia l’agenzia Mainstream, MAIKER o il Personal Brand. L’apertura di un Project con la knowledge già caricata, così non devo spiegare ogni volta da capo il contesto.

Il brainstorm quando ho un’idea grezza e mi serve una prima passata di angolazioni. L’aggiornamento conversazionale di un MEMORY.md di area, quando devo capire insieme a Claude cosa è cambiato e come riassumerlo. E il triage rapido delle idee in arrivo, quando arriva una nota da capire prima di salvarla nel posto giusto.

Cosa significa “costruisce”

Claude Code fa quattro mestieri, e li fa meglio di qualsiasi cosa avessi prima.

Il primo è operazioni sul filesystem. Quando devo creare un vault da zero per una cliente Academy, la sintassi che uso è una sola riga: gli dico “scaffolda la struttura PARA con cinque aree, ogni area con CLAUDE, MEMORY e log, e un bucket _system/skills/ vuoto”. Il tempo che ci avrei messo io a lavorare su tutte le cartelle, non los o, invece Claude Code lo fa in quaranta secondi e non sbaglia.

Il secondo è scaffolding di sistemi nuovi. Sabato nove maggio ho impostato l’agente domenicale del sistema editoriale di cui ti ho scritto la settimana scorsa. L’ho fatto dentro Claude Code: una conversazione che è partita da “voglio un agente che legga i log delle aree e mi proponga tre idee per i tre format Substack” ed è finita con un agente vero, un system prompt strutturato salvato dentro _System/agents/, una skill orchestratrice in _system/skills/. Avrei potuto farlo in Cowork. Cowork mi avrebbe lasciato uno splendido documento di design. Claude Code mi ha lasciato un sistema che gira.

Il terzo è git e GitHub. Questo è il pezzo che ho sottovalutato per troppo tempo. Il vault è versionato. Ogni operazione di chiusura giornata è un commit. Ogni cliente nuovo è un branch o un sottoalbero protetto da .gitignore aggressivo per i dati sensibili. Questo lavoro Claude Code lo fa nativo: legge git status, scrive il commit message in italiano con il formato che ho deciso io (chore(sync): YYYY-MM-DD — sintesi), risolve i conflitti chiedendomi se ha dubbi, pusha sul repository GitHub privato. Cowork non vede git. Non è progettato per vedere git. Continuare a usarlo per quello è una scelta da pizzaiolo che usa il microonde.

Il quarto è eseguire skill locali. Questo merita un movimento a parte, perché è anche il tutorial concreto di oggi. Lo vediamo tra poco.

Se stai leggendo questo senza essere ancora iscritto al free, fallo adesso. Dal primo luglio i post del mercoledì come questo entrano dietro paywall, e tre giorni di ritardo per i lettori non paid sono la nuova regola. Iscriverti adesso ti porta in lista d’attesa per i venticinque posti Founding a prezzo lifetime, quando lancio.

Iscriviti ora

Cosa significa “pensa”

Cowork fa l’opposto, e lo fa bene. Tre mestieri principali.

Il primo è chat focalizzate per area. Dentro Cowork creo un Project per ogni cartella significativa del vault. Master Project che vede tutto. Project Substack che vede solo 2-Areas/personal-brand/2-areas/substack/. Project Mainstream che vede solo 2-Areas/mainstream-agency/. Project per ogni cliente attivo dell’agenzia. La differenza con una chat generica è che il Project carica solo il contesto giusto: aprendo “Personal Brand” non rischio mai di confondere un tono di voce con quello dell’agenzia, perché Cowork non ha caricato l’agenzia.

Questa è la cosa che mi ha cambiato il modo di lavorare a marzo, quando l’ho capita. Le chat generiche con tutto il vault dentro sono il modo più veloce per avere risposte mediocre. Le chat focalizzate per area sono il modo più veloce per avere risposte buone. Il Project Cowork è quella scoperta in versione operativa.

Il secondo è drafting di contenuti. Ogni articolo che leggi sul mio Substack passa per Cowork prima di arrivarti. Non perché Cowork scriva al posto mio, ma perché ragiona con me sull’angolazione, sulla struttura, sull’apertura. Apro il Project Substack, gli dico “questa settimana voglio raccontare la regola che uso tra Code e Cowork”, lui pesca dal contesto le ultime tre Lettere dal Builder, mi propone tre architetture diverse, scelgo la migliore, scrivo io. Poi rileggo io. Poi tagliuzzo io. La firma del testo è sempre mia, ma la fase di pensiero strutturato funziona meglio con una controparte intelligente che ha già letto il mio archivio.

Il terzo è operazioni amministrative dell’agenzia e del lavoro giornaliero. Questo è il pezzo più sottovalutato. Cowork è dove apro la chat alla mattina per leggere un report di un cliente Mainstream, ragionare su un preventivo, schedulare i prossimi quindici giorni, capire chi richiamare oggi. È lo strumento del lavoro ordinario di chi gestisce un’azienda. Non è uno strumento per nerd. È uno strumento per chi ha una scrivania e cento cose aperte. Lo dico perché è il pezzo che mi separa dal tipico “creator AI” italiano: io non solo parlo di AI, io ho un’agenzia con nove clienti attivi e una cofounderie con altri due soci, e Cowork è la cabina di regia di quel lavoro ogni giorno.

La regola davanti a un caso vero

Vediamo come funziona la regola in pratica, con due esempi che ho fatto questa settimana.

Esempio uno: aggiornare la strategia del post di lunedì.

Il post BUILD WITH AI nel quale racconto che ho dovuto fermare la mia pagina AI per qualche settimana e ho migrato un pezzo del workflow su Codex. La strategia di quel post vive in un file che si chiama strategia/post-tg-ai-italia-esperimento.md. Sabato scorso ho deciso di cambiare l’asse del post. Operazione: aggiornare il file di strategia, riallineare i movimenti narrativi, controllare che la bozza generata combaci con la nuova architettura.

Dove l’ho fatta? Tutta in Cowork. È un’operazione di pensiero su un singolo file di testo. Cowork legge il file, ragioniamo insieme, scrive la nuova versione, io rileggo, lui salva. Zero comandi terminal. Zero git. Quella è arrivata dopo, quando sono passato a Claude Code per fare il commit.

Esempio due: archiviare due progetti chiusi.

Il quindici maggio ho deciso di chiudere due progetti che vivevano in 1-projects/ dell’area Personal Brand. Uno era un generatore di video Remotion per delle slide di pitch, l’altro era un canale video sperimentale di Igor. Operazione: spostarli in 4-archives/, comprimere quello recuperabile in zip, cancellare fisicamente quello troppo pesante (centonovantaquattro mega di node_modules rigenerabili, troppo per il backup), aggiornare il MEMORY.md dell’area e il bucket 4-archives/, fare commit.

Dove l’ho fatta? Tutta in Claude Code. È un’operazione di filesystem pura: mv, zip, rm -rf, git add, git commit, git push. Cowork non avrebbe potuto farla. Non ha le mani per farla.

Vedi la simmetria? Stesso vault, stessa settimana, due operazioni opposte. Una di pensiero su un file, una di mani sul filesystem. Strumenti diversi, lavori diversi.

Se non hai letto il post in cui spiego come è strutturato il vault PARA che sto usando in questi esempi, è il punto di partenza naturale: PARA + Claude + Obsidian. Salvalo, te ne servirà per quello che sto per farti vedere adesso.

Tutorial concreto: la skill /aggiorna-lavoro

Adesso arriviamo al pezzo che ti porta a casa il valore di questo post. Ti faccio vedere una skill vera che gira nel mio vault da una settimana e che si chiama /aggiorna-lavoro. Lanciandola in Claude Code alla fine della giornata, mi sincronizza tutto. È il caso d’uso che dimostra meglio cosa significa “Claude Code costruisce”.

Come è installata. Vive a .claude/skills/aggiorna-lavoro/SKILL.md nella root del vault. Da quel path, sia Claude Code che Cowork la riconoscono come comando slash invocabile. La differenza è cruciale: Cowork la vede ma non può eseguire i sei step interni perché tre dei sei sono git log, git diff, git push. Cowork non ha mani per i comandi terminal. Claude Code sì.

Il prompt completo lo trovi infondo al post.

Cosa succede quando lo lancio. Mi siedo alle ventidue, dopo una giornata in cui ho toccato sette file in tre aree diverse. Apro Claude Code dentro il vault. Digito /aggiorna-lavoro e premo invio. Vado a prendere acqua. Quando torno, due minuti dopo, ho un report di dieci righe nella chat che mi dice esattamente quanto è cambiato nel vault dall’ultimo commit, quali aree sono state aggiornate, quali file in _Inbox/ sono stati triagiati e dove, quali memorie globali sono state scritte, quanti file sono finiti nell’archivio, il numero del commit appena pushato su GitHub.

Quello che faccio io: niente. È letteralmente il valore della skill. Il lavoro mentale di chiusura della giornata, che prima richiedeva quaranta minuti di disciplina che non avevo, adesso richiede due minuti di attesa.

Provala. Salvala. Adattala al tuo vault. Il pattern è generalizzabile a qualsiasi setup PARA con git versioning sotto. Se hai un vault Obsidian e un repository GitHub, hai tutto quello che ti serve per replicarla.

Se ti è utile, mandalo a un freelance o a un consulente che usa Obsidian ma non versiona ancora il vault. È il pezzo che gli manca per smettere di copiare comandi a mano.

Condividi

I tre casi in cui ho rotto la regola

Ogni regola operativa che funziona ha le sue eccezioni dichiarate. Se non te le dichiaro io, te le scoprirai da solo dopo dieci giorni di applicazione. Te le dico subito.

Eccezione uno: drafting di contenuti dentro Claude Code, quando il contenuto è il codice della skill stessa.

Quando ho scritto il prompt sopra, la prima versione l’ho ragionata in Cowork (perché era un esercizio di design del prompt) e la seconda passata di scrittura l’ho fatta dentro Claude Code, direttamente sul file SKILL.md. Il motivo è che Claude Code vede il file aperto, vede l’eventuale chiamata che fa la skill, può testarla in tempo reale con un --dry-run. Cowork avrebbe potuto scrivere il prompt più bello del mondo ma non avrebbe potuto vederlo in azione. Quando il contenuto è esso stesso un’istruzione operativa, Code vince.

Eccezione due: piccole operazioni di filesystem dentro Cowork, quando sono di lettura sola.

Se sto ragionando dentro un Project Cowork su una strategia di area e mi serve “leggere” il MEMORY.md di un’altra area, Cowork lo legge senza problemi. Non è un’operazione di filesystem nel senso di mutazione, è una lettura. La regola dice “Code per filesystem ops”; la regola intende mutazione, non lettura. Le letture stanno bene dovunque.

Eccezione tre: la chat ibrida quando un cliente ha lo schermo condiviso.

Quando faccio una sessione live di Academy MAIKER, il setup è uno schermo solo con due strumenti aperti a fianco. Cowork a destra per la spiegazione conversazionale che il cliente segue, Claude Code a sinistra per le operazioni che vedono comparire in tempo reale su Obsidian al centro. Tecnicamente non sto rompendo la regola, sto solo orchestrando i due insieme. Lo metto qui perché è il caso d’uso più potente, e perché probabilmente è anche il modo in cui formalizzerò un giorno il flow standard di onboarding Academy.

Cosa cambia dopo che applichi la regola

Tre cose, in ordine di magnitudine.

La prima: smetti di perdere tempo. Cinque minuti che si moltiplicano dieci volte al giorno fanno cinquanta minuti. Cinquanta minuti che si moltiplicano per cinque giorni a settimana fanno quattro ore. Quattro ore a settimana che si moltiplicano per quattro settimane al mese fanno sedici ore. Sedici ore al mese, ogni mese. Se la tua tariffa oraria è settanta euro, è milleecento al mese. È la differenza tra avere un assistant che funziona o averlo che ti fa perdere tempo.

La seconda: smetti di sporcare le chat. Cowork con cento chat dentro perché ogni volta apri quella nuova è il modo più sicuro per perdere contesto. Project per area significa che ogni Project ha la sua storia continua, che cresce nel tempo, e che a sei mesi sa di te più di quanto te ne ricordi tu.

La terza, e forse la più importante: smetti di dire “Claude” e basta. Inizi a dire “Claude Code” o “Cowork” quando parli del tuo workflow. Sembra una piccolezza linguistica, è invece il segnale che hai dentro un modello mentale operativo, non un’idea generica. Il giorno in cui un cliente o un collega ti chiede “ma tu come usi l’AI?” e tu rispondi con due frasi distinte (”Claude Code per quello, Cowork per quell’altro”), in quel momento hai smesso di essere uno che parla di AI e sei diventato uno che la usa.

LEGGI LA GUIDA COMPLETA A CLAUDE COWORK

Quello che Cowork sa fare. Funzione per funzione, con parole normali. Poi, alla fine, ti porto dentro casa mia e ti faccio vedere come uso ognuna di queste cose ogni giorno

LEGGI LA GUIDA COMPLETA COWORK

Da approfondire (stesso cluster)

1. Stai usando Obsidian per sbaglio. (E quasi tutti lo fanno.), il post sorgente di tutto. Spiega la struttura PARA del vault che sta sotto a questo workflow. Senza quella struttura, né Claude Code né Cowork hanno un terreno su cui lavorare bene.

2. Mentre lavoro l’AI prende appunti. La domenica mi propone le idee., il caso d’uso più forte di Claude Code nel mio vault: l’agente domenicale che legge i log delle aree e propone tre idee editoriali. È esattamente il tipo di sistema che Cowork non avrebbe potuto costruire, perché vive nel filesystem.

3. Meta ha appena ucciso i wrapper. Adesso inizia il lavoro vero., per chi si chiede dove finisce Claude e iniziano gli MCP. Spoiler, il discorso “Code vs Cowork” si moltiplica quando aggiungi un MCP server sotto a entrambi.

PROMPT PER AGGIORNARE LAVORO DOPO IL PAYWALL (GRATIS PER TUTTI SOLO PER POCHI GIORNI)

Read more

Quel rumore di fondo è il sistema editoriale che ti voglio raccontare oggi.

Per cinque mesi, ogni domenica sera, mi sono trovato davanti al calendario editoriale Substack vuoto a chiedermi “su cosa scrivo lunedì?”. A volte avevo idee chiare e partivo. A volte no, e perdevo due ore. Le sere in cui ne avevo troppe perdevo tre, perché non riuscivo a scegliere. E quasi sempre, dopo un po’ di rimugino, mi rendevo conto che la cosa più interessante della settimana l’avevo già fatta, ma me l’ero dimenticata. Era nel log di lunedì mattina, sepolta sotto altre venti operazioni successive.

Sabato ho preso quel pattern e l’ho dato a un agente. Domenica sera, alle 7 di sera, lui apre il vault, legge i log delle aree dove ho lavorato la settimana, ricostruisce cosa è successo, e mi propone tre idee topic per la settimana entrante. Una per ognuno dei tre format, lunedì mercoledì venerdì. Lunedì mattina io apro il calendario e trovo già la pipeline. Tre proposte, ognuna con angolazione + numeri di partenza + spunti narrativi. Non scrive al posto mio. Mi ricorda cosa ho fatto, e mi dà il punto di partenza.

Questo è quello che gira oggi. Nei prossimi giorni l’agente cresce, e gli aggiungo la ricerca esterna, le novità AI della settimana e cosa si sta dicendo sui social di rilievo, così le proposte di lunedì non sono solo “dentro il mio vault”, sono “dentro il mio vault intrecciato col fuori”. Quando questo upgrade è in piedi, il sistema fa quello che oggi fanno cinque persone in una redazione editoriale. Settimana per settimana, autonomamente, e con il mio veto sopra a tutto.

La scelta dell’idea, la scrittura, il tocco umano, il pensiero che lega le cose, restano a me. Sempre. Quella parte del lavoro, quella che ritengo la più importante, non si delega.

Questo post è il mio metodo, pezzo per pezzo. Te lo regalo perché chiunque scriva con cadenza fissa lo può adattare. E voglio essere chiaro su una cosa: la prima esecuzione vera dell’agente è di ieri sera, domenica 10 maggio. Lunedì che leggi questo è il primo lunedì in cui parto da una pipeline pre-cucinata. Non sto vendendo settimane di rodaggio che non ho. Ti faccio vedere dentro un sistema vero appena nato, con la sua architettura attuale e quella verso cui sta crescendo.

I due problemi del foglio bianco, decidere e ricordare

C’è una cosa che la maggior parte di chi insegna content marketing non dice mai abbastanza chiaramente, e che invece chiunque l’ha provato sulla propria pelle riconosce subito. Il foglio bianco settimanale ha due facce, non una sola, e la maggior parte delle soluzioni in giro si occupa solo della prima.

La prima faccia è la decisione. Cosa scrivo questa settimana, in questo format, per questo pubblico, in modo che si incatena con quello che ho scritto la settimana scorsa e con quello che voglio dire fra un mese? È il problema strategico, e si vede. Domenica sera, calendario aperto, due ore di rimugino. La maggior parte degli articoli di content marketing parlano di questo. Calendario editoriale, batching, tema settimanale, idee evergreen.

La seconda faccia è la più sottile, ed è quella che mi ha ferito davvero in cinque mesi su Substack. È la perdita di knowledge episodica. Lavori una settimana intera, fai cose, prendi decisioni, risolvi problemi, scopri pattern. La domenica ti siedi a scrivere, e di tutta quella settimana ricordi a malapena tre o quattro punti, sempre i più recenti. Le cose interessanti di mercoledì sono già sepolte. Le rotture di lunedì le ricordi vagamente. La decisione importante presa giovedì pomeriggio in macchina mentre rientravi non l’hai scritta da nessuna parte. La settimana è stata densa, il ricordo è debole.

I due problemi sembrano lo stesso, perché si manifestano nello stesso momento (domenica sera, calendario vuoto). Sono due. La decisione la risolvi con un sistema che propone. Il ricordo lo risolvi con un sistema che cattura. E i due pezzi devono parlarsi, perché un sistema che propone senza ricordare ti dà idee fuori contesto, e un sistema che cattura senza proporre ti dà solo una pila di file con dentro la tua settimana, ma niente che la traduca in contenuto.

Io ho scelto di costruirli insieme, non a tappe. La cattura passa dal sistema dei log delle cartelle del vault, già attivo da mesi senza che me ne accorgessi. La proposta passa da un agente schedulato di domenica sera, costruito sabato. Il post che stai leggendo è la prima esecuzione di entrambi che lavorano insieme.

Se ti riconosci in uno dei due problemi (calendario vuoto della domenica o memoria asciutta della settimana), e non sei iscritto, qui sotto puoi farlo. Scrivo ogni settimana il manuale operativo dei sistemi AI che uso davvero, su clienti veri, con architetture vere.

Iscriviti ora

Il framework, tre pezzi reali oggi più uno in arrivo questa settimana

Il sistema si appoggia su tre pezzi reali oggi, più un quarto che sto montando in questi giorni. Te li racconto in ordine, perché è anche l’ordine in cui un sistema editoriale serio si costruisce, dal basso verso l’alto.

Parte uno, la cattura passiva tramite log delle cartelle. Questo è il pezzo che si vede meno e che fa più lavoro. Il mio vault è strutturato in PARA, ne ho parlato in Una struttura del 2017 ha aspettato dieci anni per parlare con Claude due settimane fa. Dentro ogni cartella c’è un file log.md che si popola in autonomia mentre lavoro. Quando chiudo un report cliente, una riga scende nel log della cartella cliente. Quando aggiorno un agente, una riga scende nel log della cartella agente. Quando archivio una decisione personale nel Decision Log, una riga scende nel log della cartella personale. Non scrivo io quei log. Si scrivono quasi soli, perché il pattern operativo del vault dice che ogni operazione lascia traccia. Sono mesi che girano. Da soli sembrano rumore di fondo. Per l’agente di domenica sono materia prima.

A questo si affianca un secondo livello di cattura, che è invece manuale ma rapido. Si chiama content-pipeline e vive in _system/content-pipeline/seeds/. Quando in una delle aree del vault succede qualcosa che ha potenziale editoriale forte (caso cliente con numero, decisione strategica, errore raccontabile), io creo un file seed in due minuti, frontmatter standard, fatto concreto + numero chiave + pillar + privacy. È capture esplicita per le cose che voglio sicuramente spingere a contenuto. I log sono il rumore di fondo, i seed sono il sussurro intenzionale.

Parte due, l’agente di ricerca topic schedulato di domenica. Una scheduled task che gira ogni domenica alle diciannove, in autonomia. Il prompt che gli do è semplice nelle istruzioni, denso nella richiesta. Leggi i log delle cartelle dove ho lavorato la settimana, leggi memory-day di area per lo stato corrente, leggi i seeds attivi della content-pipeline, leggi log Substack ultime sei settimane (per evitare ripetizioni). Sintetizza il contesto. Genera tre proposte topic per i tre format Substack della settimana entrante, ognuna con angolazione + numeri di partenza + patrimonio swipe da incastonare + rischio ripetizione. Scrivi tutto dentro 2-areas/substack/memory-day.md nella sezione “Settimana entrante”, marca timestamp, lascia traccia in log dell’agente.

L’agente non scrive l’issue. Propone i topic. Mi ricorda cosa ho fatto. Mi dà il punto di partenza. Io poi conferma, sostituisco, scarto. La scelta resta mia, sempre.

Parte tre, la skill orchestratore di drafting. Si chiama pb-substack-week-cycle e vive in _system/skills/. Quando lunedì mattina apro Claude Desktop nel vault e dico “scrivi le tre issue della settimana”, la skill carica in sequenza la madre pb-newsletter-substack (voce, regole, CTA framework, paywall, settings) + le tre figlie format-specific (BUILD WITH AI, CREA IL TUO SISTEMA AI, LETTERA DAL BUILDER), legge le proposte topic che l’agente ha scritto la sera prima, e drafta tutte e tre le issue salvandole in bozze/issues/. Le drafta su scaffold di ognuno dei tre format, ma il pensiero che lega le frasi, le metafore, le dichiarazioni vulnerabili, le decido e le scrivo io durante quella sessione. La skill è la struttura, io sono la voce.

Parte quattro, in arrivo questa settimana, la ricerca esterna. Oggi l’agente di domenica legge solo dentro il vault, e questo è già parecchio. Nei prossimi giorni gli aggiungo due capability che cambiano il livello di gioco. La prima, ricerca web sulle novità AI e marketing della settimana, perché non basta sapere cosa ho fatto io, serve anche sapere cosa è successo intorno (rilasci, sentenze, casi pubblici). La seconda, lettura di cosa si sta dicendo sui social di rilievo per il mio pubblico, per intercettare conversazioni in atto invece di partire da zero. L’agente intreccia il dentro (i miei log) con il fuori (novità + social) e mi propone tre topic che sono ancorati alla settimana mia ma anche al momento del mercato. Quando questo upgrade è in piedi, il sistema fa quello che fa una redazione editoriale piccola ma seria, settimana per settimana, autonomamente.

Tre pezzi reali oggi più uno in arrivo. La somma è un sistema che cattura quello che vivo, lo intreccia con quello che succede fuori, mi propone idee, e lascia a me la scelta + la scrittura + il pensiero. Quel pezzo non si delega, e il valore vero del sistema è proprio che mi libera tempo e lucidità per dedicarmi a quello.

Una nota prima di entrare nell’implementazione. Questa guida fra qualche giorno entra dietro paywall come ogni CREA IL TUO SISTEMA AI, oggi la stai leggendo nei primi giorni di apertura.

Iscriviti ora

Implementazione, sette step concreti per montare lo stesso sistema

Adesso veniamo al pratico, perché un framework senza implementazione resta un articolo di LinkedIn motivazionale, e il mio mestiere non è quello.

Step uno, attiva i log.md per ogni cartella del vault. È il pezzo che fa la cattura passiva ed è anche il pezzo più sotto-stimato. La regola è semplice, ogni cartella di lavoro nel tuo vault PARA ha un suo file log.md in cui finiscono le operazioni che fai dentro. Quando crei un agente in _system/agents/<nome>/, scendi una riga datata nel log di quella cartella. Quando chiudi un report cliente, una riga datata nel log della cartella cliente. Quando archivi un file, una riga datata nel log di archives. Il modo più pratico per renderlo automatico è dare l’istruzione nel CLAUDE.md della cartella (”ogni operazione che fai qui dentro lascia traccia in log.md con timestamp + 1 riga”), così quando un agente lavora in quella cartella scrive lui i log. Per le operazioni che fai a mano, è abitudine, due settimane di disciplina e diventa automatico. Tempo setup, un’ora a testa per ogni area principale.

Step due, scaffolding content-pipeline. Sopra ai log delle cartelle aggiungi un secondo livello di cattura, esplicito, per quando vuoi sicuramente spingere qualcosa a contenuto. Crea dentro il vault una cartella _system/content-pipeline/ con quattro sottocartelle, seeds/, in-sviluppo/, pubblicati/, scartati/. Dentro seeds/ crea sottocartelle per area sorgente, da-mainstream/, da-maiker/, da-personale/. Crea un _template-seed.md con frontmatter standard, fonte-area, fatto, numero-chiave, pillar, privacy-livello, formato-candidato, capture-date. Tempo, due ore.

Step tre, capture protocol del seed esplicito. Regola operativa, ogni volta che succede qualcosa con numero concreto + pillar identificabile, creo un seed in due minuti. Se rimando, perdo. Due minuti significa, copio il template, riempio sei campi del frontmatter, scrivo tre righe nel corpo (fatto concreto, contesto, angolazione narrativa). Salvo. Stop. Lo lavoro durante il filter settimanale. I miei trigger sono cinque, fine di un report cliente con numero, risoluzione di un problema tecnico, decisione presa nel Decision Log personale, framework appena estratto da una guida, conversazione con cliente o partner che mi ha colpito.

Step quattro, filter settimanale. Venerdì sera, sessione di trenta-quaranta minuti, apro la cartella seeds/ e per ognuno applico tre check. Voice fit (la voce di Substack regge questo seed?). Pillar match (è uno dei quattro pillar?). Privacy (NDA rispettati, anonimizzazione fatta?). Se passa, sposto in in-sviluppo/<slug>/. Se no, in scartati/<slug>.md con motivo scritto in alto. Target, svuotare seeds/ portandone due-tre in sviluppo. Se a fine venerdì la cartella seeds ha ancora dieci file, la capture della settimana dopo va sospesa, accumulare senza filtrare è anti-pattern.

Step cinque, configurare l’agente di ricerca topic. Crea _system/agents/agente-ricerca-topic/ con quattro file dentro, AGENT.md(definizione completa, sequenza di esecuzione, confine sacro), prompt.md (il prompt esatto che la scheduled task eseguirà), MEMORY.md (stato persistente, ultima esecuzione, pattern emersi, pillar tracker), log.md (cronologia esecuzioni). Il prompt esatto, con istruzioni di lettura dei log delle cartelle + memory-day di area + seeds + log Substack ultime sei settimane, sta nel deep dive PDF dietro paywall qui sotto.

Step sei, schedulare l’agente. Quando sei sicuro che il prompt funziona (testalo manualmente almeno due-tre volte prima di schedulare), usa il tool MCP scheduled-tasks per creare un task con cron 0 19 * * 0 (domenica 19:00), timezone Europe/Rome, prompt il contenuto di prompt.md. La task si attiva ogni domenica sera, esegue, scrive l’output in 2-areas/substack/memory-day.md sezione “Settimana entrante”, aggiorna il log dell’agente. Lunedì mattina trovi le tre proposte già pronte.

Step sette, ROADMAP, aggiungi all’agente la ricerca esterna. Questa è la parte che sto montando io in questi giorni. Si tratta di estendere il prompt dell’agente con due strumenti aggiuntivi. Una ricerca web sulle novità AI e marketing della settimana (basta abilitare il tool WebSearch o equivalente nel client che ospita la scheduled task, dargli filtro temporale “ultimi sette giorni” e una lista di domini di rilievo). Una lettura di cosa si sta dicendo sui social, dove “social” per me significa principalmente LinkedIn e X tramite MCP dedicati (esistono già diversi MCP open per leggere feed e thread). L’agente intreccia il dentro (i tuoi log + memory-day + seeds) con il fuori (novità + social), e le proposte di lunedì sono ancorate alla settimana tua e al momento del mercato. Senza questo step funziona già, con questo step diventa un’altra cosa.

Step otto, skill orchestratore week-cycle per il drafting. In _system/skills/pb-substack-week-cycle/SKILL.md scrivi un orchestratore che (a) carica la madre Substack + le tre figlie format-specific in sequenza, (b) legge le proposte topic da memory-day.md, (c) ti chiede conferma topic + numerazione progressiva, (d) drafta in sequenza le tre issue salvando in bozze/issues/, (e) fa il pass anti-AI checklist (no em dash, no parole vietate, IO soggetto attivo), (f) handoff alla skill pb-substack-batch-weekend per le Note di traino. Tempo della sessione drafting, quattro-sei ore lunedì mattina.

Otto step (sette reali + uno in roadmap). La prima volta li monti in due-tre weekend di lavoro lento. Una volta in piedi, vivono da soli, e l’unica cosa che ti resta è la review settimanale del filter (40 min venerdì) + la sessione di drafting con la skill orchestratore (4-6h lunedì). Il resto, capture passiva e proposta, si auto-popolano.

Se questa logica (cattura passiva mentre lavori, agente che intreccia la domenica, craft umano sopra a tutto) ti rappresenta come lavori o come vorresti lavorare, mandala a un collega che sta ancora costruendo i contenuti uno alla volta dentro Notion.

Condividi

Il caso applicabile, questo stesso post

Voglio essere onesto, perché altrimenti sembra che ti stia raccontando settimane di rodaggio che non ho. Il sistema editoriale completo, agente schedulato compreso, l’ho montato sabato. Sabato 9 maggio 2026. Tutta la giornata di sabato è stata costruzione, non scrittura. La parte di cattura passiva (i log delle cartelle) gira invece da mesi senza che me ne fossi reso conto come “sistema editoriale”, la usavo come tracking operativo. Domenica sera, alle 19:00, l’agente ha eseguito la sua prima vera lettura, ha aperto i log delle cartelle dove avevo lavorato la settimana, ha letto memory-day di area, ha letto i seeds della content-pipeline, e ha scritto in memory-day.md Substack tre proposte topic per la settimana.

Lunedì mattina, oggi, ho aperto memory-day.md. Ho letto le tre proposte. Una era questa, “racconta il sistema che hai appena costruito”. Ho riconosciuto subito che era la prima da scrivere, perché era l’unica delle tre che parlava del sistema stesso, ed era il momento giusto per farlo prima che diventasse storia. Ho confermato. La skill orchestratore ha drafted la struttura. Da lì ho preso il drafting in mano io, ho aggiunto la mia voce, ho scritto la storia di mercoledì pomeriggio col report che chiudeva, ho legato i due problemi (decidere + ricordare), ho dichiarato la roadmap onestamente.

Quella riduzione di carico cognitivo, da “cosa scrivo” a “in quale ordine scrivo”, è il valore vero del sistema in fase uno. Si vede solo dopo averlo provato una volta, ed è il motivo per cui te lo sto raccontando subito invece di aspettare due mesi di metriche.

La fase due, quella che monto questa settimana, sposta il valore ancora più su. Aggiungo le novità AI esterne e la lettura social, e l’agente non mi ricorda più solo “cosa hai fatto”, mi propone “cosa hai fatto + cosa è successo intorno a te + dove può inserirsi il tuo angolo”. Quando la fase due è in piedi, le proposte di lunedì sono ancorate al mercato di quel preciso momento, non solo al mio vault. È esattamente quello che fa una redazione editoriale, e una redazione costa un sacco. Il sistema costa una scheduled task + due MCP, fra qualche giorno funziona.

Le metriche di throughput le compilerò man mano. Tra otto settimane farò un post-recap con seeds catturati, percentuale di filter, percentuale di seed che diventano post, dove si rompe il funnel, e quante delle proposte agente ho effettivamente accettato vs riformulato. Ma il valore “qualità della domenica sera” l’ho già misurato in una sera sola, e mi basta per consigliarti di costruirlo.

Errori comuni quando provi a montare un sistema così

Vedo già adesso cinque trappole in cui sto vedendo cadere chi prova a costruirsi un sistema di questo tipo. Te le racconto perché se le eviti dall’inizio risparmi un mese di frustrazione.

Trappola uno, confondere il sistema con un ghostwriter. È la trappola più costosa, e se ci cadi dentro tutto il resto perde valore. Il sistema non scrive al posto tuo, ti propone le idee. Ti ricorda cosa hai fatto. Ti dà il punto di partenza. La scelta dell’idea, la scrittura, le metafore, i punti vulnerabili, le decisioni di voce, restano un mestiere tuo. Se cominci ad accettare le bozze dell’orchestratore senza riscriverle con la tua testa, in otto settimane il tuo Substack ha la voce tiepida di chi sta delegando una cosa che non si può delegare. Antidoto, ogni volta che apri una bozza che la skill ha scritto per te, parti dal presupposto che dovrai riscriverla per metà a mano. Se finisci con meno del 50% di reword, hai abdicato.

Trappola due, capture diventa procrastinazione. Inizi entusiasta, crei venti seed in tre giorni, e poi non li filtri mai. La cartella seeds/ diventa un cimitero. Antidoto, blocca venerdì sera quaranta minuti di filter, non negoziabili. Se ti accorgi che venerdì sei sotto deadline cliente, sposta il filter a sabato mattina. Mai oltre. La capture senza filter è anti-pattern perché ti dà l’illusione di star costruendo un sistema mentre stai solo accumulando rumore.

Trappola tre, log di cartella scritti male. I log automatici sono utili solo se contengono frasi parlate (datate + concrete + con un numero o un nome quando possibile). Se i log dicono “aggiornato file” o “modificato CLAUDE.md”, l’agente di domenica li legge e non capisce niente. Antidoto, l’istruzione standard nei CLAUDE.md di cartella deve essere “ogni log deve avere data + verbo + oggetto + esito o numero”. Esempio buono, “2026-05-07 chiuso report cliente, ROAS +20% da consolidamento 9-3 campagne”. Esempio cattivo, “2026-05-07 update report”.

Trappola quattro, l’agente come decisore. Cominci ad accettare le proposte dell’agente senza guardarle, perché sono “già pronte”. Tre settimane dopo ti accorgi che il tuo Substack ha un tono mediato e fiacco, perché l’agente generalizza dove tu invece personalizzeresti. Antidoto, l’agente propone sempre tre alternative per format, non una. Tu scegli, e quando nessuna delle tre ti convince, le scarti tutte e ne scrivi una a mano. L’agente è un assistente, non un sostituto.

Trappola cinque, sistema senza tracking. Lo monti, parte, lo usi per due settimane e poi non sai se sta funzionando. Antidoto, popola un MEMORY.md content-pipeline con KPI semplici, seeds catturati questa settimana, percentuale che entra in sviluppo, percentuale che esce pubblicata, e in più una colonna nuova quando l’agente è in piedi, percentuale di proposte agente accettate vs riformulate vs scartate. Cinque numeri, aggiornati ogni venerdì alla fine del filter. Se tre settimane di fila scendono, il sistema ha un buco, vai a cercarlo.

Il sistema PARA su cui appoggia tutto questo l’ho aperto in Una struttura del 2017 ha aspettato dieci anni per parlare con Claude. Questo post è cosa ci ho costruito sopra. Salvali entrambi, sono la mappa intera del sistema operativo personale che uso ogni giorno.

Tre cose che voglio lasciarti, perché sono il vero punto di questo post

Voglio chiudere con tre cose che valgono più degli otto step operativi qui sopra, perché gli step li puoi ricreare, queste no.

Uno. L’AI non scrive al posto mio. Mi propone le idee e mi ricorda cosa ho fatto. Sono due funzioni profondamente diverse, ed è importante chiamarle col loro nome. Per cinque mesi, leggendo gente che diceva di “automatizzare i contenuti con l’AI”, ho pensato che parlassero di sostituzione. Non lo è. La parte che si delega bene è la cattura (passiva, costante, senza fatica) e la sintesi (settimanale, su materiale tuo intrecciato col fuori). La parte che resta tua è la scelta di cosa raccontare, la scrittura della frase che ti viene in mente sotto la doccia, la metafora che lega due cose, il punto di vulnerabilità che mostri solo perché vuoi mostrarlo. Questo è il craft. Si chiama tocco umano per una ragione, ce lo metti tu.

Due. Il sistema editoriale è anche un sistema di memoria. Tre quarti dei fallimenti dei piani editoriali che ho visto nei miei clienti negli ultimi due anni non venivano dalla mancanza di idee, venivano dalla perdita di knowledge episodica. Lavori, scopri, decidi, e dopo una settimana non te lo ricordi più, perché la testa umana non è un archivio, è un filtro. Il sistema editoriale serio risolve questo trasformando il vault in archivio (i log scendono soli) + dando a un agente la chiave di lettura (legge il dentro, intreccia col fuori, propone). Quando hai questa coppia in piedi, scrivere settimanalmente smette di essere “trovare idee” e diventa “scegliere fra idee tue che hai dimenticato di avere”.

Tre. Costruire il sistema è il vero contenuto. Quello che ti sto raccontando in questo post non è teoria, è la stessa cosa che ho fatto sabato. La differenza tra chi avrà un sistema editoriale tra sei mesi e chi non lo avrà non sarà chi ha più tempo o più budget. Sarà chi avrà avuto la disciplina di mettersi in un sabato pomeriggio, scrivere le istruzioni di log nelle CLAUDE.md delle cartelle, costruire la content-pipeline, scrivere il prompt agente, schedulare la task, scrivere la skill orchestratore. Sei pezzi di sistema che esistono già nei tuoi tool, gratis o quasi, ma che diventano un sistema solo quando li orchestri tu. Nessuno ti vende un sistema editoriale chiavi in mano che funziona davvero. Il giorno che lo vendessero, non sarebbe più tuo, sarebbe loro.

Mentre lavoro, lui prende appunti. La domenica, mi propone le idee. Lunedì, scelgo, scrivo, ci metto la testa. È il patto con il sistema. Lui fa quello che lo annoierebbe a me, io faccio quello che a me piace fare, e quello che nessuno può fare al posto mio.

Ivan

Commenta. Domanda specifica per te. Tu come fai a non perderti le cose che hai fatto durante la settimana quando arriva la domenica? Hai un sistema, o ti affidi alla memoria? Scrivimelo nei commenti, leggo tutto, una per una. I casi più interessanti finiscono nel prossimo CREA IL TUO SISTEMA AI, raccontati per nome.

Lascia un commento

Deep dive, scarica il PDF Builders

Quello che hai letto sopra è il framework. Tutto il sistema vero, copiabile pezzo per pezzo, sta nel deep dive PDF qui sotto. Te lo do perché lo replichi nel tuo vault, lo adatti al tuo canale, e parti lunedì prossimo invece di costruirtelo da zero in due weekend.

Cosa trovi dentro:

1. Il prompt esatto dell’agente di ricerca topic (~400 parole) con le quattro scelte non-ovvie spiegate (perché tre alternative per format, perché numero specifico obbligatorio, perché skip se Ivan ha già pianificato, perché sei settimane indietro nella lettura log).

2. Template seed completo + due esempi reali compilati, uno Mainstream (cliente fashion sneaker ecommerce, consolidamento 9→3 campagne Meta, ROAS +20%, anonimizzato) e uno Personale (primo speech a Social Hub Roma, 20 persone, 40 min Q&A).

3. Skill orchestratore pb-substack-week-cycle, frontmatter completo + sequenza 8 step (carica madre → conferma topic → drafting BWAI → drafting CREA → drafting LETTERA → validazione anti-AI → handoff batch-weekend → tracking pre-pubblicazione).

4. Dashboard KPI MEMORY.md content-pipeline, count per stadio + target settimanali (capture ≥3, seeds→sviluppo ≥50%, sviluppo→pubblicato ≥70%) + pillar tracker per evitare squilibri.

5. Bonus scaffold zip in arrivo, cartelle pronte da copiare nel tuo vault.

Sotto trovi il deep dive completo. Il prompt esatto che gira nell’agente domenica sera (~400 parole, con stop conditions e check anti-deriva), il template seed completo con due esempi reali compilati di mio (uno Mainstream cliente con ROAS, uno personale con turning point), la skill orchestratore pb-substack-week-cycle da copiare nel tuo _system/skills/ (frontmatter + sequenza di esecuzione completa), e la dashboard KPI MEMORY.md per il tracking settimanale. Per leggerlo serve essere Builders (€5/mese o €50/anno) o Piano “AI Maiker”, dopo il lancio paid del 1 luglio. Fino al 30 giugno è gratis per tutti, perché stiamo ancora costruendo la libreria.

📎 Scarica il deep dive PDF (8 pagine, ~1.400 parole, formato A4 brandizzato), sotto il paywall!

Read more

Settimana scorsa, in queste stesse pagine, ti ho raccontato come sono finito a costruire un vault Markdown che funziona da memoria persistente per Claude. Ti ho spiegato perché il Markdown è il formato che gli LLM capiscono meglio, e perché un sistema di backlink come quello di Obsidian, prima di essere una funzione comoda per gli umani, è una mappa di relazioni che un agente sa attraversare. Ti ho lasciato sospeso su un problema, però. Il sistema funziona finché i file sono pochi. Quando diventano tanti, e diventano tanti in fretta proprio perché funziona, qualcosa comincia a incepparsi. Non per Claude. Per me.

Quando i file di un vault arrivano a duecento, poi trecento, e continuano a crescere settimana dopo settimana, l’agente li legge in pochi secondi e non se ne accorge nemmeno. Tu, invece, nel momento in cui hai bisogno di aprire un singolo documento durante una call, di mostrarlo a un cliente, o semplicemente di ritrovarlo in un momento in cui Claude non è disponibile, cominci a perdere il filo. La cartella si gonfia. Le sottocartelle si moltiplicano per buona intenzione, e poi nessuno le mantiene. Le note di una call di sei mesi fa stanno accanto a quelle di stamattina, e in mezzo c’è di tutto.

Il problema lo conoscevo già. Anzi, conoscevo già anche la soluzione, ma in una forma diversa.

Parlo di come applico l’AI per il lavoro, non perderti i miei prossimi articoli

Iscriviti ora

C’è un metodo di organizzazione delle informazioni che si chiama PARA. Lo ha formalizzato Tiago Forte nel 2017. Nel mondo della produttività digitale è uno standard, ci sono libri, corsi, persone che lo usano da quasi dieci anni per tenere in ordine il proprio secondo cervello. Non è una scoperta, e non sono io ad averla fatta. Forte voleva dare ai professionisti uno schema universale per decidere dove va ogni file che entra nella loro vita, basandosi su una sola domanda: quanto è vicino a qualcosa di attivo adesso?

Le quattro categorie sono semplici. Se un file appartiene a un progetto con una scadenza reale, va in Projects. Se riguarda una responsabilità continuativa senza fine definita, come la propria agenzia o il proprio personal brand, va in Areas. Se è conoscenza di riferimento che non si lega a nessuna azione specifica, va in Resources. Se appartiene a qualcosa che si è chiuso o si è interrotto, va in Archives. Quattro cartelle, un criterio, e tutto il resto sta dentro.

Io PARA la uso dal 2020. La applicavo alle cartelle del mio computer, per tenere in ordine i file di lavoro, e dentro Notion, dove ho passato anni come secondo cervello, come strumento di gestione progetti, come database personale. Lo facevo in un modo completamente diverso da come lo faccio oggi: era una griglia di archiviazione e niente di più. Mi serviva per non perdermi tra i documenti e per ritrovare le cose. Il principio era lo stesso che applico oggi, ma il contesto era un altro. PARA era una mia abitudine privata, non l’infrastruttura di nessun sistema operativo personale.

Poi, alla fine dello scorso anno, è cambiato qualcosa.

Claude ha aperto la possibilità, dentro la modalità Cowork del desktop, di lavorare direttamente sulle cartelle del mio computer. Non più chat con upload manuale di file, non più copia e incolla di documenti dentro una conversazione. Un agente che entra nel mio file system e legge, scrive, sposta, modifica file dentro la struttura locale che già esisteva.

La prima cosa che mi è venuta in mente è stata: bene, adesso posso costruire un sistema di organizzazione vero, non solo una griglia di cartelle ferme. La seconda cosa è stata: non sono sicuro di volergli dare accesso a tutto.

Il rischio era pratico, non filosofico. Un agente che lavora autonomamente sui file del computer è potente, ma se prende un’iniziativa sbagliata su una cartella importante, se sposta qualcosa per errore, se sovrascrive un documento su cui stavo lavorando, ricostruire la situazione precedente diventa complicato. Per qualche settimana mi sono trattenuto. Aprivo Cowork solo per piccoli compiti, mai sull’intera struttura, mai sui clienti, mai sui materiali sensibili.

La soluzione l’ho trovata collegando l’intera cartella madre a un repository GitHub privato. Ogni modifica che Claude fa, ogni file che crea, sposta o cancella, ogni prompt che ho usato in una sessione di lavoro, finisce in un commit datato. Se qualcosa va storto, posso tornare indietro a una versione precedente in trenta secondi. Se voglio capire quando e perché un certo file è cambiato, c’è lo storico completo. È una rete di sicurezza che mi ha permesso di lasciare a Claude un livello di autonomia che senza versioning non mi sarei mai sentito di concedere.

A quel punto ho fatto la seconda mossa. Ho trasferito tutto quello che avevo dentro Notion in una cartella di file Markdown locali, dentro Obsidian. Per anni Notion era stato il mio secondo cervello, ma quando il vault è diventato la base per il mio lavoro con gli agenti AI, ho dovuto ammettere che non era più adatto. Notion conserva i contenuti dentro database proprietari accessibili tramite API, con limiti di chiamate e con un livello di astrazione che separa il dato dalla sua rappresentazione finale. Obsidian è semplicemente una cartella di file di testo sul mio computer. Per un agente che deve leggere, scrivere, e mantenere coerenza tra centinaia di file, la differenza è enorme. Markdown locale significa zero conversioni, zero rate limit di API, zero overhead. È il file che è anche la sua forma finale.

Solo a quel punto, con il versioning attivo e la migrazione completata, ho potuto appoggiare PARA sopra il vault. Non più come una griglia di archiviazione, ma come l’architettura portante di un sistema operativo personale. È in quel passaggio che mi sono accorto di una cosa che in cinque anni di uso quotidiano non avevo capito.

PARA non è solo una griglia per organizzare informazioni statiche. È una struttura che codifica il tempo. Risponde alla domanda di dove vivono le cose tenendo conto del fatto che le cose hanno un ciclo di vita: nascono, durano, e prima o poi finiscono. Forte non poteva saperlo nel 2017, ma proprio questa dimensione temporale, scritta dentro la struttura stessa delle cartelle, è quello che oggi serve a un agente AI per capire cosa è ancora vivo nel mio lavoro e cosa è invece memoria archiviata che non deve più disturbare il quotidiano.

Quest’anno è successa una cosa che mi ha confermato di stare guardando nella direzione giusta.

Andrej Karpathy, ex direttore AI di Tesla e co-fondatore di OpenAI, ha pubblicato un post breve su X in cui raccontava come avesse cominciato a usare gli LLM non principalmente per scrivere codice, ma per costruire knowledge base personali. File Markdown strutturati che l’agente stesso compila e mantiene tra una sessione e l’altra. Il post ha fatto sedici milioni di visualizzazioni in pochi giorni, e due giorni dopo ha pubblicato un gist su GitHub con l’architettura tecnica completa: una cartella di fonti grezze, una cartella wiki dove l’LLM compila pagine sintetiche, un file CLAUDE.md come schema operativo dell’agente. Migliaia di star in una settimana.

Quando l’ho letto, ho riconosciuto subito il principio di fondo. Era lo stesso a cui ero arrivato per conto mio nei mesi precedenti, lavorando su un problema diverso, in un contesto diverso. E la cosa che trovo interessante, a distanza di qualche mese, è proprio questa convergenza. Quando un problema è abbastanza reale e abbastanza diffuso, persone che non si conoscono e che lavorano su tavoli lontani arrivano a soluzioni che si assomigliano. Non è genio individuale, è quasi consequenzialità. Se il Markdown è il formato che gli LLM capiscono meglio, e se hai bisogno di una memoria che sopravviva alle sessioni, e se lavori su molte cose in parallelo con orizzonti temporali diversi, finisci per costruire una struttura simile a quella che un’altra persona, in un altro angolo del mondo, sta costruendo nello stesso momento.

L’architettura di Karpathy, però, è pensata per un ricercatore. Lui studia transformer da cinque anni, e la sua wiki cresce in profondità su pochi argomenti che restano rilevanti a lungo. Tutto quello che mette dentro continua ad avere senso, perché il suo orizzonte è quello. Per chi si trova invece a gestire più contesti contemporaneamente, l’orizzonte è un altro. Le cose nascono, durano qualche settimana o qualche mese, e poi vanno spostate da qualche parte dove non disturbano più il quotidiano senza essere però perse del tutto. PARA fa esattamente questo, e lo fa codificando il ciclo di vita delle informazioni dentro la struttura stessa, non come etichetta a parte.

Voglio spendere due righe su un beneficio che, fino a oggi, davo per scontato. Parlo molto di come PARA sia leggibile da un LLM, ed è vero. È la metà della storia, però. L’altra metà è che PARA è facile da navigare anche per noi, esseri umani che ogni tanto apriamo Finder o l’Esplora Risorse senza avere Claude davanti.

Quando di domenica sera devo cercare la nota di una call con un cliente attivo, so dove andare: 2-Areas/clienti/, e da lì proseguo. Non devo ricordarmi gerarchie inventate caso per caso. La struttura me lo dice. Per un cervello umano è meno pesante di un albero di cartelle improvvisato di volta in volta, e per un agente è pulizia che lo aiuta a non andare a rovistare nel mucchio. Stesso principio, due lettori diversi, entrambi soddisfatti.

E proprio perché funziona in modo trasversale, ho cominciato a pensare che questo sistema non sia utile soltanto a chi fa lavori che si etichettano come “creativi” o “complessi”. L’ho costruito pensando alla mia agenzia, alla piattaforma di formazione, al personal brand. Andando avanti mi sono accorto che lo stesso impianto regge per un imprenditore che gestisce un’azienda di trenta persone e si ritrova progetti che entrano ed escono, fornitori che cambiano, pratiche aperte e chiuse. Regge per un dipendente di un ufficio normale che convive con cartelle email infinite, decisioni prese in una call e dimenticate tre giorni dopo, documenti che non si trovano più nel momento in cui servono. Regge per chiunque produca documenti, prenda decisioni, debba tenere traccia di qualcosa nel tempo. PARA combinata con un agente AI, in pratica, diventa un assistente generale per qualsiasi attività intellettuale che lasci una traccia scritta. Non è un sistema da marketer. È un sistema da chiunque pensi per lavoro.

Sopra PARA ho aggiunto una sola cartella che non è prevista nello schema originale, e si chiama _System. Dentro vivono gli agenti, le skill, i template, le istruzioni di manutenzione del vault. Non è contenuto, è infrastruttura. Forte non l’ha messa nel 2017 perché nel 2017 non esistevano agenti che lavorano da soli sopra i file. Karpathy non ne ha bisogno perché lavora a un livello di astrazione diverso, quello dei modelli e dei prompt. A me serve, perché altrimenti il vault resta una bella libreria che però non si muove da sola, e quando i progetti sono molti il quotidiano non si regge senza qualcosa che lavora in autonomia tra una sessione e l’altra.

Vale la pena raccontare anche come si dividono i ruoli tra gli strumenti che uso per dare comandi a questo vault, perché è un dettaglio che cambia molto la sensazione di controllo. La cartella madre, quella alla radice di tutto, è gestita da Claude Code. È il tool più potente che ho a disposizione, quello che ha accesso al terminale, può fare versioning verso GitHub, riorganizzare in massa, e mantenere la coerenza generale dell’intero sistema. Quando invece lavoro a un singolo progetto, a una bozza, a una sotto-area, apro Claude Cowork dentro la sotto-cartella specifica. Cowork ha accesso solo a quel ramo del vault, non a tutto. Questa separazione fa sì che il rischio resti contenuto: se sto scrivendo un articolo dentro 1-Projects/substack/, l’agente con cui sto lavorando in quel momento non ha alcun bisogno di toccare la cartella dei clienti dentro 2-Areas/. Ogni livello ha il suo perimetro, e ogni perimetro ha l’agente con la quantità di potere giusta per il pezzo di lavoro che ci si fa dentro. Poi a fine giornata lavorativa, torno in Claude Code, per condividere la memoria e i log con il resto dei file se ne hanno bisogno.

Per dare un’idea concreta di come gira tutto questo insieme, mi è capitato qualche mattina fa di aprire Cowork dentro la cartella di un cliente e di chiedere a Claude di prepararmi il follow up di una call avvenuta il venerdì precedente. Claude ha trovato un file CLAUDE.md specifico dentro quella cartella, che eredita le regole generali dell’area agenzia e aggiunge le specifiche del cliente, ha letto il log con la trascrizione della call, ha consultato la memoria del cliente che gli ricordava un paio di cose che non voglio dover rispiegare ogni volta, e ha scritto la mail già nel tono giusto. Quaranta secondi, senza che io abbia aperto un file a mano. La stessa cosa avviene quando passo da Cowork a Claude Code per riorganizzare l’intero vault o per uno script di automazione che tocca più aree: cambio strumento, ma il contesto resta identico, perché la struttura del vault è la stessa per entrambi. Su una settimana di lavoro vera, questo mi fa risparmiare circa due ore di onboarding ripetuto su tool diversi. Su un anno, sono due settimane lavorative restituite al pensiero.

C’è un’ultima cosa che vale la pena dire, prima di chiudere.

La struttura di cui ti ho parlato risponde alla domanda di dove vivono le informazioni. Non risponde però a un’altra domanda, che secondo me è quella in cui si gioca davvero la differenza tra un vault ben organizzato e qualcosa che assomiglia a un collaboratore. La domanda è chi muove le cose. Quando un documento nuovo entra nella inbox del vault, chi decide dove va? Quando un cliente chiude, chi sposta la cartella in Archives? Quando una proposta è pronta, chi la genera partendo dalle note? A queste domande oggi rispondono gli agenti che ho costruito dentro _System, e lavorano in modo autonomo sopra l’architettura PARA. Sono loro, più della struttura, il livello che trasforma una libreria in qualcosa che lavora anche quando non ci sei. Ne parlo nel prossimo pezzo, con un esempio reale, codice e prompt.

Una cosa colpisce, a posteriori. Tiago Forte ha scritto PARA quasi dieci anni fa, pensando a un problema completamente diverso. Karpathy l’ha riscoperto a gennaio di quest’anno, a partire da un altro problema ancora. Io l’ho usata per cinque anni come semplice sistema di archiviazione, su Notion e sulle cartelle del computer, e poi per un caso fortunato, quando Claude ha aperto la possibilità di entrare nel mio file system locale, mi sono accorto che era anche qualcosa di completamente diverso da quello per cui l’avevo sempre adoperata. Le strutture giuste, quando esistono davvero, hanno questo tratto in comune. Resistono al tempo, e ogni tanto qualcuno le riprende in mano scoprendo che parlano una lingua nuova senza essere mai cambiate.

Se questo pezzo ti ha aperto qualcosa, mandalo a qualcuno che secondo te ne ha bisogno. Imprenditore, dipendente, libero professionista, non importa: chiunque produca documenti e debba ritrovarli ne può trarre qualcosa.

Lascia un commento

ARTICOLI CHE TI POTREBBERO INTERESSARE

1. Predecessore diretto (23/4/2026) — già citato come “settimana scorsa” “Stai usando Obsidian per sbaglio. (E quasi tutti lo fanno.)” https://open.substack.com/pub/ivanmosetti/p/stai-usando-obsidian-per-sbaglio

2. Evoluzione su agenti che lavorano sul vault (14/5/2026) — risponde alla domanda “chi muove le cose” lasciata aperta in fondo al pezzo “Mentre lavoro l’AI prende appunti. La domenica mi propone le idee.”https://open.substack.com/pub/ivanmosetti/p/sistema-editoriale-agente-pipeline-substack

3. Agenti che escono dal vault e operano su sistemi reali (12/5/2026) — estende il paradigma _System dall’archivio personale ai tool esterni “Meta Ads MCP: in sette minuti ho mandato in pensione due anni di wrapper artigianali”https://open.substack.com/pub/ivanmosetti/p/meta-mcp-fine-dei-wrapper

SOTTO IL PAYWALL TROVERAI IL PROMPT PER REALIZZARE IL TUO SECOND BRAIN

Read more

Hai aperto Obsidian. Hai visto quella schermata con i pallini luminosi che si connettono tra loro in tempo reale. Ti sei detto: “figo”. Hai cominciato a mettere dentro note, link, file, documenti. Hai guardato di nuovo il graph view. Hai pensato: “sembro un Tony Stark”.

E poi, dopo tre settimane, era diventata un’altra cartella di cose a caso sul tuo computer.

Normale. Ci siamo passati quasi tutti.

Il punto è che la maggior parte di chi usa Obsidian oggi lo usa come se fosse Notion con la modalità scura. O peggio, come Google Drive con i file in formato .md per sentirsi più tech.

Non è questo il punto.

Il punto vero non è l’interfaccia. Non è il graph view. Non è l’estetica da Jarvis col tema dark. Non sono i plugin, le hotkey.

Okay, il sistema di backlink lo e’. Ma non per il motivo che pensi. Lo spiego dopo.

Il punto principale e’ che Obsidian usa Markdown. E il Markdown, oggi, e’ il miglior sistema di archiviazione per un LLM che esiste. Non per un umano. Per un LLM.

E questa differenza cambia completamente la prospettiva su cosa stai costruendo.

Quasi nessuno l’ha ancora capito.

Prima di tutto: cos’è il Markdown e perché dovrebbe interessarti

Se non lo conosci, il Markdown è un formato di testo leggero. Apri un file .txt, aggiungi qualche simbolo convenzionale: # per i titoli, ** per il grassetto, - per le liste, > per le citazioni. Il risultato è un documento strutturato, leggibile, portabile.

Puoi aprire un file Markdown con Blocco Note di Windows e funziona uguale. Funziona su Mac, Linux, web, qualsiasi sistema operativo. È testo puro con un po’ di struttura sopra. L’opposto di un file .docx, che senza Microsoft Word diventa illeggibile.

Ma la cosa interessante non è che è leggibile per te.

E’ che e’ leggibile per un LLM. In modo nativo, diretto, efficiente. Senza overhead, senza conversioni, senza perdita di struttura e senza occupare troppo contesto nella chat, quindi consumando meno token!

Claude, GPT, Gemini, tutti i modelli con cui lavoriamo ogni giorno sono stati addestrati su miliardi di file in questo formato. GitHub ha decine di milioni di README.md. Wikipedia e’ strutturata in Markdown. La documentazione tecnica di quasi ogni software serio e’ in Markdown. I blog degli sviluppatori sono in Markdown. I paper tecnici condivisi online sono in Markdown.

Il Markdown e’ la lingua madre degli LLM. Non la parlano soltanto. Ci pensano.

Quando passi a un LLM un file Markdown ben strutturato, non deve interpretarlo in modo forzato, non deve fare salti logici per capire la gerarchia, non deve “tradurlo” mentalmente in qualcosa di comprensibile. Lo capisce direttamente. Come tu capisci immediatamente una lettera scritta in italiano senza dover decodificare niente.

E questa differenza, quando lavori su un sistema con decine o centinaia di file, cambia l’accuratezza, la velocita’, e la qualita’ delle risposte in modo misurabile. Non e’ percezione. E’ struttura.

Il problema che nessuno affronta davvero: la memoria degli LLM

Parliamoci chiaro su una cosa che di solito viene glissata nei contenuti sull’AI.

Quando chiudi una chat con Claude o con qualsiasi agente AI, cosa succede al contesto di quella conversazione? Sparisce. La prossima volta riparti da zero. L’LLM non sa chi sei, non sa di cosa avete parlato, non sa cosa hai gia’ provato, non sa niente dei tuoi progetti o dei tuoi clienti.

E’ come avere un collaboratore brillante con l’Alzaimer. Ogni mattina gli rispieghi il progetto. Ogni sessione ricostruisci il contesto. Ogni volta perdi qualche minuto a fare onboarding di un agente che dovrebbe gia’ sapere tutto.

Il problema si chiama memoria esterna. Come fai a dare a un LLM un contesto persistente che sopravviva alle sessioni? Come fai a fargli “ricordare” quello che sa su di te, sui tuoi clienti, sui tuoi workflow?

Negli ultimi anni sono nate tre generazioni di risposte a questa domanda. La maggior parte di chi lavora con l’AI e’ ancora ferma alla prima.

Generazione 1 — il RAG (Retrieval Augmented Generation)

E’ il metodo piu’ usato in azienda e nei sistemi enterprise. Funziona cosi’: hai un database di documenti, li converti in rappresentazioni numeriche chiamate vettori, e quando fai una domanda il sistema recupera i pezzi di testo matematicamente piu’ vicini alla tua query e li passa all’LLM come contesto temporaneo.

Funziona. Per quello per cui e’ stato pensato, funziona bene. Se hai 10.000 PDF aziendali e devi trovare la clausola giusta in un contratto di 200 pagine, il RAG e’ il tool giusto.

Ma il problema non e’ che il RAG funziona male con gli LLM. Il problema e’ che e’ stato progettato per recuperare frammenti da documenti statici in formato misto: PDF, Word, HTML, testo scansionato, tabelle, tutto insieme. Ogni formato deve essere parsato, convertito, normalizzato prima di diventare un vettore. Quella conversione introduce rumore. Perde struttura. L’LLM riceve frammenti de-contestualizzati, non documenti coerenti.

Il RAG ogni volta riparte da zero. Non accumula niente. Non costruisce connessioni tra concetti nel tempo. Recupera, risponde, dimentica.

Per la memoria personale di un professionista, che vuole un sistema che cresce e impara, e’ il tool sbagliato per il problema sbagliato.

Generazione 2 — Agentic File Search

Un passo avanti. Invece di fare query su un database vettoriale, l’agente naviga autonomamente un file system reale. Va dentro le cartelle, apre i file che sembrano rilevanti, legge il contenuto, poi risponde. Piu’ flessibile del RAG classico, piu’ adattabile a strutture non uniformi.

Ma il problema di fondo rimane identico: ogni sessione ricomincia da zero. L’agente cerca di nuovo ogni volta invece di sapere gia’. Non esiste una conoscenza cumulativa che cresce nel tempo. E’ piu’ intelligente nel trovare, non nel ricordare.

Generazione 3 — LLM Wiki

Qui cambia tutto il paradigma. Non si tratta piu’ di “recupera informazioni quando servono”. Si tratta di “costruisci una memoria che cresce nel tempo e che l’LLM mantiene attivamente”.

Invece di fare query su frammenti di documenti grezzi, costruisci una wiki in Markdown che l’LLM stesso compila, aggiorna e mantiene tra una sessione e l’altra. La conoscenza si accumula. Si organizza in pagine tematiche strutturate. Si collega tra file diversi attraverso link interni espliciti.

Un file crea riferimenti a un altro. Una nota di progetto punta alla nota del cliente. La nota del cliente punta al log delle call. Il log delle call punta al documento di strategia. Ogni connessione e’ esplicita, navigabile, incrementale.

E qui entra il sistema di backlink. Quello che ti sembrava solo una feature carina di Obsidian.

In Obsidian, quando scrivi nome-file dentro un documento, stai creando un link bidirezionale. File A punta a File B. Ma File B sa automaticamente che File A lo ha linkato. Puoi navigare la connessione in entrambe le direzioni senza dover cercare niente.

Per un umano e’ comodo. Per un LLM e’ qualcosa di diverso.

Quando un agente AI legge un file Markdown con backlink espliciti, non deve inferire le relazioni tra concetti. Le relazioni sono scritte nel testo, nel formato che conosce meglio. Il file dice esplicitamente: “questo argomento e’ connesso a questo altro argomento”. L’LLM non deve indovinare, non deve fare embedding e calcoli di similarita’. Legge la connessione, la attraversa, e costruisce il contesto.

E’ la differenza tra dire a qualcuno “Mario e’ il responsabile di quel progetto” e sperare che lo capisca dal contesto.

Esattamente come funzionano i neuroni umani: non hai una memoria lineare, hai una rete di associazioni con connessioni esplicite. Il cervello non recupera informazioni come un database. Associa, connette, contestualizza.

E il graph view di Obsidian che ti sembrava solo una roba figa da guardare? Stavi guardando la rappresentazione visiva di questa rete di backlink. Connessioni che un LLM puo’ attraversare, esplorare, e usare per risponderti in modo contestuale e preciso. Molto piu’ preciso di qualsiasi sistema RAG su documenti misti.

Adesso capisci perche’ i pallini si muovono in quel modo.

Da dove e’ partita questa idea: il post che ha fatto girare tutto

Qualche giorno fa (2 Aprile, 2026), uno dei ricercatori piu’ influenti nella storia degli LLM pubblica un post su X.

Ex direttore AI di Tesla. Co-fondatore di OpenAI. Creatore del corso di deep learning piu’ seguito al mondo. Una delle voci piu’ seguite nel campo dell’intelligenza artificiale applicata.

Il titolo del post era semplice: “LLM Knowledge Bases”.

Il contenuto meno.

Raccontava una cosa apparentemente banale: aveva iniziato a usare gli LLM non principalmente per generare codice, ma per costruire knowledge base personali su argomenti di ricerca. File Markdown strutturati, aggiornati e mantenuti nel tempo dall’LLM stesso, che diventavano piu’ ricchi e piu’ connessi ad ogni sessione.

Il post ha preso 16 milioni di visualizzazioni nel giro di pochi giorni. Due giorni dopo ha pubblicato un gist su GitHub con l’architettura tecnica completa del sistema. Migliaia di star in una settimana.

La frase che ha fatto girare di piu’ era questa:

“Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.”

Tradotto: Obsidian e’ l’ambiente di sviluppo. L’LLM e’ il programmatore. La wiki Markdown e’ il codice che viene costruito e mantenuto nel tempo.

Non stava parlando di Obsidian come app per le note personali. Stava parlando di un sistema di memoria persistente, navigabile, incrementale, dove ogni file Markdown e’ un neurone della rete e ogni link interno e’ una sinapsi.

La struttura tecnica che propone e’ a tre livelli: una cartella raw/ per le fonti grezze originali immutabili, una cartella wiki/ dove l’LLM genera e aggiorna pagine di conoscenza strutturata sintetizzando le fonti, e un file CLAUDE.md come schema operativo che guida l’agente su come comportarsi con quel sistema specifico.

Non e’ un esperimento mentale. E’ architettura funzionante che puoi installare sul tuo computer oggi.

Ho preso quell’idea e l’ho portata nel mio lavoro quotidiano

Quella architettura e’ stata pensata principalmente per la ricerca e per il codice. Io l’ho adattata al flusso di lavoro di un marketer che gestisce un’agenzia, clienti attivi, contenuti su tre piattaforme, partner, e decine di workflow paralleli.

Read more