Por qué los agentes en la nube de Cursor olvidan tu contexto incluso con Builds (2026)

Las Builds preparan la máquina, no el modelo

Lee lo que realmente contiene una build. La documentación describe el entorno de desarrollo como "similar a la configuración de tu laptop: repositorios clonados, dependencias instaladas, secretos, comandos de inicio y acceso a la red", configurado a través de .cursor/environment.json con configuración guiada por el agente, una instantánea guardada o un Dockerfile. Las Builds preparan ese entorno con anticipación para que los agentes "comiencen con los repositorios y las dependencias listos", y los agentes siempre inician desde la última build exitosa; si una actualización de dependencias rompe el entorno, la build fallida nunca se activa.

Cada elemento de esa lista es infraestructura. Ninguno de ellos es conocimiento. El comando de instalación se ejecuta una vez durante la creación de la build y el comando de inicio se vuelve a ejecutar en cada sesión, lo cual es exactamente el diseño correcto para servicios y contenedores, y completamente ortogonal a si el agente sabe que tu módulo de facturación no puede admitir un cambio disruptivo en este sprint.

Cursor es directo sobre la importancia de los entornos: "Los agentes son tan capaces como los entornos en los que se ejecutan" y "la configuración del entorno es el paso más importante para mejorar la efectividad de los agentes en la nube". Eso es cierto, y las builds lo hacen económico. Simplemente responde a una pregunta diferente de la que la gente se hace después de que su tercera ejecución en la nube repite un error.

El activador es todo el briefing

Las sesiones locales tienen una conversación. Los agentes en la nube a menudo no. Los puntos de entrada documentados incluyen Cursor Desktop, Cursor Web en cursor.com/agents, una aplicación de iOS o PWA de Android, Slack a través de un comando @cursor, un comentario que mencione a @cursor en una pull request o issue de GitHub o Bitbucket, Linear y la API.

Mira lo que la mayoría de ellos tienen en común: el agente es lanzado por alguien que escribe un solo mensaje, con frecuencia mientras no está sentado frente a su editor, a veces por un compañero de equipo que no escribió el código. Ese mensaje es el briefing completo. Todo lo que el agente sabrá más allá del contenido de tu repositorio proviene de esa frase más los archivos que lea por su cuenta; y una frase escrita en un teléfono desde un ticket de Linear es un briefing muy escaso en comparación con una sesión local donde has estado hablando con el agente durante veinte minutos.

Esta es también la razón por la que el fallo se siente diferente al olvido local. Localmente, notas que el agente pierde el hilo y se lo vuelves a explicar. En una ejecución en la nube no hay nadie en la sala para notarlo, por lo que el malentendido termina convirtiéndose en una pull request.

Las reglas son el único canal de conocimiento, y una de sus formas falla silenciosamente

Debido a que el activador es escaso, el repositorio es donde debe residir todo el conocimiento duradero. La documentación de reglas de Cursor lo dice explícitamente: "Los modelos de lenguaje grandes no retienen la memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". Las reglas vienen en cuatro formas documentadas: reglas de proyecto como archivos .mdc en .cursor/rules bajo control de versiones, reglas de usuario globales para tu entorno de Cursor, reglas de equipo gestionadas desde el panel de control en los planes Team y Enterprise, y AGENTS.md en la raíz del proyecto con soporte para archivos anidados, donde los más específicos tienen prioridad.

Aquí está la trampa, citada de la misma documentación: "El sistema de reglas ignora un archivo .md simple en .cursor/rules porque no tiene frontmatter para especificar description, globs y alwaysApply".

Sin advertencias, sin errores, sin entradas en un registro. Un archivo que parece una regla, se encuentra en el directorio de reglas y se lee como si estuviera funcionando. Esto afecta más a los equipos que llegaron de otra herramienta cuyas reglas eran markdown simple, y es invisible precisamente donde menos te lo puedes permitir: en una ejecución en la nube, nadie está observando la sesión para notar que el archivo de convenciones nunca se cargó. Vale la pena asociarlo con los cuatro modos de aplicación, ya que deciden cuándo se carga una regla válida: alwaysApply: true, una description para aplicación inteligente, globs para archivos específicos, o nada en absoluto, lo que requiere una mención explícita con @. Una regla configurada para aplicación manual nunca se cargará por sí sola en la ejecución de un agente en la nube.

Dos limitaciones más son importantes para el trabajo en la nube. La documentación aconseja mantener las reglas por debajo de las 500 líneas y dividir las grandes en piezas combinables, lo que significa que el canal que siempre está cargado es deliberadamente estrecho. Y una regla delimitada por globs solo entra en contexto cuando los archivos coincidentes están en juego; es adecuado, pero significa que el conocimiento específico del área es invisible hasta que el agente ya ha decidido qué archivos tocar.

La documentación enumera lo que persiste, y la memoria no está en la lista

Esta es la parte con la que quiero tener cuidado. La documentación de los agentes en la nube de Cursor cubre entornos, instantáneas, builds, hooks de .cursor/hooks.json, espacios de trabajo multirrepositorio donde "el agente puede inspeccionar todo el espacio de trabajo, realizar cambios coordinados", selección de modelos donde "los agentes en la nube utilizan una selección curada de modelos" con un tamaño de ventana de contexto seleccionable, y un panel de control que muestra qué entorno y build utilizó un agente junto con el historial de versiones.

Lo que no hace es describir la persistencia de contexto, estado o memoria entre ejecuciones de agentes independientes. La documentación de las reglas tampoco contiene ninguna declaración sobre una función de memorias, y cursor.com/docs/agent/memories devuelve un error 404 al momento de escribir este artículo. Por lo tanto, la afirmación precisa no es "Cursor no tiene memoria", sino que el mecanismo documentado para transferir conocimiento entre ejecuciones son los archivos de reglas, y nada en la documentación promete que la segunda ejecución de un agente herede algo de la primera más allá de lo que está en el repositorio.

Planifica en función de lo que está documentado. Si tu equipo confía en la suposición no documentada de que un agente en la nube recuerda la semana pasada, esa suposición no tiene respaldo en la documentación, y el síntoma se manifestará como inconsistencia entre ejecuciones, el equivalente en la nube del problema local descrito en por qué Cursor olvida las sesiones anteriores.

Escribir archivos de reglas más largos. El paso natural, pero choca con la recomendación de las 500 líneas. A partir de cierto tamaño, el archivo que siempre está cargado se convierte en un muro de texto que compite con la tarea real por la atención del modelo, y todo lo que contiene se paga en cada ejecución, sea relevante o no.

Poner el contexto en el comentario activador. Funciona para una ejecución. Significa que la persona que registra el ticket debe conocer todas las limitaciones del proyecto y recordar volver a exponerlas, lo que anula el propósito de delegar en un agente, y no sobrevive para el siguiente ticket.

Añadirlo al entorno. La gente intenta codificar el conocimiento como configuración: un README que el script de instalación lee con cat, un archivo que el comando de inicio muestra con echo. Los entornos son para dependencias y servicios. El conocimiento canalizado a través de ellos es frágil e invisible en la revisión.

Ejecutar todo localmente en su lugar. La respuesta más segura y la más costosa. Renuncias a la razón por la que existen los agentes en la nube: que un compañero de equipo pueda activar el trabajo desde Slack o un comentario de PR sin tener una máquina propia.

Asumir que las reglas se cargaron. Extremadamente común, y la trampa del .md simple lo empeora. Los equipos depuran el modelo cuando el archivo nunca estuvo en contexto. Antes de culpar a un modelo, verifica que las reglas realmente se aplicaron; el patrón de falla se describe en por qué Cursor olvida las reglas del proyecto.

Generar más agentes. Los agentes en la nube en paralelo multiplican el problema en lugar de resolverlo: cada uno comienza con su propio briefing escaso y ninguno sabe lo que concluyeron los demás. Ese es el escenario cubierto en memoria multiagente.

El problema estructural es que un agente en la nube tiene exactamente dos entradas (el activador y el repositorio) y una de ellas es una frase. Los archivos de reglas manejan el pequeño conjunto de cosas que deben estar en contexto en cada ejecución. Lo que no pueden contener es el creciente cuerpo de conocimiento del proyecto: las decisiones, los enfoques rechazados, las limitaciones que hicieron que una pieza de código extraña fuera la elección correcta. Ese material es demasiado grande para un archivo que siempre está cargado y demasiado valioso para dejarlo en una sesión local que ya terminó.

MemoryLake le da a ese conocimiento un hogar que el agente puede consultar en lugar de un archivo que siempre debe llevar consigo: una capa de memoria de la que lee cualquier agente conectado, de modo que una ejecución activada desde un comentario de PR pueda buscar lo que el equipo ya decidió. La configuración consta de tres pasos.

Paso 1: Crea una clave API

Inicia sesión en MemoryLake y crea una clave API. Una sola credencial compartida por cada agente que conectes, lo cual es importante aquí, porque las ejecuciones en la nube se activan desde varias plataformas y no querrás una configuración por plataforma.

Paso 2: Sube tus primeras memorias

Carga el conocimiento que tus archivos de reglas no pueden permitirse llevar. Decisiones de arquitectura y el razonamiento detrás de ellas. Enfoques que probaste y abandonaste, con el motivo (la categoría de mayor valor, porque de lo contrario un agente nuevo con un briefing escaso los volverá a proponer con total confianza). Limitaciones que parecen arbitrarias sin contexto. Convenciones que viven en la cabeza de las personas porque a nadie se le ocurrió escribirlas. Mantén las entradas cortas y con una sola idea cada una, para que la recuperación devuelva algo sobre lo que el agente pueda actuar.

Paso 3: Conecta tu IA y agentes

Conecta tus agentes. MemoryLake es accesible a través de MCP y de una API, por lo que los agentes nativos de MCP (entre ellos Claude Code, Codex y OpenClaw) se conectan apuntando al servidor MCP, y otras herramientas leen la misma memoria a través de la API. Las reglas siguen haciendo su trabajo específico: el puñado de cosas que deben estar en contexto en cada ejecución. Todo lo demás se vuelve recuperable, por lo que un activador escaso deja de significar un briefing escaso. Si estás configurando la parte de MCP por primera vez, configurar la memoria entre IAs con MCP te guiará en el proceso.

Límites honestos. MemoryLake no vigila tus ejecuciones en la nube y no capturará lo que un agente aprendió a menos que alguien lo escriba. No es una capa de cumplimiento obligatorio; si una regla debe cumplirse sin importar lo que decida un modelo, eso pertenece a un hook o a una verificación de CI, que es precisamente para lo que sirve .cursor/hooks.json. And it doesn't replace rules files; the two do different jobs, and the mistake is asking either to do both.

Un activador escaso deja de producir un trabajo deficiente. La persona que registra el ticket ya no necesita ser la que recuerde cada limitación. Esa es la promesa real de los agentes en la nube, y solo se cumple si las limitaciones son accesibles sin ellos.

Las ejecuciones locales y en la nube convergen. En este momento, la misma solicitud a menudo produce un trabajo diferente dependiendo de si la ejecutaste en tu editor después de una larga conversación o desde un mensaje de Slack. Cuando ambos leen la misma memoria, la plataforma deja de importar, lo que también significa que el contexto deja de vivir en una sola máquina.

Los archivos de reglas se vuelven más cortos y, por lo tanto, mejores. Mover el conocimiento de referencia fuera del canal que siempre está cargado no es solo cuestión de orden. Te mantiene dentro de la recomendación de las 500 líneas y reduce el ruido que compite con las reglas que genuinamente deben aplicarse siempre.

Las correcciones repetidas dejan de repetirse. La experiencia más desmoralizadora con un agente en la nube es ver que la ejecución tres comete el error que corregiste en la ejecución uno. Eso sucede porque la corrección vivió en una sesión, y las sesiones terminan. Una vez escrita, está disponible para cada ejecución posterior.

Las revisiones se vuelven más cortas. La mayoría de los comentarios de revisión en las pull requests creadas por agentes no son sobre la calidad del código, sino sobre el contexto que el agente no tenía. Mueve el contexto y una gran parte de la revisión desaparecerá.

Audita `.cursor/rules` hoy mismo en busca de archivos `.md` simples. Cualquier archivo allí sin frontmatter que especifique description, globs y alwaysApply se ignora, silenciosamente. Esta es una verificación de cinco minutos con una alta tasa de aciertos, especialmente en repositorios migrados desde otra herramienta, la misma trampa de conversión descrita en migrar de Windsurf a Cursor.

Conoce qué modo utiliza cada regla. alwaysApply: true para el pequeño conjunto que siempre debe cargarse; globs para reglas específicas de un área; description para aplicación inteligente. Las reglas manuales que requieren una mención con @ nunca se cargarán por sí solas en una ejecución en la nube; trátalas como exclusivas para uso local.

Escribe los activadores como si el agente no supiera nada más allá del repositorio. Porque no lo sabe. Establece el objetivo y los criterios de aceptación; deja que la capa recuperable proporcione los antecedentes.

Usa el panel de control del entorno cuando una ejecución salga mal. La documentación describe que muestra qué entorno y build utilizó un agente, con el historial de versiones. Si una ejecución se comportó de manera diferente a su predecesora, verifica si estaba en una build diferente antes de asumir que el modelo cambió.

Coloca las limitaciones obligatorias en hooks, no en prosa. Los agentes en la nube ejecutan hooks basados en comandos desde .cursor/hooks.json. Cualquier cosa que deba cumplirse en cada cambio pertenece allí, donde se impone en lugar de sugerirse.

Mantén los secretos fuera de la memoria. Los secretos del entorno pertenecen a la configuración del entorno. Una capa de memoria contiene conocimiento, no credenciales.

Las Builds son una mejora genuina y el precio es indiscutible: gratis, activadas de forma predeterminada a partir del 17 de agosto, y los agentes siempre comienzan desde la última build exitosa en lugar de una máquina fría. La razón por la que vale la pena hablar de la brecha restante ahora es que las builds eliminan la excusa. Cuando un agente en la nube tardaba cuatro minutos en iniciarse, la lentitud parecía ser el problema. Iniciar en segundos y proponer inmediatamente el diseño que rechazaste el mes pasado hace evidente que la velocidad nunca fue el problema.

La solución no es un archivo de reglas más largo. Es reconocer que un agente en la nube tiene dos entradas, que una de ellas es una sola frase y que todo lo demás que sabe tu equipo debe poder recuperarse de la otra. Prepara el conocimiento con antelación de la misma manera que Cursor ahora prepara la máquina.