Todos los artículos

Cómo dar a sus asistentes de IA una sola memoria compartida

Cada asistente tiene ya su propia memoria, y ninguno la comparte. El servidor MCP remoto es la pieza que resuelve eso.

Publicado el 22 de septiembre de 2026 · 6 min de lectura

Usted explica su stack, sus clientes, sus restricciones a un asistente. Dos semanas después cambia a otro modelo porque es mejor en lo que ahora necesita, y empieza de cero. La memoria que construyó no es suya: vive dentro de un producto.

Ese es el problema real. No es que los asistentes olviden: la mayoría recuerda bastante bien ahora. Es que cada uno recuerda por separado, en un almacén que usted no puede leer, mover ni apuntar a otro sitio.

Memoria integrada frente a una memoria que es suya

Las memorias nativas son cómodas y no cuestan nada. También tienen tres propiedades que conviene mirar de frente: el proveedor decide qué se recuerda, los datos se quedan dentro de ese proveedor, y nada le acompaña cuando se marcha. Para un uso ocasional es un buen trato. Para un trabajo que construye durante años, es un encierro que eligió sin darse cuenta.

La alternativa es mantener la memoria fuera de todos los asistentes y dejar que cada uno lea de ella. Eso exige un protocolo que ambas partes acepten, y ahí es donde entra MCP.

Qué es realmente MCP

El Model Context Protocol es un estándar abierto para conectar un asistente con herramientas y datos externos. Anthropic lo publicó, y desde entonces se ha adoptado mucho más allá de Claude. Desde el punto de vista del modelo, un servidor MCP no es más que un conjunto de herramientas invocables: guarda esto, busca aquello.

Un servidor de memoria expone algo así como cuatro herramientas —escribir un recuerdo, buscar entre los recuerdos, listar un proyecto, hacer aflorar lo que es relevante ahora mismo— y el asistente las llama por su cuenta cuando la conversación lo necesita. Usted ya no pega contexto: el modelo va a buscarlo.

Los servidores MCP existen en dos formas, y esa diferencia importa más que cualquier comparativa de funciones:

  • Local (stdio). El servidor corre como un proceso en su máquina. Rápido, privado, gratuito, e invisible para todo lo que no sea una aplicación de escritorio en esa máquina. Ni su teléfono, ni una pestaña del navegador.
  • Remoto (HTTP + OAuth). El servidor vive en una URL. Cualquier cliente compatible con conectores remotos puede iniciar sesión y usarlo, desde cualquier dispositivo.

Si quiere una memoria compartida entre asistentes y dispositivos, la que necesita es la segunda. Si quiere una memoria en un solo portátil que nunca salga de ahí, la primera es sinceramente la mejor respuesta, y además es gratis.

Cómo se conecta una memoria remota

No hay nada que instalar. Un servidor MCP remoto es una URL más un inicio de sesión OAuth, el mismo gesto que conectar un calendario a una aplicación:

  1. Pegue la URL del servidor en los ajustes de conectores de su cliente.
  2. El cliente recupera los metadatos OAuth del servidor y se registra solo.
  3. Usted autoriza el acceso en una ventana del navegador, una vez.
  4. Las herramientas aparecen. El asistente empieza a llamarlas cuando corresponde.

Repita el primer paso en un segundo cliente y los dos leerán y escribirán ya la misma memoria. Todo el truco está ahí: la memoria es un servicio, no un archivo. Nuestra versión paso a paso, con capturas por cliente, está en la guía de conexión.

Almacenar es fácil. El producto es recuperar.

Cualquier cosa sabe añadir texto a una base de datos. Lo difícil es responder, meses después y en mitad de una conversación sin relación, cuáles cinco de sus cuatro mil notas importan ahora. Falle en eso y habrá construido un archivo que nadie lee.

Dos formas de fallar, ambas habituales:

  • La búsqueda solo por palabras clave se pierde todo lo formulado de otra manera a como usted lo guardó.
  • La búsqueda solo vectorial devuelve cosas vagamente relacionadas con el tema y se deja los nombres exactos, los códigos de error y los identificadores, precisamente los detalles que necesitaba.

Las implementaciones serias ejecutan las dos y fusionan las clasificaciones —la fusión de rangos recíprocos es el método habitual— y después vuelven a puntuar la lista corta con un modelo de reranking que sí lee la consulta y el candidato juntos. Cuesta más por consulta y es la diferencia entre una memoria y un montón.

Si trabaja en más de un idioma, compruebe esto en concreto. Una cadena ajustada sobre embeddings en inglés se degrada en silencio en francés o en alemán, y el fallo es invisible: simplemente obtiene peores resultados y supone que anotó mal.

Cinco preguntas antes de comprometerse

  1. ¿Local o remoto? Decida esto primero: en un sentido o en el otro, elimina la mayor parte del mercado.
  2. ¿Dónde están los datos, y bajo qué jurisdicción? Si la respuesta no está en la web, dé por hecho que no le va a gustar.
  3. ¿Puede sacarlos? Exportación en un formato usable, a demanda, sin escribir al soporte.
  4. ¿Recuperación híbrida y reranking, o búsqueda vectorial a secas? Pregunte: rara vez se anuncia.
  5. ¿Qué ocurre al llegar al límite del plan gratuito? Borrado, congelado o en solo lectura: tres desenlaces muy distintos.

Dónde se sitúa Pryzm

Pryzm Memory es de la segunda forma: un único punto de acceso alojado, inicio de sesión OAuth, compartido por todos los clientes que conecte. Corre en servidores en Alemania, bajo jurisdicción europea, cifrado en reposo, con un esquema y un rol de base de datos por cliente impuestos por el propio PostgreSQL. La recuperación es híbrida, con un reranker multilingüe, en ocho idiomas.

Tampoco es de código abierto y hoy no se puede autoalojar, lo que resulta descalificante para algunas personas, y preferimos decirlo aquí antes de que lo descubra después de registrarse. Mantenemos una comparativa honesta con las alternativas, incluidas las que nos ganan justo en esos dos puntos.