Il secondo cervello dell’azienda: dal wiki alle competenze, è tutta una questione di contesto8 min read

Ho pensato molto a tutto l’hype che circonda il “secondo cervello”. Ne ho discusso con altri del settore e con i miei colleghi che stanno costruendo un secondo cervello o ne hanno una versione.

Per chi non lo conoscesse, il secondo movimento cerebrale è iniziato con l’idea “Wiki” di Andrej Karpathy: organizzare la conoscenza personale dell’agente in una sorta di struttura Wiki interconnessa di file MD locali. Successivamente ciò si è esteso all’organizzazione dei dati personali in un formato molto più ampio, con gli utenti che spesso utilizzano Obsidian per organizzare e visualizzare note e aggiungere dati dalle riunioni (trascrizioni Granola/Whisperflow/Zoom) nel Wiki.

basi-di-conoscenza-razzo-karpathy: inizio

basi-di-conoscenza-razzo-karpathy:fine

Man mano che la “Wiki” si espandeva, è diventato ovvio che c’è un valore reale nel condividere le informazioni in essa contenute. Cominciano così a fiorire i progetti del “secondo cervello aziendale”. La versione utopica di un secondo cervello consiste nel far trascrivere tutto il possibile: chiamate zoom, riunioni F2F, anche interazioni casuali, e-mail, messaggi lenti, documenti, il tutto in un enorme database di dati come Snowflake. Immagina che chiunque in azienda possa chiedere a questa istanza di Snowflake tutto ciò che desidera e ottenere immediatamente una risposta a ogni domanda.

Ops, non è una buona idea. Innanzitutto, è molto costoso. La quantità di dati che entra in qualcosa di simile è semplicemente pazzesca e il loro recupero diventa estremamente difficile, lento e costoso. La sicurezza e la separazione dei dati diventano un problema. Come evitare che dati personali, dati finanziari, decisioni gestionali, dati sulle risorse umane o persino decisioni di licenziare qualcuno entrino nelle trascrizioni e diventino accessibili 1:1? Non tutti dovrebbe sapere tutto…

Inoltre, chi ne ha bisogno, cosa ci salva ed è anche una buona idea?

Direi che in generale una versione contenuta di questo è una buona idea. Gran parte del motivo per cui esiste il middle management è quello di sollevare le questioni a monte e chiarire le decisioni a valle. Gran parte di questo può ora essere fatto con un secondo cervello.

Secondo cervello per i team tecnici

Un secondo cervello tecnico può essere molto più semplice da mantenere. Molte aziende utilizzano semplicemente una directory Dropbox/Google Drive/OneDrive che contiene la conoscenza condivisa che Claude/Codex può condividere. L’automazione per inviarlo a un repository Git è abbastanza semplice, oppure puoi davvero utilizzare Github per gestire anche questo (immagino che sia uno sforzo molto piccolo per OpenAI/Anthropic supportare questo scenario senza dover installare competenze personalizzate per gestire questo tipo di cose). La fonte della verità ora diventa il repository Github e le copie locali sono repository Git locali.

Ciò può aggiungere conoscenze e capacità come competenze condivise, decisioni condivise, progetti architettonici, progetti visivi (decisioni sul sistema di progettazione, ad esempio) e varie altre decisioni sui prodotti aziendali.

I piccoli team non hanno davvero bisogno di molto oltre una semplice sincronizzazione del repository, ma le aziende più grandi con numerosi team più grandi si troveranno molto rapidamente a dover affrontare gravi limitazioni. I problemi più gravi riguardano l’avvelenamento del contesto in cui un particolare utente potrebbe prendere decisioni locali che sono in conflitto con i dati del secondo cervello, introducendo dati contrastanti o sovrascrivendo inavvertitamente le decisioni aziendali (in alcuni casi forse intenzionalmente?).

Mantenerlo in git e fonderlo può essere fatto utilizzando un agente dedicato che cerca i conflitti e può avvisare un utente se le sue modifiche sono in conflitto, risolvere i conflitti e unire i risultati.

Tieni presente che questo non è un buon metodo per conservare la documentazione del progetto. Per questo, la soluzione migliore è includere il wiki come parte integrante del progetto stesso. È abbastanza facile da creare. Metti semplicemente da parte un agente di codifica e gli chiedi di esaminare il progetto, documentarlo accuratamente in una cartella di documenti, suddiviso per architettura, trucchi, decisioni sul prodotto, decisioni tecniche e altre cose che conclude potrebbero essere utili in piccoli file md contenibili. La chiave è dirgli di assicurarsi che il codice e readme.md puntino tutti alla directory dei documenti per garantire che venga fatto riferimento ovunque e considerato una parte del progetto e non una risorsa esterna. La cosa fondamentale che l’agente deve sapere è che l’intento qui è quello di consentire un rapido inserimento di un altro agente nel progetto per evitare insidie, buche e voragini tecniche…

Una volta integrato nella struttura stessa del progetto repository, l’agente di codifica lo manterrà come se fosse codice. Lo leggerà come se fosse parte del codice e se qualcosa cambia, adatterà o modificherà la documentazione (ricorda che “la documentazione è che il codice è facile da leggere e cancellare” o “la documentazione diventa obsoleta nel momento in cui lascia la tastiera” – fidati dell’intelligenza artificiale per mantenerli, quindi non sono più veri).

Secondo cervello per i team di prodotto, marketing e non tecnici

Questo tipo di secondo cervello può essere davvero interessante per i team tecnici, ma fare la stessa cosa per i team non tecnici sarà estremamente difficile.

Prendi ad esempio un team di avvocati, hanno una serie di conoscenze molto specifiche e si estendono a e-mail, Slack, file di parole e altri documenti. Lo stesso vale per i contabili, le vendite, il successo dei clienti, ecc. Ognuno di loro ha la propria conoscenza del secondo cervello.

Oltre a ciò, il management probabilmente desidera che i dati emergano (non filtrati dal management intermedio) e il team potrebbe aver bisogno delle informazioni generate dal management. Come produrre un grafico della conoscenza scalabile che sia protetto e separato?

Ci sono alcuni approcci che potrebbero rendere le cose più facili, almeno finché i grandi non risolveranno questo problema, si spera in modo aperto, ma più probabilmente attraverso una costosa soluzione chiusa.

1. Secondo cervello personale – ogni persona che lo desidera, può trascrivere i propri incontri e mantenere il proprio secondo cervello. L’ossidiana è molto utile per questo, qualsiasi agente può sostanzialmente ordinarla e ripulirla. Utilizza il meccanismo di sonno REM per ottimizzarlo: un agente dovrebbe svegliarsi di notte, identificare tutte le informazioni raccolte durante il giorno, trovare tutte le informazioni critiche e importanti da conservare per il futuro e organizzarle in modo facilmente recuperabile in cartelle e file MD. Ciò significa che se hai parlato con un particolare cliente, quel cliente avrà un file md aggiornato che riflette le informazioni che è importante ricordare su di lui, su cosa state lavorando insieme, ecc. Lo stesso vale per i progetti. Ci saranno sovrapposizioni: la sovrapposizione è positiva: va bene che le informazioni su un particolare progetto risiedano sia nel file della persona con cui hai parlato, sia nell’azienda che nei file del progetto. Lascia che sia l’agente a gestirlo per te. In caso di domande, imposta questa come origine dati principale per il tuo agente. Puoi esporre il tuo agente alle tue email/conversazioni/ecc. – Assicurati solo di non trascrivere cose che non vuoi che siano documentate (non trasformiamolo in un reality show o in una soap).

2. Secondo cervello a livello di squadra – un secondo livello di dati include dati che si trovano nel secondo cervello personale e che l’agente è sicuro al 100% siano rilevanti per l’intero team o dati che hanno avuto origine in riunioni a livello di team che sono, per loro natura, basate sul team. Un agente può anche raccogliere dati per questo secondo cervello dai canali slack del tuo team: non dovrebbero essere nei canali 1:1 o nelle chiamate zoom. Una volta recuperati i dati, un agente può organizzarli in tempo reale o di notte e segnalare incoerenze dove le decisioni sono state ribaltate o non corrispondono a decisioni personali o gestionali. Questi dovrebbero essere evidenziati e avvisati alla persona che prende la decisione incompatibile in modo che possa fare le proprie scelte in modo informato.

3. Secondo cervello a livello gestionale – Si tratta fondamentalmente di un secondo cervello a livello di squadra, ma a causa della sensibilità dei dati e delle decisioni prese, dovrebbe essere gestito in modo molto più sfumato. Qui dovrebbero essere condivisi solo le decisioni finali e i dati pubblici per evitare potenziali fughe di informazioni nel resto dell’azienda. Potrebbe essere una buona idea che un essere umano esamini alcuni dati, almeno all’inizio, per garantire la sicurezza dei dati. È anche una buona idea lasciare il cervello del management fuori dal secondo cervello dell’azienda.

4. Il secondo cervello dell’azienda – questo è il più difficile e dovrebbe contenere solo dati concreti, informativi che potrebbero essere rilevanti per l’intera azienda. Solo risultati finanziari riportati, ad esempio informazioni sul personale (chi ricopre quale posizione).

Ciò lascia fuori molti dati, inclusi ad esempio i dati sul sentiment, che il management vuole sentire dall’intero team. Questo può essere raccolto separatamente o raccolto dal rallentamento e da altre fonti. Non è una buona idea raccogliere questo tipo di dati direttamente dal cervello dell’azienda.

Allora, cosa cerchi in un secondo cervello o in un cervello aziendale, hai provato a costruirne uno e quali sono state le tue conclusioni?