Dalla Knowledge Base al Deploy: come ELAN42 ha costruito una suite Agentica per il Team

Come si organizza un’agenzia quando smette di usare l’AI come un tool e inizia a conviverci come un collega? ELAN42 ha risposto costruendo un sistema di memoria condivisa, ruoli chiari tra agenti, e un’infrastruttura cloud che azzera i segreti in chiaro.

Negli ultimi mesi, in ELAN42 abbiamo affrontato un problema che chi lavora con l’AI generativa conosce bene: più agenti usi, più contesto perdi. Ogni sessione ripartiva da zero, ogni agente rifaceva le stesse domande, e la conoscenza aziendale — chi fa cosa, quali clienti abbiamo, come sono strutturati i progetti — viveva sparsa tra chat, file locali e teste delle persone.

La soluzione non è stata “un tool in più”. È stata ripensare come un’agenzia digitale organizza la propria memoria, i propri agenti, e la propria infrastruttura quando l’AI smette di essere un assistente occasionale e diventa un collaboratore stabile.

Ecco i tre pilastri che abbiamo costruito.

1. Una Wiki che parla il linguaggio degli LLM (e si sdoppia da sola)

Il primo problema era la memoria. Un’agenzia accumula conoscenza — team, competenze, clienti, stack tecnologico, bandi vinti — ma quella conoscenza raramente è strutturata per essere letta da un’intelligenza artificiale.

Abbiamo costruito una LLM Wiki: un archivio in Markdown puro, wiki-linkato, dove ogni pagina ha una fonte, una data di aggiornamento, e collegamenti a pagine correlate. È il formato che un modello linguistico legge meglio — niente HTML, niente CMS, solo testo strutturato che l’AI può interrogare senza “context rot” (il decadimento di qualità che si verifica quando un LLM viene inondato di informazioni non pertinenti).

Ma c’è un vincolo che ogni agenzia conosce bene: non tutta la conoscenza aziendale è condivisibile con tutto lo staff. Costi del personale, dati anagrafici sensibili, topologia dei server: sono informazioni che restano riservate a chi le gestisce direttamente.

Per questo la Wiki si sdoppia automaticamente:

• La fonte di verità resta interna, riservata, completa.
• Un estratto pubblico — generato applicando regole di censura scritte una volta sola — viene distribuito a tutto il team via repository condiviso, aggiornato ad ogni sync.

Il risultato: ogni collaboratore, quando apre un nuovo progetto, eredita automaticamente il contesto aziendale — chi siamo, cosa sappiamo fare, quali strumenti usiamo — senza che nessuno debba spiegarglielo a voce, e senza che dati sensibili finiscano dove non dovrebbero.

2. Due agenti, un solo tavolo: come dividere il lavoro tra AI diverse

Il secondo problema era più sottile: quando più agenti AI lavorano sullo stesso progetto, chi fa cosa?

In ELAN42 usiamo due agenti con ruoli distinti:

• Claude (Anthropic) si occupa di giudizio, strategia, scrittura, decisioni di valore.
• Antigravity (Gemini) si occupa di task meccanici, ripetitivi, elaborazioni lunghe.

Il rischio, però, è ovvio: due agenti che scrivono sullo stesso repository, senza coordinamento, generano conflitti — file sovrascritti, contesto perso, lavoro duplicato o, peggio, cancellato per errore.

Abbiamo risolto il problema con tre regole semplici ma non negoziabili:

1. Mai in contemporanea. Un solo agente alla volta lavora sul progetto.
2. Un file di passaggio (handoff) che ogni agente legge all’inizio e aggiorna alla fine: cosa è stato fatto, cosa NON va toccato, quali sono le prossime azioni.
3. Commit isolati e tracciabili — mai un commit generico che assorbe tutto il lavoro in corso: ogni agente aggiunge solo i file che ha effettivamente toccato, con una firma che identifica chi ha fatto cosa.

Il beneficio più concreto? Zero conflitti git in settimane di lavoro parallelo. E soprattutto: quando riprendi una sessione — anche a distanza di giorni — non devi rispiegare nulla. Il contesto è già lì, scritto da chi ti ha preceduto.

3. Segreti in un caveau, non in un file

Il terzo pilastro riguarda la sicurezza. Token, password, chiavi API: sono il tallone d’Achille di qualsiasi automazione. Basta un commit distratto per esporre credenziali in chiaro su un repository — anche privato.

Abbiamo eliminato il problema alla radice, spostando ogni segreto in un vault cloud dedicato (Google Cloud Secret Manager), accessibile solo tramite autenticazione a livello di identità — non più file di chiavi salvati su disco, non più .env versionati per sbaglio.

from scripts.apa_vault import get_secret, hydrate
hydrate()
token = get_secret("NOME_SEGRETO")

Ogni script, ogni agente, ogni progetto legge i propri segreti da un’unica fonte centralizzata, senza mai doverli scrivere in chiaro da nessuna parte. Se per errore un segreto finisse comunque in un commit, il problema viene segnalato immediatamente — non scoperto mesi dopo.

Perché ne vale la pena

Costruire questa infrastruttura ha richiesto disciplina: niente scorciatoie, niente “lo sistemo dopo”. Ma il ritorno si vede già:

• L’onboarding di un nuovo progetto passa da ore a minuti — un agente nuovo eredita subito contesto aziendale, ruoli, e regole operative.
• La conoscenza aziendale compone nel tempo, invece di dissolversi ad ogni sessione persa.
• La sicurezza è strutturale, non affidata alla memoria di chi scrive codice quel giorno.

🚀 Il “digitale umano” in cui crediamo non è rifiutare l’automazione:
significa costruirla in modo che liberi le persone, invece di generare più caos di quanto ne risolva.