Tutti gli articoli

Come dare ai suoi assistenti IA una sola memoria condivisa

Ogni assistente ha ormai la propria memoria, e nessuno la condivide. Il server MCP remoto è il pezzo che risolve la cosa.

Pubblicato il 22 settembre 2026 · 6 min di lettura

Lei spiega il suo stack, i suoi clienti, i suoi vincoli a un assistente. Due settimane dopo passa a un altro modello perché è migliore proprio su ciò che le serve adesso — e riparte da zero. La memoria che ha costruito non le appartiene: vive dentro un prodotto.

È questo il vero problema. Non è che gli assistenti dimentichino: la maggior parte ormai ricorda piuttosto bene. È che ciascuno ricorda separatamente, in un archivio che lei non può leggere, spostare né puntare altrove.

Memoria integrata contro una memoria che le appartiene

Le memorie native sono comode e non costano nulla. Hanno anche tre proprietà su cui conviene essere lucidi: è il fornitore a decidere che cosa viene ricordato, i dati restano dentro quel fornitore, e nulla la segue quando se ne va. Per un uso occasionale è uno scambio accettabile. Per un lavoro che costruisce su più anni, è un vincolo che ha scelto senza accorgersene.

L'alternativa è tenere la memoria fuori da ogni assistente e lasciare che ciascuno la legga. Serve per questo un protocollo su cui entrambe le parti si accordino, ed è qui che entra in gioco MCP.

Che cos'è realmente MCP

Il Model Context Protocol è uno standard aperto per collegare un assistente a strumenti e dati esterni. Lo ha pubblicato Anthropic, ed è stato adottato ben oltre Claude. Dal punto di vista del modello, un server MCP non è che un insieme di strumenti richiamabili: salva questo, cerca quello.

Un server di memoria espone una manciata di strumenti — scrivere un ricordo, cercare tra i ricordi, elencare un progetto, far emergere ciò che è pertinente adesso — e l'assistente li chiama da solo quando la conversazione lo richiede. Lei non incolla più il contesto: è il modello che va a prenderlo.

I server MCP esistono in due forme, e la differenza conta più di qualsiasi confronto di funzionalità:

  • Locale (stdio). Il server gira come processo sulla sua macchina. Veloce, privato, gratuito — e invisibile a tutto ciò che non sia un'applicazione desktop su quella macchina. Non il suo telefono, non una scheda del browser.
  • Remoto (HTTP + OAuth). Il server vive a un URL. Qualsiasi client che supporti i connettori remoti può autenticarsi e usarlo, da qualsiasi dispositivo.

Se vuole una sola memoria condivisa tra assistenti e dispositivi, le serve la seconda forma. Se vuole una memoria su un solo portatile da cui non esca mai, la prima è davvero la risposta migliore — ed è gratuita.

Come si collega una memoria remota

Non c'è nulla da installare. Un server MCP remoto è un URL più un accesso OAuth, lo stesso gesto di collegare un calendario a un'applicazione:

  1. Incolli l'URL del server nelle impostazioni dei connettori del suo client.
  2. Il client recupera i metadati OAuth del server e si registra da solo.
  3. Lei autorizza l'accesso in una finestra del browser, una volta.
  4. Gli strumenti compaiono. L'assistente inizia a chiamarli quando è pertinente.

Ripeta il primo passo in un secondo client ed entrambi leggono e scrivono la stessa memoria. Tutto il trucco è qui: la memoria è un servizio, non un file. La nostra versione passo per passo, con schermate per ogni client, è nella guida di connessione.

Archiviare è facile. Il prodotto è ritrovare.

Qualunque cosa sa aggiungere testo a un database. La parte difficile è rispondere, mesi dopo e nel mezzo di una conversazione che non c'entra, quali cinque dei suoi quattromila appunti contano adesso. Sbagli quello e avrà costruito un archivio che nessuno legge.

Due modi di fallire, entrambi frequenti:

  • La sola ricerca per parole chiave manca tutto ciò che è formulato diversamente da come è stato salvato.
  • La sola ricerca vettoriale restituisce cose vagamente in tema e manca i nomi esatti, i codici di errore e gli identificatori — esattamente i dettagli che le servivano.

Le implementazioni serie eseguono entrambe e fondono le classifiche — la reciprocal rank fusion è il metodo abituale — poi rivalutano la lista breve con un modello di reranking che legge davvero domanda e candidato insieme. Costa di più per ogni richiesta ed è la differenza tra una memoria e un mucchio.

Se lavora in più di una lingua, verifichi proprio questo punto. Una catena tarata su embedding inglesi si degrada silenziosamente in francese o in tedesco, e il guasto è invisibile: ottiene solo risultati peggiori e pensa di aver scritto male l'appunto.

Cinque domande prima di impegnarsi

  1. Locale o remoto? Decida prima questo: in un senso o nell'altro elimina gran parte del mercato.
  2. Dove stanno i dati, e sotto quale giurisdizione? Se la risposta non è sul sito, dia per scontato che non le piacerà.
  3. Può tirarli fuori? Un export in un formato utilizzabile, su richiesta, senza scrivere all'assistenza.
  4. Recupero ibrido e reranking, o semplice ricerca vettoriale? Lo chieda: viene raramente pubblicizzato.
  5. Che cosa succede al limite del piano gratuito? Cancellati, congelati o in sola lettura: tre esiti molto diversi.

Dove si colloca Pryzm

Pryzm Memory è della seconda forma: un unico endpoint ospitato, accesso OAuth, condiviso da ogni client che collega. Gira su server in Germania sotto giurisdizione europea, cifrato a riposo, con uno schema e un ruolo di database per cliente imposti da PostgreSQL stesso. Il recupero è ibrido, con un reranker multilingue, su otto lingue.

Non è nemmeno open source e oggi non può ospitarlo da sé — cosa squalificante per alcuni, e preferiamo dirlo qui piuttosto che lasciarglielo scoprire dopo l'iscrizione. Manteniamo un confronto onesto con le alternative, incluse quelle che ci battono esattamente su questi due punti.