A fine giugno, con Raffaele, abbiamo pubblicato cowork-os e ho scritto «CONTEXT IS GOLD!» in un post. Lo penso ancora. Da allora il company brain di Yempik è entrato nel lavoro quotidiano di persone e agenti, e scrivere il Markdown si è rivelato la parte facile.
La tesi: il contesto vale qualcosa quando un'altra persona o un altro agente può trovarlo, capire quando e dove è vero, correggerlo e riusarlo senza la conversazione in cui è nato. Il formato conta poco. Contano chi ha l'ultima parola, se la ritrovi, quanto dura, chi può vederla e come passa da un lavoro al successivo. Le regole che seguono vengono da errori nostri.
Approvato non vuol dire vero.
Quando abbiamo riletto tutto il Brain dall'inizio, abbiamo trovato schede approvate e citabili il cui testo diceva «da validare» o «non l'ho verificato». Lo stato diceva una cosa, il contenuto un'altra. Un agente che guarda solo lo stato trasforma un'ipotesi in una decisione che nessuno ha preso. Trust me bro, in versione database.
Abbiamo separato le due domande. La prima è se un'affermazione è entrata nel Brain. La seconda è quanto è solida: ipotesi, proposta, decisione presa, fatto verificato. La regola sta in una riga: un'ipotesi approvata resta un'ipotesi, e chi la riusa lo dice anche nella risposta.
Quando faccio formazione lo spiego così: se scrivi a un agente «sono Simone Bova», ti crede. Se scrivi «ipotizzo di essere Simone Bova», lo tratta come un'ipotesi. L'agente non può verificare quasi niente di quello che gli dai, quindi quanto è sicura un'informazione deve stare scritto accanto all'informazione stessa.
Un passaggio di consegne è finito quando chi riceve riesce a leggere.
Le automazioni commerciali di Yempik hanno avuto lo stesso problema più volte. Contatti verificati consegnati in chat e mai salvati nel Brain, così la coda dei primi contatti si è fermata. Una routine che contava su file presenti sul mio computer, che i run programmati in cloud non vedono.
Ogni volta il lavoro era fatto bene. Io lo vedevo, la macchina dopo di me no. Abbiamo scritto una regola: ogni dato che serve a un passo successivo vive in un posto che quel passo può leggere, e ogni automazione dichiara cosa legge, cosa scrive e dove. Quello che finisce in chat è per il founder, e se serve anche alla macchina va scritto anche per lei. Il test si fa dall'ambiente di chi riceve, perché la tua sessione vede cose che il run programmato non vedrà mai.
Una ricerca vuota deve dire perché è vuota.
Abbiamo fatto lavorare un agente sul Brain per un'intera giornata vera. La memoria tra una sessione e l'altra reggeva. La ricerca invece non trovava niente su domande normali che dovevano portare a schede approvate.
La ricerca in sé funzionava. Il passo che rende trovabile una scheda dopo l'approvazione falliva in silenzio, e nessun log lo segnalava. Una ricerca rotta e una ricerca senza risultati davano la stessa risposta. Adesso un check confronta di continuo le schede approvate con quelle trovabili, la ricerca dice quando è indietro, e il test che conta percorre tutta la strada, dalla scrittura alla ricerca. Se il tuo brain tiene una copia derivata dei dati, prima o poi le due divergeranno: confrontale e fai dichiarare al sistema quando non sa.
Due versioni in conflitto hanno bisogno di una relazione scritta.
Nella stessa rilettura c'erano due decisioni sul reminder per chi deve approvare le schede: una diceva dopo un'ora, l'altra dopo un giorno. Entrambe valide, nessuna segnata come superata.
«Usa il documento più recente» qui non basta. Quando una scheda è stata scritta, da quando vale e quando smette di valere sono informazioni diverse. Adesso un'iniziativa chiusa conserva la sua data di fine invece di sparire, e ogni risposta dice qual è quella corrente. Quando due fonti si contraddicono le teniamo entrambe e scriviamo che rapporto hanno: si smentiscono, una sostituisce l'altra, oppure parlano di casi diversi.
Il brain deve sapere dove vive la verità operativa, senza copiarla.
Abbiamo scritto un contratto tra i nostri sistemi. Il Company Brain tiene quello che Yempik deve ricordare. Linear quello che deve fare, GitHub quello che ha costruito, il CRM con chi lavora. Le chat non sono una fonte di verità. Se un'informazione sta in più posti, ha un proprietario e gli altri rimandano a lui.
La riga più utile riguarda la chiusura del lavoro: quando un task finisce, il Brain cambia solo se è cambiata una verità destinata a durare. Un fix ordinario non diventa una scheda. Senza questa regola il Brain si riempie di stato che invecchia in una settimana, e l'agente lo legge come se fosse vero oggi.
Anche un collegamento è un'informazione. Nel grafo del Brain chi naviga vede un collegamento solo se può vedere entrambi i documenti che unisce, e un collegamento proposto da un agente aspetta una persona prima di valere. Puoi proteggere il testo di due documenti e far trapelare lo stesso il fatto che sono collegati.
Prima di cambiare modello, guarda le istruzioni che gli arrivano.
In autunno ho notato che Claude Code archiviava benissimo nel mio second brain e male in un'altra memoria collegata dall'esterno. Stesso modello, stesse possibilità di scrittura. Cambiava il regolamento che il modello aveva davanti. Nel vault le regole del progetto sono sempre in contesto e le fonti si leggono per intero. Sull'altra strada il modello riceveva gli strumenti e una guida più povera, che lo spingeva a spezzare tutto in frammenti e non diceva mai quando il lavoro era finito.
Ho riunito le regole in un solo regolamento condiviso dalle due strade. La misura prima e dopo è ancora da fare. Da quel lavoro sono uscite due regole che applico ovunque.
- Un'ingestione è completa se un lettore futuro riesce a ricostruire decisione, ragioni, alternative, vincoli e domande aperte.
- Scritture riuscite e link puliti provano poco. Completo vuol dire rileggere quello che hai salvato, confrontarlo con la fonte e dichiarare cosa resta aperto.
L'obiezione più forte: sono solo note, il modello non impara niente.
Un amico founder, in una call, me l'ha detto senza giri di parole: quello che l'agente «impara» non finisce nel modello, sono file di testo con delle note. Ha ragione. Una cosa scoperta oggi in una sessione non rende il modello più capace domani.
La mia risposta è dire con precisione cosa migliora. Migliorano le prove che l'agente ha a disposizione, la sua capacità di ritrovarle e il modo in cui esegue un processo. Il modello resta quello. Quando qualcuno ti promette «l'agente che impara la tua azienda», chiedigli quale di queste intende.
C'è anche l'obiezione opposta: più memoria è sempre meglio. Quando faccio formazione chiedo di leggere ogni riga dei propri file di memoria almeno una volta a settimana, e dico che spegnerla va bene se intralcia il lavoro.
L'importante è che sia una scelta vostra e soprattutto consapevole.
Da lunedì
- Tieni separato il fatto che una scheda sia approvata da quanto è solida, e fai arrivare quella differenza fino alla risposta dell'agente.
- Per ogni automazione scrivi cosa legge, cosa scrive e dove. Poi provala dall'ambiente in cui girerà.
- Fai dire al sistema quando una risposta vuota dipende da dati mancanti, e confronta di continuo i dati originali con le loro copie.
- Quando due fonti divergono, scrivi che rapporto hanno. Dai una data di fine alle iniziative chiuse.
- Dai un proprietario a ogni tipo di informazione. Il brain tiene ragioni e collegamenti, lo stato vivo lo chiedi al sistema che lo possiede.
- Prima di cambiare modello, metti fianco a fianco le istruzioni che riceve su ogni strada.