Cursor Projects mantiene el contexto durante meses: nada llega al siguiente agente a menos que lo lleve un archivo (2026)

La publicación del lanzamiento es específica sobre el alcance. Projects, escribe Cursor, "te permite abordar conjuntos de trabajo más grandes, como una funcionalidad, una migración o una aplicación completa. Mantiene el contexto a lo largo de meses de trabajo, delega tareas en miles de subagentes y realiza trabajos recurrentes sin necesidad de indicaciones".

El coordinador deliberadamente no es un programador: "El agente coordinador en un proyecto no escribe código por sí mismo; planifica el trabajo, lo delega en agentes que lo implementan y te devuelve el trabajo terminado para que lo revises". También se ejecuta en un lugar donde tú no estás: "Un Project se ejecuta en su propia computadora en la nube, por lo que cerrar tu laptop no lo detiene", y puede comenzar a trabajar por su cuenta, vigilando un canal de Slack, un cronograma o un conjunto de pull requests.

La sección que más importa para el contexto es la que Cursor tituló, en el propio anuncio, "Shared context" (Contexto compartido):

"Cada Project mantiene un conjunto de archivos que se sincronizan en cada máquina local y en la nube que utilizan sus agentes. Los agentes añaden investigaciones y artefactos, junto con lo que aprenden sobre la base de código y cómo prefieres que se haga el trabajo."

Y luego el ejemplo que revela el mecanismo: "Si un agente descubre cómo probar un servicio, por ejemplo, cada agente futuro podrá usar esas instrucciones. El contexto compartido crece con el Project, haciendo que el coordinador sea más efectivo con el tiempo".

Lee ese ejemplo con atención. El beneficio es real y es condicional. Cada agente futuro puede usar esas instrucciones porque un agente las escribió en un archivo. El conocimiento no viajó porque los agentes estuvieran conectados. Viajó porque se escribió.

La documentación de subagentes de Cursor dice la otra mitad en voz alta:

"Los subagentes comienzan con un contexto limpio. El agente padre incluye información relevante en el prompt, ya que los subagentes no tienen acceso al historial de conversaciones anterior."

Ese es todo el modelo en dos frases. Un subagente recibe un prompt y un checkout. No recibe el historial. El padre decide qué incluir, y el conjunto de archivos sincronizados del Project es lo que sobrevive al padre.

No cambia cuánto puede contener un solo agente. La propia razón de Cursor para aislar a los subagentes es el presupuesto: "Cada subagente tiene su propia ventana de contexto. Las tareas largas de investigación o exploración no consumen espacio en tu conversación principal". Los tres subagentes integrados (para exploración de la base de código, comandos de shell y control del navegador) existen porque esas operaciones son ruidosas, y la justificación declarada de Cursor es que "La salida intermedia se queda en el subagente. El padre solo ve el resumen final".

Así que lo que llega al siguiente paso es un resumen, por diseño. Cualquiera que haya visto a un agente volver a deducir con total confianza una decisión que ya había tomado hace tres horas ha experimentado la consecuencia de ese diseño. Nuestro artículo anterior sobre lo que realmente leen los agentes de programación analiza ese mismo límite desde la perspectiva de un solo agente; Projects lo multiplica por el número de trabajadores.

Tampoco hace que el conjunto de archivos compartidos sea un registro completo. Cursor también es cuidadoso aquí. En el lanzamiento del 19 de agosto, una entrada independiente (que no formaba parte del lanzamiento de Projects) introdujo subagentes en sus propias máquinas: "Los subagentes ahora pueden ejecutarse en sus propias máquinas virtuales. Cada uno obtiene una copia aislada del proyecto con un contexto limpio en su propio entorno en la nube". Y la documentación de subagentes advierte sobre el comportamiento predeterminado: "Los subagentes comparten el checkout del agente padre por defecto. Cuando varios subagentes editan archivos a la vez, pueden sobrescribir los cambios de los demás".

Lo que sí cambia es dónde vive la parte duradera de tu proyecto. Antes de Projects, un esfuerzo a largo plazo vivía en un chat que mantenías abierto y en un conjunto de archivos de instrucciones que gestionabas a mano. Después de Projects, el chat desaparece como canal de transmisión (hay cientos de chats, cada uno comenzando desde cero) y el conjunto de archivos se convierte en el único canal. Esa es una mejor arquitectura. También significa que la calidad de la memoria de tu proyecto es ahora exactamente la calidad de lo que alguien se molestó en escribir.

Esta no es una observación exclusiva de Cursor. Es hacia donde se ha dirigido la categoría. La documentación de Crew de Kiro describe subagentes que "se ejecutan en paralelo con un contexto aislado". Factory define a los droids personalizados como subagentes "con su propio prompt de sistema, modelo y política de herramientas a los que el Droid delega tareas enfocadas en una nueva ventana de contexto". Las canalizaciones de subagentes de Zencoder "generan subprocesos aislados con diferentes modelos, contextos y habilidades para una ejecución paralela y un aislamiento limpio del contexto". Warp toma el camino opuesto en cuanto a portabilidad y dice que sus "Rules, Skills, servidores MCP y Codebase Context se aplican de la misma manera en la aplicación, la CLI y la nube"; la misma conclusión desde la otra dirección: la capa duradera es la declarada, no la conversacional. Esto no es una crítica a ninguno de ellos. Son cuatro equipos que deciden de forma independiente que un contexto limpio supera a un contexto heredado, y los cuatro te dejan a ti la tarea de proporcionar la parte que debe persistir.

"El coordinador recuerda, así que no tengo que escribir las cosas". El coordinador mantiene un conjunto de archivos. No mantiene una historia oral. Cualquier cosa que un subagente haya aprendido y resumido desaparece al final de la ejecución de ese subagente, a menos que haya quedado registrada en los archivos.

"Miles de subagentes significan miles de perspectivas sobre mi base de código". Significa miles de inicios limpios. La amplitud proviene del paralelismo; la continuidad proviene de la capa escrita. Nuestro artículo sobre por qué el contexto largo no es memoria hace la misma distinción a nivel de modelo.

"Este es el mismo problema que los subagentes de Claude Code". Cerca, pero no es el mismo objeto, y vale la pena separarlos. El hecho de que los subagentes de Claude Code no compartan memoria se refiere a una sola sesión que se ramifica y regresa. Un Cursor Project está acotado a un conjunto de trabajo (una funcionalidad, una migración o una aplicación completa) que se ejecuta durante meses en máquinas que nunca ves. El radio de impacto es diferente, y también lo es la solución. Del mismo modo, el hecho de que los agentes en la nube de Cursor olviden el contexto cubre una sola ejecución remota; esto trata sobre la capa que sobrevive a cada ejecución.

"Un Project es donde debería vivir el conocimiento de mi equipo". Parte de él, sí. Pero un Project está acotado a un Project. Las convenciones sobre las que tu equipo debatió durante dos semanas (por qué rechazaron la otra base de datos, qué servicio es propietario de la migración, qué significa "terminado" para un lanzamiento) no son datos específicos de una funcionalidad. Sobreviven al Project que las originó, y deben ser legibles por el próximo Project y por cualquier herramienta que use la persona que tienes al lado.

El objetivo no es luchar contra la arquitectura. Es dejar de pedirle a un conjunto de archivos específico de un Project que contenga el razonamiento de múltiples proyectos.

Paso 1: Separar los artefactos del trabajo de las decisiones del proyecto

Revisa lo que acumula un Project y clasifica cada elemento con una sola pregunta: ¿seguirá siendo esto cierto después de que se lance la funcionalidad? "Cómo levantar el servicio de pagos para las pruebas" es un artefacto de este trabajo y pertenece exactamente a donde Cursor lo coloca. "No añadimos una dependencia sin un propietario" es una decisión, y será igual de cierta en el próximo Project, en tu editor y en la revisión de código dentro de tres meses.

Los artefactos van en el Project. Las decisiones van en una capa de la que lee el Project.

Paso 2: Capturar la razón, no solo la regla

Un coordinador que lee "usa el patrón de repositorio aquí" lo seguirá y no sabrá por qué. Un coordinador que lee "usamos el patrón de repositorio aquí porque el adaptador heredado tiene fugas de conexiones bajo carga, y nos topamos con eso en producción" puede saber cuándo deja de aplicarse la regla. Esta es la diferencia entre un archivo de instrucciones y un registro de decisiones, y es lo que hace que valga la pena llevar el registro entre Projects en lugar de volver a escribirlo cada vez.

Paso 3: Darle al registro una dirección a la que pueda acceder cualquier interfaz

Cursor sincroniza sus archivos de Project "en cada máquina local y en la nube que utilizan sus agentes", lo que resuelve la portabilidad dentro de un Project. No resuelve la portabilidad entre Projects, ni entre las demás herramientas de tu equipo. Coloca el registro de decisiones en un lugar direccionable, mantén el conjunto de archivos del Project apuntando a él, y dejarás de mantener el mismo párrafo en cuatro lugares diferentes. Nuestra nota sobre cómo convertir los documentos del proyecto en memoria de IA cubre el proceso de clasificación con más detalle.

Una capa de decisiones compartida es para lo que sirve MemoryLake: un lugar donde vive el razonamiento, legible por el coordinador, por el agente local y por el próximo Project que nunca haya visto nada de esto.

Paso 1: Crear una clave de API

Inicia sesión, abre la configuración de tu espacio de trabajo y genera una clave de API. Esta es la credencial que tus agentes y editores utilizan para leer la misma capa, así que créala una vez y mantenla disponible para cada interfaz desde la que trabajes.

Paso 2: Subir tus primeras memorias

Comienza con las decisiones que ya has explicado más de dos veces: la decisión arquitectónica y su motivo, las convenciones que han sobrevivido a un ciclo de revisión, las restricciones que no son obvias a partir del código. Mantén cada entrada lo suficientemente corta como para que un coordinador pueda actuar sobre ella sin tener que cargar un documento completo.

Paso 3: Conectar tu IA y agentes

Conecta las herramientas que realmente utilizas (el editor, el agente de terminal, las ejecuciones en la nube) para que el mismo razonamiento llegue a cada una de ellas. Un subagente seguirá comenzando limpio. Solo que comenzará limpio con las decisiones del proyecto ya frente a él.

La primera diferencia aparece cuando termina un Project. En lugar de un conjunto de archivos que se queda obsoleto lentamente en un Project cerrado, el razonamiento ya está en un lugar que el próximo Project lee, y los artefactos se quedan donde pertenecen.

La segunda aparece cuando un coordinador delega. El modelo de Cursor hace que el padre decida qué poner en el prompt. Cuando los datos duraderos viven en una capa de la que el padre puede citar, esa decisión se vuelve más fácil y consistente, y dejas de ver a los subagentes llegar a tres respuestas diferentes para una pregunta que resolviste en mayo.

La tercera aparece en tu peor día. Un Project que se ejecuta sin indicaciones contra un canal de informes de errores eventualmente tomará una acción que tú no habrías tomado. La pregunta útil después de eso es a partir de qué estaba trabajando, y eso se puede responder cuando las decisiones vigentes están escritas y versionadas en lugar de ser reconstruidas a partir de un resumen. Auditar lo que tu IA recuerda es la práctica que permite responder a eso.

Escribe para un lector sin historial. Cada subagente es ese lector. Las entradas que comienzan con "como se discutió" son entradas que se interpretarán mal.

Mantén lo que siempre es cierto separado de lo que es cierto actualmente. El estado del sprint pertenece al Project. Las decisiones vigentes pertenecen a la capa inferior. Mezclarlos significa que la capa se deteriora en el momento en que termina el sprint.

Registra la opción rechazada. La forma más económica de evitar que un agente vuelva a proponer algo es tener el rechazo y su motivo escritos una sola vez.

Vuelve a leer lo que un agente escribió sobre tu base de código. Cursor dice que los agentes añaden "lo que aprenden sobre la base de código y cómo prefieres que se haga el trabajo". Ese es un mecanismo genuinamente útil y también es una inferencia. Trata las primeras entradas como borradores y corrígelas, de la misma manera que corregirías las notas de incorporación de un nuevo compañero de equipo.

Asume que el traspaso de información tiene pérdidas y hazlo económico. No puedes ensanchar el canal entre los agentes. Puedes asegurarte de que lo que viaje a través de él sea la conclusión en lugar de la transcripción.

Cursor Projects es una pieza de ingeniería seria y su modelo de contexto es el más honesto: los subagentes comienzan limpios, el padre proporciona lo que necesitan y los archivos sincronizados del Project son lo que sobrevive. La consecuencia es fácil de enunciar y fácil de pasar por alto. En una arquitectura donde cada trabajador comienza de la nada, la capa escrita no es algo opcional. Es todo el ancho de banda entre todo lo que sucede hoy y todo lo que sucederá el próximo mes.

Projects está en fase beta y se está implementando para todos los usuarios. Si estás a punto de dirigir un coordinador hacia meses de trabajo, la hora de mayor impacto que pasarás no será en el prompt. Será escribiendo las decisiones que de otro modo esperarías que recordara.