Il Company Brain di Hyper: come progettare una knowledge base per agenti IA

Ciò che mi ha fatto fermare su Hyper non è stata l’espressione company brain. È stato il modo in cui nomina un problema in cui molti team stanno già cadendo: gli agenti IA ora sanno modificare codice per più turni, scrivere email ed eseguire script, ma spesso non hanno idea di quale piano il team abbia scartato ieri. Chiedi a Codex di modificare una pagina di checkout e potrebbe appoggiarsi al linguaggio di prodotto di una vecchia PR. Chiedi a Claude Code di ispezionare un vincolo di API e potrebbe riaprire Drive perdendo la decisione più recente su Slack. Una collega umana aggiunge naturalmente: «Non usare più quel piano.» Un agente non sviluppa da solo questa memoria condivisa.

Tratterei Hyper prima come un caso di studio di architettura. È ancora presto, e i materiali pubblici non equivalgono a una validazione di terze parti. Eppure i dettagli sulla sua pagina YC e nella discussione Launch HN aiutano a chiarire cosa deve davvero fare una knowledge base aziendale per agenti IA: non è solo ricerca di documenti, né solo un connettore MCP. È un modo per far agire gli agenti nel contesto aziendale giusto, attuale e consapevole dei permessi.

Dove il RAG normale si blocca

Il RAG normale è bravo a trovare chunk nei documenti. Suddividi Markdown, PDF e pagine web in chunk, li embeddizzi, recuperi contenuti simili alla query e lasci che il modello componga una risposta. BetterLink ha trattato questa via nell’architettura RAG + agente, e basta per Q&A di conoscenza, FAQ di supporto e spiegazione di codebase.

Il contesto aziendale è più disordinato. L’agente non deve solo trovare contenuti simili. Deve anche sapere se il contenuto è ancora valido, chi può vederlo e perché la decisione è stata presa.

Vecchie e nuove informazioni si scontrano

Prendi una piccola decisione di release. La riunione di lunedì dice: «Rilasciare venerdì.» Mercoledì il feedback dei clienti cambia e il product owner sposta il lancio a lunedì prossimo. Un database vettoriale può memorizzare entrambe le affermazioni. Quale viene prima dipende dalla query, dall’embedding, dal chunking e dal ranking. Se l’agente recupera la vecchia nota «venerdì», continuerà a scrivere l’annuncio sbagliato e a pianificare il lavoro sbagliato.

Un design più sicuro conserva entrambi i fatti ma marca il nuovo come sostituto del vecchio: chi l’ha detto, quando, quale ambito è interessato e perché la conclusione precedente è diventata invalida. Così, quando l’agente risponde a «Perché è stato rinviato?», può ripercorrere la storia della decisione invece di perdere il vecchio contesto.

I permessi devono agire prima della risposta

Appena una knowledge base aziendale alimenta un agente capace di agire, i permessi smettono di essere un dettaglio. Vendite, supporto, ingegneria e direzione possono chiedere dello stesso cliente e dovrebbero ricevere ambiti di informazione diversi. Le linee guida di OpenAI sui connettori di team fanno un punto simile: ChatGPT vede solo contenuti a cui l’utente ha già accesso, e i connettori rispettano i confini di permesso esistenti.

Questo controllo dovrebbe avvenire prima del retrieval, non dopo che il modello ha già visto il contesto e gli si chiede di comportarsi bene. Filtra prima i dati invisibili; poi recupera, ordina e inietta. Altrimenti l’agente può far trapelare informazioni sensibili tramite log, bozze o chiamate a strumenti.

Agli agenti serve anche il perché

Molti documenti aziendali registrano risultati, non ragioni. Un piano di design può essere stato scartato perché l’allineamento al brand era sbagliato, le vendite hanno sentito resistenza dei clienti, il debito tecnico era troppo alto, o il team semplicemente non aveva capacità in quel momento. Se l’agente vede solo il risultato, può ripetere lo stesso errore in un contesto leggermente diverso.

L’aggiornamento sulla memoria di OpenAI inquadra la memoria utile attorno al portare avanti il contesto, seguire le preferenze e restare aggiornati nel tempo. A livello aziendale aggiungerei un requisito: il sistema dovrebbe spiegare i vincoli dietro una decisione. Senza questo strato, un agente cerca solo più in fretta, non capisce meglio l’azienda.

Alibaba Cloud - Scelta top per sviluppatori, 15% di sconto esclusivo su Lighthouse

Ottieni -15% →Pubbl.

Cosa rivelano i materiali pubblici di Hyper

Ci sono alcuni dettagli nel lancio pubblico di Hyper che mi interessano. Non provano che il prodotto sia perfetto, ma sono più concreti di «mettere Slack e Drive in un database vettoriale».

Il primo dettaglio è la separazione tra episodes e facts. Nel thread di lancio HN, i fondatori descrivono le fonti grezze come episodes: documenti, email, calendari, Slack, note Granola e così via. I facts sono il significato estratto da quegli episodes. Hanno la forma di record subject-predicate-object, con un plain summary più timestamp di quando il fatto è stato introdotto e invalidato. Il materiale grezzo resta disponibile come source of truth, mentre i facts estratti supportano un ragionamento e un retrieval più veloci.

Il secondo dettaglio sono gli archi di relazione tra facts. La discussione pubblica menziona facts in tensione tra loro, derivati l’uno dall’altro, o sostituiti (superseded) da un fatto più recente. Questo conta per gli agenti perché il contesto aziendale non è una cartella piatta di note. È una storia di decisioni che cambiano.

Il terzo dettaglio è il retrieval ibrido. Hyper ha menzionato query expansion, ricerca semantica via embedding, Postgres full-text search e reciprocal rank fusion. Niente di mistico, ma è pratico. Il retrieval semantico è bravo con il significato. La ricerca full-text è migliore per nomi di clienti esatti, ID di ticket, nomi di funzioni e numeri di contratto. La fusione riduce la dipendenza da un singolo percorso di retrieval.

Il quarto dettaglio è il tagging dei permessi. Ogni fatto porta provenienza e access-control tag, e il retrieval viene valutato solo contro facts ed episodes a cui l’utente ha accesso. Senza questo, un company brain diventa in fretta un rischio di sicurezza.

Il quinto dettaglio è la divisione tra hook e MCP. La documentazione MCP descrive MCP come uno standard aperto per collegare le applicazioni IA a sistemi esterni, e l’OpenAI Agents SDK supporta anch’esso più integrazioni MCP. MCP è utile quando un agente interroga attivamente uno strumento, ma dipende dal fatto che l’agente riconosca quando lo strumento va chiamato. Hyper ha detto nel thread HN che per strumenti come Claude Code, Codex e Cursor usa anche lifecycle hook per iniettare o estrarre contesto quando una sessione inizia, un prompt viene inviato o un turno di agente finisce. Questo compromesso è controverso, soprattutto sulla trasparenza dell’installazione, ma indica un problema reale: certo contesto non può dipendere dal fatto che l’agente si ricordi di chiederlo.

Costruire un company brain come pezzi verificabili

Se il tuo team non vuole ancora introdurre un nuovo fornitore, puoi comunque costruire una versione piccola. Non partire collegando ogni fonte dati. Parti separando il sistema in pezzi che puoi davvero esaminare.

Source: gli input grezzi devono essere riproducibili

Lo strato sorgente non ha bisogno di copertura totale dal primo giorno. Punti di partenza migliori sono i Markdown di decisioni di prodotto, i riepiloghi delle PR recenti, le issue pubbliche e gli articoli della knowledge base di supporto. I dati Slack, email e CRM sono densi, ma anche rumorosi e carichi di permessi. Aggiungili dopo.

Ogni elemento sorgente dovrebbe portare metadati di base: tipo di fonte, URL o percorso file originale, ora di creazione, ora di aggiornamento, autore, ambito di visibilità e un hash. Se un fatto viene estratto male in seguito, il team deve poter tornare al testo originale.

Fact: un fatto dovrebbe essere più di un riassunto

Un fatto utilizzabile ha bisogno di campi come subject, predicate, object, summary, source, ora di introduzione, ora di invalidazione, tag di permesso, confidenza e record di correzione umana. Non è accumulo di campi. Dà confini all’agente quando risponde.

Per esempio:

L’estrazione dei fatti non sarà perfetta al primo tentativo, quindi serve un percorso di correzione umana. Nella discussione HN, quando qualcuno ha chiesto dei dati disordinati e contraddittori delle aziende mature, il fondatore di Hyper ha menzionato correzioni dure tramite uno skill MCP come /correct. Questa direzione vale la pena copiarla: lascia che un umano dica esplicitamente «Questo è sbagliato; usa questo» e conserva la traccia di correzione.

Retrieval: la ricerca ibrida è più affidabile di un singolo percorso

Il retrieval vettoriale è utile per il significato sfumato, ma nomi di clienti, SKU, ID di ticket, nomi di funzioni e numeri di contratto spesso richiedono corrispondenze per parola chiave. Dividerei il retrieval in tre passi:

1. Filtrare per identità, progetto, fonte dati e permessi dell’utente.
2. Eseguire in parallelo ricerca semantica, ricerca full-text ed espansione del vicinato del grafo.
3. Fondere o riordinare i risultati, poi iniettare solo un piccolo set di fatti molto rilevanti.

Più contesto non è sempre meglio. Se il contesto è troppo ampio, il modello tratterà fatti non correlati come indizi. Un default migliore è iniettare 5-15 fatti stretti con provenienza e confidenza. Se l’informazione manca, l’agente deve chiedere o controllare la fonte originale.

Injection: MCP, hook e contesto manuale hanno confini diversi

MCP è un punto di ingresso, non un sistema di memoria completo. Lascia che gli agenti accedano a strumenti e fonti dati, e può esporre capacità come search_company_facts, correct_fact o get_decision_history. Puoi estendere il pattern della chiamata a strumenti da parte degli agenti ed esporre la knowledge base aziendale come strumento.

KiloClaw - OpenClaw gestito per enterprise: orchestrazione agenti IA e routing intelligente

Inizia →Pubbl.

Gli hook sono più stabili perché possono iniettare contesto automaticamente all’avvio di una sessione o all’invio di un prompt, senza aspettare che il modello chiami uno strumento. Comportano anche un rischio. Gli utenti devono sapere cosa è stato installato, quando viene eseguito, cosa legge e come disattivarlo. Questo punto ha suscitato resistenza nei commenti HN, e i piccoli team dovrebbero rendere visibili avvisi, log e interruttori.

Il contesto manuale resta utile. Per task ad alto rischio, lasciare che un umano scelga quale conoscenza di progetto è consentita per questa esecuzione può essere più sicuro dell’automazione totale. AI-first non significa che ogni passo debba essere senza supervisione.

Governance: correzione, export e audit devono arrivare presto

Più un company brain diventa utile, più è costoso migrare altrove. Su HN sono state sollevate preoccupazioni di vendor lock-in, e sono ragionevoli. Se ogni agente dipende dallo stesso strato di conoscenza, export, cancellazione, backup e audit non sono funzioni bonus.

Farei queste domande durante il pilota: i facts si possono esportare come JSON o CSV? Gli episodes grezzi si possono cancellare? Un cambio di permesso attiva un nuovo filtraggio? C’è un log di quale fatto un agente ha usato in quale task? Una correzione umana sovrascrive un vecchio fatto o conserva una catena di storia? Chiedere presto risparmia debito dopo.

Come scegliere tra le opzioni

Queste opzioni risolvono problemi diversi, quindi i nomi possono ingannare.

Se i dipendenti devono solo chiedere «Dov’è la policy delle spese?», la ricerca enterprise o il RAG normale basta. Se un agente deve modificare codice, inviare email, scrivere follow-up di vendita o riassumere il rischio cliente, il sistema ha bisogno di più: questo fatto è ancora valido? La fonte è affidabile? L’utente è autorizzato a vederlo? L’azione ha bisogno di conferma?

I connettori di team di OpenAI portano già contenuti dagli strumenti del team nelle conversazioni. L’ecosistema MCP rende più facile per gli agenti collegarsi a più strumenti. Un company brain si colloca tra questi strati: trasforma contenuti sparsi in contesto aziendale continuamente aggiornato, tracciabile, filtrato per permessi e riutilizzabile da diversi agenti.

Un pilota di 7 giorni: parti da un workflow stretto

Non devi collegare tutta l’azienda per testare un company brain. Scegli un workflow di agente a basso rischio e ad alta frequenza, e fallo girare una settimana.

Giorni 1-2: scegliere workflow e fonti

Scegli uno scenario chiaramente delimitato, come «chiedere a Codex di aggiornare una piccola funzionalità in base agli ultimi vincoli di prodotto» o «chiedere a un agente di supporto di redigere una risposta da note di bug recenti». Collega solo tre tipi di fonti: doc di decisioni di prodotto, riepiloghi delle PR recenti e issue pubbliche. Non partire con tutti i dati Slack, email e CRM.

Scrivi l’ambito proibito: niente email reali, niente modifiche alla configurazione di produzione, niente dati finanziari o HR e niente fatti senza fonte trattati come conclusioni.

Giorni 3-4: estrarre fatti e relazioni di conflitto

Estrai 50-100 fatti da quelle fonti. Fanne una parte a mano, poi con l’aiuto di un modello. Ogni fatto dovrebbe includere fonte, tempo, permessi e confidenza. In caso di conflitto, non cancellare in fretta il vecchio. Marca la relazione: supersedes, supplements, conflicts with o needs confirmation.

Puoi partire con uno schema semplice. Un database a grafo complesso non serve per un pilota. Tabelle Postgres, JSONB, indici full-text ed estensioni vettoriali possono reggere un piccolo esperimento. La discussione pubblica di Hyper ha anche menzionato che Postgres resta comodo in questo tipo di sistema, perché metadati strutturati e relazioni tipo grafo possono convivere.

Giorni 5-6: iniettare contesto e rieseguire i task

Aggiungi uno strumento o un hook all’agente: dato il task corrente, restituisce 5-15 fatti rilevanti con provenienza. Poi riesegui 20 task reali e segui tre numeri:

🔥 Non sprecare mesi su prodotti senza domanda! Valida i punti di forza del tuo SaaS con Adsterra e un piccolo budget ➡️

Testa ora →Pubbl.

• Quante volte gli umani devono ancora aggiungere contesto di sfondo?
• Quante volte l’agente cita fatti obsoleti o errati?
• Compare qualche fatto non autorizzato, o un contesto troppo ampio fa deviare l’agente?

Non giudicare solo se l’output sembra rifinito. Il valore di un company brain sta nel ridurre spiegazioni ripetute, abbassare gli errori da fatti obsoleti e rendere l’agente più cauto quando le prove sono incomplete.

Giorno 7: estendere, mettere in pausa o cambiare direzione

Se solo pochi dei 20 task ne traggono beneficio, non estendere ancora a tutta l’azienda. Il workflow potrebbe non adattarsi, o l’estrazione dei fatti potrebbe essere troppo grossolana. Se le richieste di chiarimento calano, le citazioni obsolete diminuiscono e non compaiono fatti non autorizzati, aggiungi un’altra fonte, come note di riunione o un canale Slack selezionato.

Il passo successivo è combinare questo con il monitoraggio e recupero degli agenti IA: quando l’agente usa un fatto a bassa confidenza, un fatto contraddittorio o un’azione ad alto rischio, instradalo verso una conferma umana.

Rendere espliciti i rischi prima dell’adozione

Appena una knowledge base aziendale si collega agli agenti, non è più un semplice progetto di retrieval di informazioni. Alcuni rischi vanno scritti presto nel piano.

Il primo è la privacy e i confini di addestramento. Il fondatore di Hyper ha detto nei commenti HN che non addestrano su dati ospitati né li vendono, e ha rimandato a FAQ e privacy policy. Poiché la pagina ufficiale di privacy non era leggibile dal mio crawler, non ne dedurrei i dettagli. I team dovrebbero esaminare contratti, termini di trattamento dati, periodi di conservazione e workflow di cancellazione invece di affidarsi a un post di lancio.

Il secondo è la trasparenza degli hook. L’iniezione automatica di contesto è più affidabile dello sperare che un agente si ricordi di chiamare MCP, ma gli utenti devono sapere cosa è installato sulle loro macchine. Avvisi di installazione, log di runtime, interruttori di disattivazione e configurazione visibile dovrebbero essere ovvi.

Il terzo è la storia inquinata. Le aziende mature hanno spesso vecchi documenti contraddittori, e il più recente non è sempre più autorevole. Nei workflow legali, finanziari, religiosi o governativi, un documento più vecchio può essere la fonte che fa fede. Il sistema non può ordinare tutto per recency. Fonti e ruoli diversi hanno bisogno di pesi diversi.

Il quarto è il vendor lock-in. Più a lungo un company brain è usato, più assomiglia a una parte del sistema operativo dell’azienda. Formati di export, strategia di backup, opzioni di self-hosting e piani di uscita d’emergenza vanno verificati presto. Senza di essi, il flusso a breve termine può diventare una trappola a lungo termine.

Lascia che il sistema dica di non essere sicuro

Mi piace la direzione che Hyper spinge: se gli agenti entreranno più a fondo nei workflow di team, hanno bisogno di un contesto aziendale più stabile di quello che il retrieval di documenti normale può offrire. Ma l’implementazione deve restare con i piedi per terra. Prima di chiamarlo un cervello di tutta l’azienda, assicurati che il sistema sappia distinguere fatti vecchi e nuovi, tornare alle fonti, filtrare per permessi, accettare correzioni umane e dire «Non sono sicuro» quando le prove sono scarse.

Un piccolo team può partire da un workflow stretto: tre tipi di fonti a basso rischio, qualche decina di fatti e 20 task reali. Fai prima questo, poi decidi se estendere. È meno spettacolare, ma per agenti che devono consegnare lavoro reale, è molto più vicino all’usabile.