Dove metto la conoscenza della mia azienda? RAG, Memory, Skills o MCP

Quattro modi di dare conoscenza a un agente AI, e quattro domande diverse a cui rispondono. Con la premessa che conta più della tabella: caricare tutto nel contesto peggiora le risposte invece di migliorarle.

BlueSky Agent AI · 2026-09-07

È la prima domanda di quasi ogni primo incontro: "abbiamo i manuali, il gestionale, dieci anni di ticket. Dove li mettiamo?". La risposta breve è che non esiste un posto solo, e che i quattro modi disponibili rispondono a domande diverse. RAG per i documenti scritti dalle persone, Memory per quello che l'agente ha già risolto, Skills per le procedure ripetibili, MCP per i dati che cambiano adesso.

La tabella qui sotto arriva da un intervento di Martin Keen per IBM Technology, uscito nella prima settimana di settembre 2026, che la costruisce su un esempio unico (un errore 500 su una pagina web). Qui è tradotta in italiano d'azienda, con gli esempi che usiamo noi.

La premessa che conta più della tabella

Prima di scegliere dove mettere la conoscenza, c'è una convinzione da smontare: che più materiale si dà al modello, meglio risponde.

Non funziona così. Riempire la finestra di contesto degrada il comportamento invece di migliorarlo: più testo irrilevante entra, più il modello fatica a trovare e usare il passaggio che serve davvero. Nel gergo tecnico si chiama context rot, e ha una conseguenza pratica che ribalta l'istinto di chi compra: il criterio non è quanta conoscenza dai all'agente, ma quale gli arriva al momento giusto.

E ogni strumento della tabella è un modo diverso di rispondere a quella domanda.

RAG: quello che hanno scritto le persone

RAG (retrieval augmented generation) serve quando la risposta esiste già, scritta da qualcuno, in un documento fermo. Manuali di macchinario, procedure interne, capitolati d'appalto, contratti quadro, circolari, verbali. Roba scritta una volta e consultata molte.

Il meccanismo: i documenti vengono indicizzati, l'agente cerca il passaggio pertinente alla domanda e lo usa per rispondere, citando da dove viene. Quest'ultima parte è quella che fa la differenza in azienda. Un responsabile qualità che riceve una risposta senza fonte deve verificarla a mano, e a quel punto poteva cercarla da solo.

Quando non serve: se il documento cambia ogni ora, RAG rincorre. Se la risposta non è scritta da nessuna parte, RAG non la inventa (o meglio: non dovrebbe, e un impianto fatto bene lo dice invece di riempire il buco).

Memory: quello che l'agente ha già risolto

Memory è esperienza, non documentazione. È il caso trattato tre settimane fa, la particolarità di quel cliente che ordina sempre con un codice sbagliato, la soluzione che ha funzionato quando il problema si era già presentato.

La differenza con RAG è la provenienza: RAG contiene quello che hanno scritto le persone, Memory quello che l'agente ha imparato lavorando. Serve a non ripartire da zero su un problema già visto.

Ma va gestita come un archivio. Cresce con l'uso, e una memoria mai potata accumula anche gli errori: se l'agente ha "imparato" una soluzione sbagliata, la ripropone con la stessa sicurezza di una giusta. Nei progetti che seguiamo la revisione periodica di cosa c'è in memoria è una voce di manutenzione, non un'attività straordinaria.

Skills: le procedure che si ripetono uguali

Le Skills sono sequenze di passi che l'azienda esegue sempre allo stesso modo. Evasione di un ordine, apertura di un ticket con la classificazione giusta, controllo di una fattura contro l'ordine, onboarding di un fornitore nuovo con i documenti da chiedere.

Tecnicamente sono istruzioni che l'agente carica solo quando servono, invece di tenersele addosso sempre (il termine è progressive disclosure). Il risultato pratico è che l'agente diventa prevedibile: sulla stessa richiesta fa gli stessi passi, e quando sbaglia si può guardare quale passo ha saltato.

È la parte che le PMI sottovalutano di più, e secondo noi è quella che rende un agente utilizzabile da chi non ha voglia di imparare a parlarci.

MCP: il gestionale in tempo reale

MCP (Model Context Protocol) è il modo standard per far parlare l'agente con i sistemi che avete già: gestionale, CRM, magazzino, posta, log dei server. Serve per i dati che cambiano mentre l'agente lavora.

Giacenza di adesso, stato di quell'ordine, ultima fattura emessa, quanti pezzi sono usciti stamattina. Nessun documento indicizzato può tenere il passo di un dato vivo, e una risposta corretta al mese scorso è una risposta sbagliata oggi.

MCP è anche il punto in cui si decide cosa l'agente può fare oltre che leggere. Un collegamento in sola lettura al gestionale è un conto, un collegamento che può scrivere movimenti è un altro: i permessi si concedono per singolo strumento, ed è una scelta da fare con chi conosce i processi, non con chi installa.

Come si sceglie, in pratica

Una domanda per volta, sul caso concreto che avete davanti:

• La risposta è già scritta da qualcuno in un documento? RAG.
• L'agente ha già affrontato questa cosa e ha imparato qualcosa? Memory.
• È una procedura che si esegue sempre uguale? Skills.
• Il dato cambia adesso e sta in un sistema? MCP.

Quasi ogni agente aziendale che funziona ne usa più di uno. Un agente di customer service, per dire: manuale prodotto in RAG, casi già risolti in Memory, procedura di reso in Skills, stato spedizione via MCP. Il progetto che va male, quasi sempre, è quello che ne usa uno solo per tutto. Di solito RAG, perché è quello di cui si parla di più.

Cosa cambia con ModelMatch

Questa architettura decide dove sta la conoscenza. Resta aperta una seconda domanda, che in bolletta pesa parecchio: quale modello esegue ciascun passo.

Recuperare un passaggio da un manuale, estrarre tre campi da una fattura o instradare un ticket sono compiti che un modello economico svolge bene quanto uno di frontiera. Scrivere la risposta finale a un cliente arrabbiato, o ragionare su un contratto ambiguo, no. ModelMatch instrada ogni fase al modello adatto: sui progetti dove lo misuriamo il costo medio scende del 42%, a parità di risultato.

Detto onestamente: la scelta del modello conta meno di come è organizzata la conoscenza. Un impianto con la conoscenza al posto sbagliato non lo salva nessun modello, per quanto costoso.

In sintesi

• Caricare tutto nel contesto peggiora le risposte. La domanda giusta è quale conoscenza arriva al momento giusto.
• RAG per i documenti scritti dalle persone, con citazione della fonte.
• Memory per l'esperienza accumulata dall'agente. Va potata, altrimenti impara anche gli errori.
• Skills per le procedure ripetibili: sono quello che rende l'agente prevedibile e verificabile.
• MCP per i dati vivi nei sistemi aziendali, con permessi decisi per singolo strumento da chi conosce i processi.
• Un agente reale ne usa quasi sempre più di uno. Il progetto fragile è quello che ne usa uno solo per tutto.

Se state valutando un fornitore, questa è una buona domanda da fargli: per il nostro caso, cosa mettete in ciascuno dei quattro, e perché. Chi risponde "mettiamo tutto nel contesto del modello" vi sta dicendo qualcosa di utile su come lavora.