Los agentes en la nube de Cursor ahora se ejecutan en máquinas que tú gestionas: dónde vive realmente el contexto del agente (2026)

La única frase que define la división

Del anuncio:

"Con las Self-Hosted Machines, solo se mueve el entorno de ejecución, mientras que el bucle del agente, la inferencia y la planificación permanecen en la nube de Cursor. Los resultados de las herramientas fluyen de regreso a Cursor para la inferencia y pueden contener código, y las transcripciones del agente pueden ser procesadas y almacenadas por Cursor."

Tres afirmaciones en una sola frase. La ejecución se mueve. Los resultados de las herramientas fluyen de regreso y pueden contener código. Las transcripciones pueden ser procesadas y almacenadas.

La documentación dice lo mismo desde la otra dirección, y vale la pena leer ambas porque la documentación enumera lo que viaja:

"El checkout completo, la caché de compilación y las credenciales locales de la máquina permanecen en tu máquina. Durante una ejecución, el worker envía a Cursor el contenido que el agente necesita, como el contenido de los archivos, la salida de la terminal, los diffs, las capturas de pantalla, los resultados locales de MCP y los metadatos de enrutamiento."

El contenido de los archivos está en esa lista. No porque Cursor esté ocultando algo (lo escribieron claramente), sino porque la inferencia necesita los bytes sobre los que el modelo está razonando. Una arquitectura donde el modelo se ejecuta en otro lugar no puede evitarlo.

Las dos mitades tienen diferentes reglas de retención

La página de seguridad de los agentes en la nube de Cursor divide los datos de los agentes en tipos y asigna a cada uno su propia regla de retención. Dos de ellos son importantes aquí.

El espacio de trabajo de ejecución (runtime workspace) contiene "El repositorio descargado (checked-out), los artefactos de compilación y el contexto de ejecución de herramientas para una ejecución activa". Su retención: "Se recicla automáticamente después de que la ejecución queda inactiva; el temporizador se reinicia cuando envías prompts de seguimiento".

El estado de la conversación contiene "Prompts, respuestas del modelo, llamadas a herramientas, contexto de diffs y artefactos de demostración que componen la transcripción". Vive en el "backend de Cursor, encriptado con claves por agente", y su retención es "Se conserva indefinidamente de forma predeterminada para que puedas volver a visitar y reanudar las ejecuciones; eliminable bajo demanda".

Así que el registro duradero de lo que pensó el agente es la mitad que no se mueve. Las Self-Hosted Machines reubican la mitad efímera.

El valor predeterminado que decide si un seguimiento recuerda

Aquí está la parte con un número real. En la configuración del pool:

"Una vez que un worker se empareja con una solicitud, Cursor reenvía todas las llamadas a herramientas del agente directamente a la máquina. La conexión tiene un tiempo de espera por inactividad que por defecto es de 1 hora".

Y cuando ese temporizador se activa:

"Una vez que un worker agota el tiempo de espera, Cursor lo marca como liberado. La máquina puede reiniciarse y volver a entrar al pool. Si un usuario reinicia un chat que se ha desconectado de su máquina, el chat se vuelve a conectar a una máquina nueva del pool. El estado del espacio de trabajo de la máquina original no se transfiere a menos que el pool utilice la hibernación".

Lee esa última cláusula dos veces. Tu conversación sobrevive: está en el backend, guardada indefinidamente. Tu espacio de trabajo no. La documentación es directa sobre el costo: "un seguimiento que llega después de que la máquina se liberó vuelve a adquirir del pool: el agente aterriza en una máquina nueva y puede pasar sus primeros minutos reconstruyendo el espacio de trabajo que ya tenía".

La hibernación es la respuesta documentada: hacer una instantánea (snapshot) de la máquina cuando se vuelve inactiva, restaurarla si llega un seguimiento dentro de la ventana de reconexión, iniciar "un worker con el mismo id antes de que expire la ventana". Si la instantánea desaparece, liberas el reclamo y "una máquina de reemplazo puede reclamarlo".

Los pools no están vinculados a los repositorios

Un detalle de diseño más con consecuencias para el contexto: "Los pools no están vinculados a repositorios individuales. Una solicitud solo necesita identificar el pool, y cualquier worker disponible puede reclamarla. Esto permite que un pool sirva a muchos repositorios".

Eficiente. También significa que la máquina que atiende tu próxima solicitud no es, por defecto, la máquina que tiene algún historial con tu proyecto.

Sí mueve la ejecución, y ese es el punto. Los equipos generalmente lo usan, según Cursor, cuando "la ejecución de herramientas del agente debe ocurrir dentro de su red, con acceso directo al control de código fuente, servicios internos y repositorios de código", cuando los agentes necesitan "hardware personalizado, como GPUs o Macs para el desarrollo de iOS", o cuando el pipeline de compilación es "difícil de empaquetar como una compilación de Cloud Agent". Esas son limitaciones reales y esto las resuelve genuinamente.

No mueve la capa de razonamiento, y eso es por diseño. Cursor ejecuta "el bucle del agente, la inferencia y la planificación". Tu worker "realiza ediciones de archivos y comandos de terminal. También ejecuta herramientas de uso de computadora y servidores MCP locales".

No es una peculiaridad de Cursor. La misma estructura aparece en los sandboxes autoalojados de Anthropic para Managed Agents, documentados en un lenguaje casi paralelo: el autoalojamiento "mantiene la orquestación del lado de Anthropic pero mueve la ejecución de herramientas a la infraestructura que tú controlas". Y específicamente en la capa de memoria: "Las habilidades del agente y el contenido de cualquier almacén de memoria adjunto a la sesión son almacenados por Anthropic y copiados en tu sandbox para la sesión; los cambios que el agente realiza en los archivos de memoria se sincronizan de vuelta con el almacén". Anthropic incluso documenta un límite estricto: "Los almacenes de memoria no se pueden adjuntar a sesiones en entornos autoalojados en Claude Platform en AWS". Dos proveedores, la misma conclusión arquitectónica: el autoalojamiento reubica el sandbox, no la memoria. Vale la pena comprender la mecánica de estos almacenes alojados en sus propios términos, que es lo que cubre los almacenes de memoria de agentes de Claude.

No cambia, por sí solo, tu postura de privacidad para peor. Los Cloud Agents "se ejecutan en Privacy Mode", y con este activado "Cursor nunca entrena con el código al que acceden los Cloud Agents ni con los prompts y respuestas que generan sus ejecuciones". Existe una API de Delete Agent que "elimina la transcripción de la conversación y los artefactos de un agente bajo demanda", y los equipos Enterprise "también pueden limitar la retención de conversaciones con políticas de retención". Los Runtime Secrets se "eliminan de la transcripción, la salida de la herramienta y los commits, y nunca llegan al modelo". Estos son controles significativos y están documentados.

"Ahora nada sale de la red". La lectura más común, y la que corrige la propia frase de Cursor: los resultados de las herramientas fluyen de regreso para la inferencia y pueden contener código. Lo que se queda en su lugar es el checkout, la caché de compilación y las credenciales locales de la máquina. Esa es una afirmación genuinamente diferente y más estrecha que "nada sale".

"Así que el agente recuerda más, porque la máquina es nuestra". Al revés, para configuraciones con pools. Ser dueño de la máquina no amplía la memoria del agente; introduce un temporizador de liberación que ahora tú administras. Sin hibernación, una máquina liberada por inactividad significa que el próximo seguimiento comienza en hardware nuevo.

"La hibernación está activada". Es un patrón que tú implementas, no un interruptor que se activa por ti: acortar el tiempo de espera de liberación por inactividad, hacer una instantánea al estar inactiva, vigilar la entrada de la cola de reclamada-pero-sin-conexión (claimed-but-offline), restaurar antes de que expire la ventana. Ese es un controlador que tú escribes y operas.

"La transcripción también está de nuestro lado ahora". No lo está. El estado de la conversación reside en el backend de Cursor, conservado indefinidamente de forma predeterminada. Eliminable bajo demanda, limitable por política, pero no reubicado por las Self-Hosted Machines.

"Un pool, un proyecto". Los pools sirven a cualquier repositorio. Si contabas con la afinidad de máquina para mantener un espacio de trabajo activo para un repositorio específico, eso no es lo que garantiza un pool.

Paso 1: Escribe dónde vive cada tipo de estado en tu configuración

Tómate quince minutos y elabora una tabla de cuatro líneas para tu propio despliegue. La documentación de Cursor te da tres de las líneas; la cuarta es tuya.

Checkout, caché de compilación, credenciales locales de la máquina — tu máquina, desaparecen cuando el worker se reinicia. Espacio de trabajo de ejecución (runtime workspace) — tu máquina, reciclado tras la inactividad. Transcripción de la conversación — backend de Cursor, indefinido por defecto. Conocimiento duradero del proyecto — esta es la línea que la mayoría de los equipos no pueden completar, porque la respuesta es "en cualquier transcripción que casualmente lo contuviera".

Esa cuarta línea es todo el problema. Todo lo que está por encima de ella es efímero por diseño o está en manos de tu proveedor.

Paso 2: Configura los temporizadores deliberadamente, luego verifica una liberación

Dos perillas, y su interacción es lo que complica las cosas. Configura el tiempo de espera por inactividad de la conexión del worker con intención en lugar de heredar el valor predeterminado de una hora, y decide explícitamente si el pool utiliza la hibernación.

Luego prueba el caso que realmente te importa. Inicia un agente, deja que construya un estado de espacio de trabajo real, espera a que pase el tiempo de espera por inactividad y envía un seguimiento. Observa si el agente se reanuda o pasa sus primeros minutos reconstruyendo. Hazlo una vez y sabrás qué comportamiento tiene tu pool, lo cual vale más que cualquier inferencia de la documentación.

Mientras estás allí, verifica que tu controlador maneje la ruta sin conexión. Cursor anuncia un seguimiento para una máquina sin conexión como una entrada de cola reclamada-pero-sin-conexión (claimed-but-offline) con claimedWorkerId y wakeTimeoutMs, y emite un evento coincidente. Si nada en tu infraestructura está vigilando eso, la hibernación no está configurada realmente.

Paso 3: Coloca el conocimiento que debe sobrevivir fuera de cada máquina y de cada transcripción

Los pasos 1 y 2 te brindan un mapa preciso y temporizadores predecibles. No responden a la pregunta de fondo: cuando un worker nuevo reclama tu seguimiento, ¿cómo conoce el agente tus convenciones?

Hoy la respuesta es "de la transcripción, si está allí". Eso convierte al conocimiento duradero en un subproducto del historial de conversaciones: en manos de tu proveedor, indefinido por defecto y organizado por sesión en lugar de por tema. Es un sistema de archivo deficiente para datos que deberían ser ciertos en cada ejecución, y el mismo razonamiento se aplica a cualquier capa de ejecución sin estado, razón por la cual memoria para tareas de MCP llega a la misma conclusión.

Una capa de memoria separada elimina por completo a la máquina de la ecuación. Cualquiera que sea el worker que reclame la solicitud, en cualquier pool, en cualquier repositorio, el agente leerá el mismo almacén. La hibernación deja de ser lo que se interpone entre un seguimiento y una respuesta competente, y se convierte en lo que debería ser: una optimización de costos para mantener activo el espacio de trabajo. MemoryLake se configura en tres pasos.

Paso 1: Crea una clave API

Inicia sesión y genera una clave API desde tu panel de control. La credencial está vinculada a ti en lugar de a un worker, un pool o una imagen de máquina, que es la propiedad que importa cuando la máquina que responde a tu próximo prompt es una que tu controlador inició hace noventa segundos.

Paso 2: Sube tus primeros recuerdos

Introduce aquello que un worker nuevo no tiene forma de reconstruir a partir de un checkout: decisiones arquitectónicas y las razones detrás de ellas, convenciones de despliegue, los servicios internos que un agente tiene permitido tocar, las correcciones que ya has escrito en tres sesiones diferentes.

Deja lo efímero como efímero. Las cachés de compilación y los checkouts deben reciclarse; eso no es una pérdida.

Paso 3: Conecta tu IA y agentes

Apunta tus agentes al almacén. Una solicitud del pool llegará entonces con el conocimiento del proyecto ya en mano, y reconstruir un espacio de trabajo te costará minutos de tiempo de compilación en lugar de una nueva explicación.

El primer cambio es que el ajuste del pool se convierte en una decisión económica en lugar de una decisión de conocimiento. En este momento, acortar un tiempo de espera por inactividad para ahorrar dinero también acorta lo que el agente sabe. Esas no deberían ser la misma palanca.

El segundo es que el pool multirepositorio se vuelve seguro de usar tal como fue diseñado. Un pool que sirve a muchos repositorios es eficiente precisamente porque los workers son intercambiables, y los workers intercambiables solo son un problema cuando el worker es donde vive el conocimiento.

El tercero es que tu conocimiento duradero deja de ser un derivado de la política de retención. Limitar la retención de conversaciones es una buena práctica de gobernanza; no debería reducir silenciosamente lo que tus agentes entienden sobre tu base de código. Mantener ambos separados es el mismo principio detrás de compartir una sola memoria a través de herramientas en lugar de hacerlo por producto.

• Cita el límite real, no el resumen. La ejecución se mueve; el bucle del agente, la inferencia y la planificación permanecen en la nube de Cursor, y los resultados de las herramientas fluyen de regreso para la inferencia.
• Configura el tiempo de espera por inactividad a propósito. El valor predeterminado de la conexión es de una hora. Decide si eso coincide con la forma en que tu equipo envía los seguimientos.
• Trata la hibernación como infraestructura que tú operas. Haz una instantánea al estar inactiva, vigila las entradas reclamadas-pero-sin-conexión (claimed-but-offline), restaura con el mismo id de worker dentro de la ventana.
• No confíes en la afinidad de máquina. Los pools no están vinculados a repositorios; cualquier worker disponible puede reclamar una solicitud.
• Usa los controles de retención existentes. La API de Delete Agent para una transcripción específica, las políticas de retención de Enterprise para una ventana, los Runtime Secrets para mantener los valores completamente fuera de las transcripciones y los commits.
• Mantén el Privacy Mode estándar en toda la organización. El Privacy Mode heredado (Legacy) no es compatible con los Cloud Agents, y la documentación recomienda aplicar el modo estándar para que cada ejecución herede sus garantías.
• Audita lo que sabe un worker nuevo. Si la respuesta depende de qué transcripción esté adjunta, ese conocimiento aún no es duradero.
• Vuelve a verificar después de los cambios. Esto se lanzó el 2 de septiembre de 2026, junto con las integraciones de proveedores de sandbox y el uso de computadoras Linux. Las tecnologías que avanzan rápido cambian constantemente.

Las Self-Hosted Machines son una respuesta real a una limitación real, y Cursor documentó sus límites con más cuidado de lo que lo hizo la cobertura a su alrededor. La ejecución se traslada a tu red. El bucle del agente, la inferencia y la transcripción no lo hacen.

La consecuencia práctica es más estrecha que los titulares y más útil: en un despliegue con pools, un tiempo de espera de infraestructura ahora ayuda a decidir si tu agente comienza un seguimiento informado o desde cero. Configura ese temporizador deliberadamente, implementa la hibernación si mantener activo el espacio de trabajo es importante, y mantén el conocimiento que debe sobrevivir a cada liberación en una capa que ningún worker posea.