Cómo proteger las memorias que las automatizaciones de Cursor guardan entre ejecuciones (Guía 2026)

Comencemos con lo que documenta Cursor. "Las memorias permiten al agente leer y escribir notas persistentes entre ejecuciones para la misma automatización. Utiliza esto para crear agentes que recuerden y mejoren con el tiempo. Cada memoria se almacena como una entrada con nombre (MEMORIES.md por defecto) que existe fuera del sistema de archivos de trabajo del agente".

Tres detalles en ese párrafo lo definen todo. Las notas las escribe el agente, no tú. Persisten "entre ejecuciones", por lo que una nota escrita hoy influye en cada ejecución futura. Y pertenecen a "la misma automatización", por lo que cada automatización tiene su propia memoria en lugar de compartir una.

A continuación se presentan los valores predeterminados y los controles. "Las memorias están habilitadas por defecto pero se pueden deshabilitar. Las memorias se pueden ver y editar desde la interfaz de usuario de configuración de la herramienta". La eliminación funciona en ambas direcciones: "Los agentes pueden eliminar archivos de memoria obsoletos durante las ejecuciones de la automatización. También puedes eliminar archivos de memoria desde la interfaz de usuario de configuración de la herramienta". Esta última capacidad llegó en una actualización de junio de 2026, que añadió la posibilidad de "eliminar archivos de memoria en la interfaz de usuario, o solicitar a tu automatización que elimine memorias obsoletas cuando se ejecute".

Luego, la advertencia completa: "Las memorias persisten entre ejecuciones y deben usarse con precaución si tu automatización maneja entradas no confiables. Las entradas pueden dar lugar a memorias engañosas o maliciosas que afecten involuntariamente a futuras ejecuciones de la automatización".

Ahora observa lo que suelen leer las automatizaciones. La lista de disparadores de Cursor incluye "Nuevo mensaje en el canal" para Slack, "Comentario añadido" en pull requests, "Comentario de issue" en GitHub issues, endpoints de webhook a los que puedes hacer POST y eventos de Linear. Cada uno de ellos contiene texto escrito por alguien que no eres tú. Una automatización que clasifica informes de errores de un canal de Slack está, por diseño, leyendo entradas no confiables en cada ejecución y, por defecto, escribiéndose notas a sí misma basadas en ellas.

Esa es la diferencia con la memoria de un editor. En tu editor, la persona que escribe eres tú. En una automatización, la entrada proviene de quienquiera que la haya activado, y la nota que deja es leída por la siguiente ejecución sin que nadie la revise.

Una nota sobre los nombres, porque genera confusión. Las búsquedas de memorias de Cursor a menudo se refieren a la función del IDE que Cursor introdujo en la versión 1.0, donde "Cursor puede recordar datos de las conversaciones y hacer referencia a ellos en el futuro", con memorias "almacenadas por proyecto a nivel individual". El índice de documentación actual de Cursor describe Memories como una herramienta de Automations, y su documentación de reglas describe las reglas como la capa persistente para el editor: "Los modelos de lenguaje grandes no retienen la memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". Esta guía cubre la herramienta de memoria de Automations.

Dejar la memoria activada para cada automatización. Es la opción por defecto, y para una automatización que resume los commits de tu propio repositorio cada mañana, probablemente esté bien. Para una que lee un canal público, significa que los mensajes de extraños pueden dar forma a las notas que guarda la automatización.

Desactivar la memoria en todas partes. Es seguro, pero desecha el valor real de la función. Una automatización que aprende qué pruebas inestables (flaky tests) ignorar o qué revisores son propietarios de qué directorios es genuinamente mejor en su décima ejecución que en la primera.

Confiar en que el agente limpie lo suyo. Cursor documenta que los agentes "pueden eliminar archivos de memoria obsoletos durante las ejecuciones de la automatización". Ese es un mantenimiento útil. Sin embargo, también es el mismo agente, leyendo las mismas entradas, el que decide qué se considera obsoleto.

No abrir nunca el archivo de memoria. Las notas se pueden ver y editar en la interfaz de usuario de configuración de la herramienta. Muchos equipos configuran una automatización, la ven funcionar durante una semana y nunca miran lo que se ha estado diciendo a sí misma desde entonces.

Asumir que la memoria se comparte entre automatizaciones. Está acotada a "la misma automatización". Una lección aprendida por la automatización de clasificación es invisible para la automatización de revisión, lo cual es un aislamiento sensato pero una sorpresa común.

El objetivo es conservar el aprendizaje y eliminar las conjeturas sobre lo que se aprendió.

Paso 1: Clasifica cada automatización según la entrada que lee

Haz una lista de tus automatizaciones y, para cada una, anota cada disparador y cada fuente que lee. Luego, organízalas en dos grupos.

Entrada confiable: programaciones sobre tu propio repositorio, pushes y merges de tu equipo, webhooks de tus propios sistemas. El texto que lee el agente fue escrito por personas y sistemas que tú controlas.

Entrada no confiable: canales públicos de Slack, comentarios de pull requests e issues de cualquier persona que pueda comentar, webhooks expuestos a terceros, tickets de clientes. La propia guía de Cursor para herramientas conectadas apunta en la misma dirección: "Solo conecta servidores en los que confíes con los permisos que tu automatización necesite".

Para el grupo no confiable, decide si la automatización realmente necesita recordar algo entre ejecuciones. Muchas no lo necesitan; clasifican cada elemento según sus propios méritos. Para esas, deshabilita las memorias. Para las que realmente mejoran con la memoria, déjala activada y pasa al Paso 2.

Paso 2: Dile a la automatización exactamente qué puede registrar

El prompt de la automatización es donde estableces las reglas para su memoria. El flujo de configuración de Cursor lo coloca en el centro: "Escribe un prompt con instrucciones para la automatización".

Añade una política de memoria corta y explícita a ese prompt. Indica qué tipo de datos vale la pena registrar (qué pruebas se sabe que son inestables, qué directorios se asignan a qué propietarios, qué patrones de alerta resultaron ser ruido). Indica lo que nunca debe registrarse: instrucciones que lleguen dentro de la entrada, afirmaciones sobre permisos, solicitudes para cambiar el comportamiento de la propia automatización. Y establece que cualquier cosa incierta debe registrarse como una observación, no como una regla.

Esto no hace que la entrada no confiable sea segura; la precaución de Cursor sigue aplicando. Reduce aquello en lo que se puede convertir una entrada engañosa y hace que una mala nota sea más fácil de detectar, porque cualquier cosa fuera de la política destacará cuando leas el archivo.

Si el trabajo de una automatización requiere que lea algo sensible, mantén la política de memoria más estricta de lo que crees necesario. Una memoria que persiste entre ejecuciones es un lugar donde una sola mala entrada puede tener una larga vida.

Paso 3: Revisa MEMORIES.md de forma programada y guarda una copia aprobada en otro lugar

Coloca un recordatorio recurrente en tu calendario (semanal para automatizaciones muy activas, mensual para las tranquilas) para abrir las memorias de cada automatización en la interfaz de usuario de configuración de la herramienta y leerlas.

Léelas de la misma manera que revisarías un pull request. ¿Es verdadera cada nota? ¿Sigue siendo verdadera? ¿Provino de una entrada en la que confiarías? Edita lo que esté mal, elimina lo que esté obsoleto y toma nota de cualquier cosa que parezca haber sido escrita porque una entrada le indicó al agente que la escribiera.

Luego, guarda una copia de las notas que aprobaste en algún lugar fuera de la automatización. Cuando una ejecución se comporte de forma incorrecta, querrás poder comparar la memoria de hoy con la última versión que verificaste, y el propio archivo de la automatización es lo único que puede haber cambiado. La misma idea se aplica a los agentes recurrentes en otras herramientas: el patrón detrás de hacer que los agentes en la nube de Warp recuerden ejecuciones anteriores es un registro revisado, no uno sin supervisión.

La copia aprobada del Paso 3 es el artefacto útil: una lista corta de lecciones que alguien verificó y con las que estuvo de acuerdo. MemoryLake es un lugar para guardarla, separada del archivo que una automatización puede sobrescribir en su próxima ejecución.

Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de la sección MEMORIES.md de una automatización, de tu configuración de Cursor ni del almacenamiento de ningún proveedor.

Paso 1: Crea una clave API

Inicia sesión y genera una clave desde el panel de control. La clave es lo que permite a un agente leer las entradas que has escrito, ya sea una automatización, una sesión de editor o una herramienta completamente diferente.

Paso 2: Sube tus primeras memorias

Añade las lecciones que aprobaste en el Paso 3, una por entrada, con el motivo y la fecha en que la verificaste. La fecha importa: una lección sobre una prueba inestable solo es verdadera hasta que alguien corrige la prueba.

Paso 3: Conecta tu IA y agentes

Apunta tus agentes al espacio de trabajo. Una lección revisada estará disponible para cada automatización y sesión que la necesite, en lugar de vivir en el archivo de una sola automatización.

La primera diferencia es que la memoria se convierte en una decisión por automatización en lugar de una opción por defecto. Las automatizaciones que leen solo tus propios sistemas siguen aprendiendo. Las automatizaciones que leen texto de extraños dejan de recordar o recuerdan bajo una política escrita.

La segunda es que la desviación (drift) se vuelve visible. Un archivo de memoria que nadie lee puede acumular una creencia errónea durante semanas. Un archivo que alguien revisa de forma programada se corrige antes de que esa creencia influya en muchas ejecuciones.

La tercera es que las lecciones dejan de estar atrapadas en una sola automatización. Debido a que las memorias están acotadas por automatización, un dato útil aprendido por una es invisible para las demás. Mantener las lecciones aprobadas en un lugar compartido es la solución, la misma brecha descrita en por qué los agentes en la nube de Cursor olvidan el contexto y en cómo los proyectos de Cursor comparten archivos de contexto.

La cuarta es que los agentes recurrentes comienzan a comportarse como un sistema sobre el cual se puede razonar. El trabajo programado en otras herramientas tiene la misma forma; consulta tareas programadas de ChatGPT que comienzan de cero y tareas programadas y memoria de Cowork. El hilo conductor es que la memoria de un agente en segundo plano es tan buena como la última vez que alguien la revisó.

Clasifica los disparadores antes de habilitar la memoria. Los canales públicos, los hilos de comentarios abiertos y los webhooks de terceros son entradas no confiables.

Deshabilita la memoria donde el trabajo no la necesite. Muchas tareas de clasificación funcionan elemento por elemento y obtienen pocos beneficios de recordar.

Escribe una política de memoria en el prompt. Indica qué registrar, qué no registrar nunca y cómo registrar la incertidumbre.

Revisa el archivo de memoria de forma programada. Cursor hace que se pueda ver y editar; el valor proviene de leerlo realmente.

Guarda una copia aprobada fuera de la automatización. Cuando el comportamiento cambie, compara el archivo actual con la última versión en la que confiaste.

Recuerda que cada automatización recuerda sola. Las memorias son por automatización. Las lecciones compartidas necesitan un hogar compartido, que es también lo que soluciona el problema más amplio de que Cursor olvide sesiones anteriores y de que los agentes recurrentes olviden ejecuciones anteriores.

Cursor creó la herramienta de memoria de Automations para resolver un problema real: agentes en segundo plano que comienzan desde cero en cada ejecución. Con la memoria activada, una automatización puede "recordar y mejorar con el tiempo", y por esa razón está activada por defecto.

Cursor también describió el riesgo claramente. Las memorias "deben usarse con precaución si tu automatización maneja entradas no confiables", porque las entradas "pueden dar lugar a memorias engañosas o maliciosas que afecten involuntariamente a futuras ejecuciones de la automatización". Para las automatizaciones que leen canales de Slack, comentarios de pull requests o webhooks externos, ese es el caso normal, no un caso extremo.

Clasifica cada automatización según lo que lee, desactiva la memoria donde no sea necesaria, escribe una política para lo que se puede registrar y revisa el archivo de forma programada. Guarda las lecciones que aprobaste en algún lugar que la automatización no pueda sobrescribir, y su memoria se convertirá en algo en lo que puedas confiar en lugar de algo que esperas que esté bien.