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.
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:
- Incolli l'URL del server nelle impostazioni dei connettori del suo client.
- Il client recupera i metadati OAuth del server e si registra da solo.
- Lei autorizza l'accesso in una finestra del browser, una volta.
- 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
- Locale o remoto? Decida prima questo: in un senso o nell'altro elimina gran parte del mercato.
- Dove stanno i dati, e sotto quale giurisdizione? Se la risposta non è sul sito, dia per scontato che non le piacerà.
- Può tirarli fuori? Un export in un formato utilizzabile, su richiesta, senza scrivere all'assistenza.
- Recupero ibrido e reranking, o semplice ricerca vettoriale? Lo chieda: viene raramente pubblicizzato.
- 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.