Cursor AI en mayo de 2026: 2 brechas que aún no cierra frente a Cloudflare Workers

El 13 de mayo, Cursor AI estrenó entornos de agentes en la nube capaces de trabajar con varios repositorios. Según la propia página del producto, más del 30% de las pull requests que Cursor fusiona ya las crean agentes autónomos que operan en sandboxes en la nube.

Qué lanzó realmente Cursor AI el 13 de mayo

La novedad central son los entornos de agentes en la nube compatibles con varios repositorios. Ahora, un agente puede trabajar en múltiples repositorios desde un único entorno configurado, sobre la base de los espacios de trabajo multirraíz que Cursor lanzó el 24 de abril. Además, el entorno puede reutilizarse entre sesiones. En la práctica, ya no hay que volver a preparar la misma máquina de desarrollo cada vez que se inicia un agente.

La configuración gira en torno a un Dockerfile. Los secretos de compilación quedan limitados a esa fase y no se transfieren al agente en ejecución. Así se evita uno de los errores más comunes en la infraestructura para agentes: que una clave de API incluida por accidente en una compilación termine en la memoria de trabajo del agente. Cursor también puede configurar el Dockerfile tras inspeccionar las herramientas y dependencias de los repositorios. Ese flujo sigue en beta privada para equipos Enterprise.

El almacenamiento en caché por capas recibió la mejora de rendimiento más importante. Cuando se reutiliza la caché, las compilaciones son ahora un 70% más rápidas porque solo se reconstruyen las capas modificadas del Dockerfile. Para los equipos que ponen en marcha agentes una y otra vez, es la diferencia entre esperar y avanzar.

La capa operativa es la parte que los competidores siguen subestimando. Cada entorno cuenta con un historial de versiones y permite revertir cambios; esta última acción está restringida a administradores. Un registro de auditoría guarda todas las acciones que los miembros del equipo realizan en los entornos. Las listas de destinos permitidos para el tráfico saliente y el alcance de los secretos se definen por entorno, de modo que un secreto disponible en el entorno A no puede alcanzarse desde el entorno B. Es la infraestructura poco vistosa, pero imprescindible, antes de permitir que un agente abra pull requests sobre código de producción.

El caso que Cursor presenta como prueba es Amplitude. Sus Cursor Automations observan canales públicos de Slack, investigan los problemas reportados, determinan qué repositorios están afectados y abren pull requests en los repositorios adecuados. Es un agente multirrepositorio que realiza el primer nivel de diagnóstico en una empresa real y a escala real. No es una demostración.

La cifra de pull requests fusionadas es la prueba de Cursor AI

Cursor afirma que más del 30% de las pull requests que fusiona ya las crean agentes autónomos que operan en sandboxes en la nube. El denominador es importante: se trata de pull requests fusionadas, no de intentos realizados por agentes. Esa cifra demuestra que el ciclo puede completarse —revisión, correcciones y entrega incluidas— sin que una persona tenga que enviar cada commit.

Desde el 2 de septiembre de 2026, Self-Hosted Machines de Cursor permite trasladar la edición de archivos, los comandos de terminal, las herramientas de interacción con la computadora y la ejecución local de MCP a workers administrados por el cliente, mientras Cursor conserva en su nube el ciclo del agente, la inferencia y la planificación. Con esto desaparece la brecha relativa a la ubicación privada de la ejecución, pero Cursor no se convierte en un runtime programable y persistente.

La disyuntiva ya no es «estado limitado a una sesión o estado persistente». Cursor conserva el estado de las conversaciones en su backend para que las ejecuciones puedan retomarse más adelante, y Self-Hosted Team Pools puede restaurar un espacio de trabajo en hibernación. La diferencia más precisa está entre el estado del agente administrado por el proveedor y el estado programable de la aplicación. Cloudflare expone un estado SQLite por Agent y pasos de workflow persistentes que el desarrollador controla desde el código.

Lo que ya resuelve mi stack de Cloudflare Workers y Agents SDK

Mantengo seis agentes en producción sobre Cloudflare. El runtime es Workers; el estado reside en Durable Objects con una base SQLite por instancia, y la orquestación de larga duración se ejecuta en Cloudflare Workflows. Lo construí en solitario, dentro de una sola cuenta, y está explicado aquí en detalle. En abril de 2026, todo el stack de Cloudflare costó $19.14. Es una factura real de producción correspondiente a una fecha concreta, no una cotización de la plataforma. Cursor muestra el precio de Enterprise como Custom; Team Pools requiere Enterprise, y Self-Hosted Machines sigue sumando el costo del modelo elegido y la factura del worker.

Hay tres diferencias entre este stack y el producto actual de Cursor.

Varios repositorios, mediante código. Un Worker puede obtener recursos a través de HTTP durante la ejecución. Browser Run, antes llamado Browser Rendering, puede controlar un navegador sin interfaz gráfica cuando el contexto está detrás de un sitio web. Cursor empaqueta el acceso a varios repositorios como una configuración de entorno reutilizable; Cloudflare deja en manos del desarrollador la obtención de datos, la autenticación y la lógica de repositorios. No es mejor ni peor: es una superficie de control distinta.

Estado persistente y programable. Un Cloudflare Agent guarda automáticamente el estado de la aplicación en su propia base de datos SQLite y lo vuelve a cargar después de un reinicio o una hibernación. Cursor también conserva el estado de la conversación y permite reanudar ejecuciones. La diferencia es el control: Cursor es propietario del almacén de conversaciones y del runtime del agente, mientras Cloudflare expone al código el estado de la aplicación y su esquema.

Persistencia entre pasos, no ejecución automática exactamente una vez. En Workflows, cada paso puede reintentarse por separado y generar estado para que la ejecución se conserve y continúe después de un fallo de red o de infraestructura. step.do acepta una configuración de reintentos por paso, NonRetryableError detiene los reintentos ante fallos terminales y los identificadores de instancia son únicos dentro de cada Workflow. Sin embargo, un paso puede ejecutarse más de una vez, y Cloudflare indica expresamente que las llamadas con efectos secundarios deben ser idempotentes. La ventaja está en la persistencia definida por el desarrollador y en el control de los reintentos, no en una protección automática contra pull requests, correos o cargos duplicados.

Las dos brechas que Cursor aún no ha cerrado

Brecha 1: estado programable del agente bajo control del cliente. Cursor ya resolvió la reanudación básica: de forma predeterminada, conserva indefinidamente el estado de las conversaciones, mientras las instantáneas de las máquinas virtuales administradas siguen una ventana móvil de 90 días de inactividad. Self-Hosted Machines traslada la ejecución de herramientas, pero Cursor todavía opera el ciclo del agente y almacena la conversación. Un Cloudflare Agent expone dentro del runtime de la aplicación un estado respaldado por SQLite. Esto importa cuando un agente supervisa incidentes, coordina una migración o mantiene el estado del negocio durante un proceso de incorporación de varios días.

Es una brecha más estrecha que la descrita en mayo. Cursor puede reanudar las ejecuciones de agentes dentro de su producto, pero no ofrece una máquina de estados propiedad del cliente que la aplicación pueda consultar, ampliar y coordinar con independencia de un chat de Cursor.

Brecha 2: una capa de pasos persistentes definida por el desarrollador. La documentación actual de Cloud Agent y Self-Hosted Machine de Cursor no ofrece una primitiva de aplicación equivalente a un paso de Workflow con estado persistente y una configuración de reintentos propia. Cloudflare sí. La diferencia se vuelve importante cuando un agente de programación interviene en facturación, correo electrónico, despliegues u otro efecto externo.

Trasladar las llamadas a herramientas a una máquina propia no cierra esa brecha: cambia el lugar de ejecución, no el contrato de orquestación. Cloudflare tampoco garantiza que los efectos secundarios ocurran exactamente una vez; sigue siendo necesario diseñar cada paso sujeto a reintentos para que sea idempotente.

Nada de esto es una crítica a Cursor. Es una cuestión de categoría. Cursor es un producto de programación que admite tanto la ejecución administrada de herramientas como la ejecución a cargo del cliente. Cloudflare es un runtime programable para aplicaciones. El lanzamiento de septiembre reduce la distancia en infraestructura, pero la frontera entre estado y orquestación todavía separa ambos productos.

Qué deberían hacer esta semana los fundadores y CTO

Tres perfiles requieren tres decisiones distintas.

Para un equipo de producto pequeño que está lanzando funcionalidades, conviene usar los Cloud Agents administrados por Cursor cuando sus entornos y controles de red permitan reproducir la compilación. El lanzamiento de entornos del 13 de mayo cubre la preparación multirrepositorio, los secretos de compilación, la caché y la auditoría; además, la cifra pública de más del 30% de pull requests fusionadas ofrece una prueba concreta. No conviene operar una flota de workers si ninguna política interna lo exige.

Para quienes ya ejecutan procesos en segundo plano de larga duración en Cloudflare o Vercel, el estado persistente de la aplicación y la orquestación deben permanecer allí. Self-Hosted Machines de Cursor ya puede usar infraestructura de Cloudflare o Vercel para ejecutar herramientas, pero Cursor continúa a cargo del ciclo del agente. Existe un caso equivalente en el mercado de consumo que merece una lectura sobre cómo Anthropic empaqueta primitivas similares para pequeñas y medianas empresas: la convergencia de las plataformas en torno a los agentes se observa en todas partes.

Para quienes preparan un despliegue empresarial, el punto de partida deben ser los Cloud Agents administrados cuando las listas de destinos permitidos, Tailscale, AWS PrivateLink o Cloudflare Tunnel satisfagan los requisitos de acceso. Team Pools es la opción cuando el checkout, la ejecución de herramientas, el hardware personalizado o la imagen del worker deban permanecer bajo control propio. Team Pools requiere Enterprise, cuyo precio figura como Custom, y los Dockerfiles configurados por Cursor siguen en beta privada.

Qué cambió después de mayo

Hay dos señales importantes.

Primero, Cursor ya documenta el estado de la conversación por separado del espacio de trabajo de ejecución. De forma predeterminada, ese estado se conserva indefinidamente para poder volver a una ejecución y reanudarla; las instantáneas de las máquinas virtuales administradas caducan después de 90 días de inactividad, salvo que un inicio o una reanudación amplíe ese plazo. La reanudación básica dejó de ser una brecha. La propiedad y la capacidad de programar el estado no.

Segundo, la ubicación privada de la ejecución también dejó de ser una brecha. Self-Hosted Machines la resuelve sin sacar de la nube de Cursor el ciclo del agente, la inferencia ni la planificación. Las dos diferencias relevantes que quedan son el estado del agente bajo control del cliente y una capa de pasos persistentes definida por el desarrollador.

¿El lanzamiento de Cursor del 13 de mayo elimina la necesidad de infraestructura autohospedada para agentes?

No. Cursor ya ofrece su propia vía autohospedada: My Machines para flujos de trabajo personales y Team Pools para flotas Enterprise. Así, la ejecución de herramientas se traslada a la red del cliente, pero Cursor sigue operando el ciclo del agente y almacenando el estado de la conversación. Los equipos que necesitan un runtime programable para aplicaciones o pasos de workflow persistentes todavía requieren infraestructura para esas capas.

¿Cuánto más rápidas son ahora las compilaciones en caché de los agentes de Cursor?

Tras la mejora del almacenamiento en caché por capas del 13 de mayo, las compilaciones que reutilizan la caché son un 70% más rápidas. En ese caso, solo se reconstruyen las capas modificadas del Dockerfile.

¿Qué significa la cifra interna de solicitudes fusionadas de Cursor?

La página oficial actual de Cursor afirma que más del 30% de las pull requests que fusiona las crean agentes autónomos que operan en sandboxes en la nube. Es una señal útil de adopción en producción porque mide pull requests fusionadas, no intentos.

¿Son seguros los agentes en la nube de Cursor para código que utiliza secretos de producción?

El lanzamiento del 13 de mayo limita por entorno tanto el tráfico saliente como los secretos, aísla los secretos de compilación del agente en ejecución y ofrece historial de versiones, reversión y registros de auditoría. Self-Hosted Machines puede mantener todo el checkout y las credenciales locales de la máquina en el worker del cliente, pero el contenido necesario de los archivos, la salida de las herramientas, los diffs, las capturas de pantalla y los resultados de MCP local aún pueden enviarse a Cursor. La seguridad depende de aprobar ambos límites.

¿Puedo usar Cloudflare Workers y los agentes en la nube de Cursor al mismo tiempo?

Sí. Cursor incluye Cloudflare entre las integraciones de Self-Hosted Machines, y su plantilla de referencia utiliza un Cloudflare Worker como controlador para iniciar un Cloudflare Container por cada solicitud que toma. Cursor puede encargarse del ciclo del agente de programación, mientras Workers, Durable Objects y Workflows administran el estado persistente de la aplicación y la orquestación. Los productos ahora se superponen en la ejecución de herramientas, pero no en la frontera del ciclo del agente.