← Torna a tutti gli articoli
Sfide

Il vero collo di bottiglia dei tuoi agenti non è il modello: è la memoria che non gli hai mai costruito

Di Marc Molas·6 giugno 2026·9 min di lettura

McKinsey ti ha appena promesso una consegna del software 24 ore su 24.

In "Rewiring software delivery for the agentic era" descrivono un mondo in cui lo sprint di due settimane si comprime in uno giornaliero, gli agenti eseguono di notte mentre dormi, e i team di otto-dodici persone lasciano il posto a piccoli pod che supervisionano. Una bella promessa, e la diagnosi di fondo è giusta quasi sempre. Ma, come quasi tutte le belle promesse delle società di consulenza, salta la parte noiosa: il motivo per cui i tuoi agenti non fanno ancora il turno di notte non è il modello che usano. È che non gli hai mai costruito una memoria.

Non scrivo questo dal sedile del consulente che disegna l'operating model, ma da quello di chi opera la piattaforma su cui atterrano questi agenti. Ho fatto abbastanza DevOps e abbastanza reperibilità alle tre di notte da sapere una cosa: un agente autonomo di notte è esattamente la stessa cosa di un ingegnere di guardia appena arrivato. Brillante, instancabile e del tutto inutile se nessuno ha messo per iscritto come funziona davvero il sistema. Il modello gli dà un cervello. Quello che gli manca non è il cervello.

Il modello non è il collo di bottiglia; il contesto che manca, sì

Pensa a cosa serve davvero a un agente per rilasciare una modifica sui tuoi sistemi senza rompere niente. Non gli serve essere più intelligente. Gli serve sapere cosa significa «cliente a rischio» nel tuo settore. Gli serve sapere quale dei sei passi di quel processo di rimborso non va mai saltato. Gli serve sapere perché quel servizio è stato costruito in un modo così strano — e che è stato per un incidente del trimestre scorso, finito con la decisione di non fare mai retry automatici contro quell'endpoint.

Niente di tutto questo vive nei pesi del modello. Vive nella testa di tre persone, in un thread di Slack che nessuno ritroverà, in un Confluence fermo da un anno, in un ticket Jira chiuso e in un post-mortem che nessuno ha riletto. Il modello più potente del pianeta, senza quel contesto, è una nuova assunzione al primo giorno, senza onboarding. Dagli pure il miglior cervello sul mercato: se non sa come funziona la tua azienda, tirerà a indovinare. E un agente che indovina in produzione non è produttività: è debito.

Le quattro condizioni di McKinsey sono, in realtà, una sola

L'articolo elenca quattro condizioni perché gli agenti funzionino: una visione di business chiara di cosa costruire, un ambiente tecnico standard con framework comuni e architettura modulare, una struttura standard dal requisito al codice perché gli input siano prevedibili, e gli stakeholder che restano coinvolti su tutta la catena del valore.

Quattro caselle. Ma guardale da vicino: puntano tutte allo stesso posto. Non sono quattro requisiti indipendenti; sono quattro facce di un unico substrato. Tutte e quattro servono a rendere il contesto della tua organizzazione leggibile e affidabile, al punto che una macchina possa ragionarci sopra. La visione chiara è contesto sul cosa. L'ambiente standard è contesto sul come. La struttura dal requisito al codice è contesto in un formato che l'agente può consumare senza interpretarlo. E gli stakeholder coinvolti sono la garanzia che quel contesto non si disallinei dalla realtà a metà settimana. McKinsey la vende come una lista di controllo; in trincea è una cosa sola, e ha un nome.

Il knowledge graph è lo strato di memoria dell'IA

È qui che l'articolo dice la cosa davvero interessante, ed è quella da portare a casa. Le aziende in testa stanno costruendo knowledge graph che fanno da strato di memoria dell'IA lungo tutto il ciclo di vita del software, uno per dominio: collegano i feedback dei clienti, le decisioni di architettura registrate, i documenti di design, i ticket, l'attività su GitHub, i report sugli incidenti e le regole di compliance.

La parola chiave è collegare. Un sistema RAG su un wiki — di cui ho già parlato per chi integra LLM — ti recupera il paragrafo le cui parole combaciano con la domanda. Utile, ma piatto. Uno strato di memoria vero sa un'altra cosa: sa che questo incidente ha innescato quella decisione di architettura, che vincola questo servizio, il cui responsabile ha scritto quella regola di compliance. Il valore non è nei nodi, è negli archi. La differenza tra le due cose è la differenza tra un agente che ti cita il wiki e uno che rispetta le tue cicatrici.

Ed è esattamente lo strato che sostenevo essere il fossato: il modello rende commodity l'80% facile, e la differenziazione si sposta sul sistema che lo circonda. La memoria di come funziona davvero la tua azienda è la parte di quel sistema che nessun fornitore di modelli può venderti, perché non ce l'ha.

Abbiamo già codificato sapere tribale, e l'abbiamo chiamato infrastructure as code

Se questo ti suona familiare, è perché noi che veniamo dalle operations questo gesto l'abbiamo già fatto diverse volte. Ogni salto verso l'autonomia, senza eccezioni, è stato lo stesso: prendere un sapere che viveva nella testa di un ingegnere senior e codificarlo perché una macchina potesse agirci sopra.

I runbook a mano sono diventati remediation automatica. I passi di deploy che sapeva solo uno sono diventati una pipeline di CI/CD. Il «chiedi a Maria, è lei che sa com'è cablata la produzione» è diventato infrastructure as code. Ed ecco il dettaglio che tutti dimenticano: la pipeline non ha iniziato a girare da sola perché gli strumenti sono diventati intelligenti. Ha iniziato a girare da sola quando abbiamo scritto quello che sapeva Maria. Gli agenti che rilasciano software di notte sono esattamente quella lezione, un piano più su. L'agente esegue senza supervisione fino esattamente al punto che il suo contesto consente, e non un passo oltre. Il substrato non è una magia nuova; è sapere tribale, finalmente scritto in una forma che una macchina può percorrere.

La consegna 24 ore è il premio, non l'obiettivo

Ecco perché la cadenza giornaliera che vende McKinsey è reale, ma viene dopo il substrato, non prima. L'esecuzione notturna funziona fin dove la memoria dell'agente lo lascia andare da solo; oltre quella linea, si ferma e aspetta un umano. Quindi la metrica che conta non è «gli agenti possono girare di notte», ma fin dove arriva l'agente prima di sbattere contro una domanda a cui solo una persona può rispondere — e ognuna di quelle fermate è un bug di contesto nel tuo strato di memoria, non un guasto del modello.

Qui devi lasciarmi concedere il controargomento forte, perché è buono: «i modelli migliorano ogni trimestre, le finestre di contesto crescono — il prossimo modello non si mangerà tutto questo?». In parte, sì. Una parte dell'impalcatura di oggi verrà assorbita: modelli migliori hanno meno bisogno che li prendi per mano, e finestre più grandi ingoiano più documenti in un colpo solo. Ma una finestra di contesto non è una memoria. Incollare tutto il wiki nel prompt non fa sì che il modello sappia quale passo non saltare mai; lo fa leggere un mucchio di testo magari contraddittorio, e tirare a indovinare. Sapere richiede curatela, verifica, freschezza e risoluzione dei conflitti: decidere quale di due fonti che si contraddicono è la verità valida oggi. Questo è giudizio, lo fa un umano, ed è lavoro di ingegneria permanente. Il modello è a noleggio, e identico per il concorrente di fronte. La memoria curata di come funziona davvero la tua azienda è la parte che nessuno può noleggiare.

Cosa farei questo trimestre se fossi il tuo CTO

Cinque scommesse concrete, perché una diagnosi senza azione è solo una bella opinione:

  1. Trova dove vive davvero il tuo contesto. Prima di comprare qualsiasi «fabbrica di agenti», fai l'inventario scomodo: quanta parte del sapere che servirebbe a un agente per rilasciare codice vive solo nelle teste, nei thread di Slack e in un wiki scaduto? Quella risposta è il tuo collo di bottiglia. Non il modello.
  2. Costruisci la memoria di UN dominio, non di tutta l'azienda. Il knowledge graph di tutto il ciclo di vita in un colpo solo è un progetto che muore in comitato. Scegli un dominio con un dolore vero, collegane le decisioni registrate, i ticket, gli incidenti e le regole di compliance, e fai ragionare un agente lì sopra. Impara lì prima di scalare.
  3. Standardizza il percorso dal requisito al codice. È la condizione di McKinsey che sposta davvero l'ago. Se ogni funzionalità entra in un formato diverso, l'agente indovina; se entra in una struttura prevedibile, esegue. Input riproducibili prima di output autonomi.
  4. Incorpora la compliance nella memoria, non alla fine. Le regole di rischio, legali e di sicurezza devono essere nodi che l'agente legge mentre costruisce, non una porta che qualcuno apre quando è già tutto fatto. Un controllo che vive nel grafo migliora la tracciabilità e la completezza; un controllo che vive in un PDF è un collo di bottiglia con un volto umano.
  5. Misura l'autonomia da quanto lontano arriva l'agente da solo. Dimentica la «percentuale di codice scritto dall'IA». La metrica onesta è quanti passi un agente concatena prima di aver bisogno di un umano — e trattare ogni fermata come un bug di contesto da sistemare nel substrato, non come un tetto del modello.

La linea che difendo è sempre la stessa, e qui l'IA la illustra nel modo più letterale che abbia mai visto: non sostituisce l'ingegnere, lo potenzia. Qualcuno deve decidere quale di due fonti contraddittorie è la verità, quale passo non si salta mai, quando un sapere è scaduto. Quel lavoro — costruire e mantenere la memoria di come funziona davvero la tua azienda — non lo fa il modello. Lo fa un ingegnere con giudizio. E più vuoi i tuoi agenti autonomi, più te ne servono, non meno.

McKinsey vende la destinazione: agenti che rilasciano software mentre dormi. Ha ragione sul fatto che è possibile. Quello che la slide ti risparmia è che il motore economico e intercambiabile non è mai stato il problema. Il problema, come sempre, è tutta la macchina intorno — e questa volta il pezzo più difficile da costruire si chiama memoria.


Stai cercando di portare i tuoi agenti dalla demo alla produzione, e quello che si disallinea è il contesto, non il modello? Parla con un CTO per mettere in piedi lo squad nearshore che ti costruisce lo strato di memoria, non solo quello che collega l'agente.

Pronto a costruire il tuo team di ingegneria?

Parla con un partner tecnico e distribuisci sviluppatori validati da CTO in 72 ore.