Cursor crea Origin para alojar código de flotas de agentes de IA, que se lanza hoy

Why it matters

Origin would give Cursor control of the repository layer beneath its editor, cloud agents and code review, turning a coding tool into an integrated software-production stack.

Michael Truell (@mntruell), cofundador y CEO de Cursor, presentó Origin el 16 de junio como una plataforma Git diseñada para manejar código producido por equipos de agentes de IA. Cursor lanzará Origin el 11 de agosto tras haber limitado inicialmente el producto a una lista de espera por correo de trabajo.

El lanzamiento extiende el alcance de Cursor a lo largo de todo el trayecto desde asignar trabajo a un agente hasta escribir, probar, revisar, almacenar y fusionar el código resultante. Origin agrega alojamiento de repositorios a una línea de productos que ya incluye un editor orientado a agentes, ejecución en la nube, revisión automatizada de pull requests, automatización de flujos de trabajo y un SDK para construir agentes personalizados.

Tomas Reimers, cofundador del desarrollador de revisión de código Graphite, está al mando de Origin dentro de Cursor. Cursor acordó adquirir Graphite en diciembre de 2025 tras identificar la revisión y la fusión segura como los siguientes cuellos de botella creados por la generación de código más rápida. Reimers había construido originalmente Graphite con los cofundadores Merrill Lutsky y Greg Foster como una herramienta interna para mantener a los ingenieros sin bloqueos antes de convertirla en un producto de revisión de código.

En la conferencia Compile de Cursor, Reimers presentó Origin como una nueva plataforma Git para equipos y agentes. La cobertura de la demostración informó de un servicio compatible con Git con APIs orientadas a agentes, soporte para Model Context Protocol, respuestas automatizadas a conflictos de fusión y ejecuciones fallidas de integración continua, e infraestructura diseñada para muchos agentes empujando cambios en paralelo. La demostración de Cursor afirmó un rendimiento de 22.6 commits por segundo en un repositorio, pero Cursor no ha publicado una metodología de benchmark ni resultados en producción para esa cifra.

Ese número describe la ingestión del repositorio, no la calidad del software. Un forge puede aceptar miles de commits de agentes sin establecer si esos cambios son correctos, seguros o convenientes de fusionar. La estrategia de producto más amplia de Cursor atiende esa brecha colocando revisión automatizada y controles de políticas alrededor de los agentes que generan el código.

Origin es un host de Git, no un reemplazo de Git

Origin se entiende mejor como un forge: el servicio alrededor de Git que almacena repositorios y gestiona la colaboración, pull requests, permisos, checks y merges. Git sigue siendo el sistema de control de versiones subyacente. Origin se posiciona frente a la capa de repositorio y colaboración ocupada por GitHub y GitLab.

La distinción importa para la portabilidad. El historial estándar de Git, las ramas y las etiquetas generalmente pueden moverse entre hosts compatibles. Las discusiones de pull requests, los rastreadores de issues, las políticas de acceso, las configuraciones de CI y las integraciones de aplicaciones son específicas del host. Cualquier evaluación seria de Origin dependerá, por tanto, de las herramientas de importación de Cursor, los controles de identidad y la compatibilidad con los pipelines de desarrollo existentes.

Antes del lanzamiento del 11 de agosto, Cursor no había publicado los precios de Origin, la arquitectura de seguridad, los términos de manejo de datos ni las herramientas de migración, y la página pública del producto seguía ofreciendo solo una lista de espera por correo de trabajo. Cursor había dicho alrededor del anuncio de junio que Origin se esperaba para el otoño de 2026, lo que hace que el lanzamiento de agosto sea anterior a su cronograma público inicial.

Lo que un equipo agentico de Cursor puede usar hoy

Origin es una capa dentro de una pila que Cursor ha ensamblado a lo largo de 2026. Los equipos no necesitan Origin para comenzar a ejecutar agentes en paralelo, aunque sus repositorios y pull requests pueden permanecer en un host existente.

Cursor 3, lanzado el 2 de abril, introdujo un espacio de trabajo que pone agentes locales y en la nube en una sola interfaz. Los agentes iniciados desde el escritorio, la web, el móvil, Slack, GitHub o Linear pueden aparecer juntos, y una tarea puede moverse entre una máquina local y la nube de Cursor. Los worktrees aíslan cambios simultáneos en ramas separadas, mientras que los espacios de trabajo con múltiples raíces permiten que un agente modifique varios repositorios en una sola sesión.

Cursor también soporta subagentes asincrónicos. Un agente padre puede dividir trabajo en tareas más estrechas con contexto, modelos y permisos de herramientas separados. El flujo de trabajo /multitask puede romper una petición más grande en corrientes paralelas, mientras que subagentes anidados pueden delegar más allá. Esta es la implementación más cercana actual de Cursor a un equipo de agentes: un humano o agente padre descompone el trabajo, agentes especializados lo ejecutan y sus salidas regresan para integración y revisión.

Los agentes en la nube se ejecutan en máquinas virtuales dedicadas con sus propias dependencias y acceso a red. Pueden continuar después de que un desarrollador cierre una laptop y devolver artefactos como logs, capturas de pantalla y demostraciones. Eso cambia el trabajo del operador de vigilar cada llamada a una herramienta a especificar la tarea, definir criterios de aceptación y verificar el resultado.

Truell escribió en febrero que el 35% de los pull requests fusionados dentro de Cursor fueron creados por agentes que corrían de forma autónoma en máquinas virtuales en la nube. Esa es una métrica interna reportada por Cursor, pero explica el momento detrás de Origin: Cursor ya está experimentando los problemas de revisión, entorno y coordinación que aparecen cuando la salida de agentes se vuelve una porción significativa del trabajo en producción.

Reglas, automatizaciones y agentes personalizados forman la capa operativa

El producto para equipos de Cursor convierte hábitos individuales de prompting en infraestructura compartida. El plan Teams actual comienza en $40 por usuario al mes e incluye un marketplace privado de equipo para distribuir reglas, skills y plugins. Los equipos pueden codificar convenciones de repositorio, requisitos de pruebas y flujos de trabajo recurrentes en lugar de pedirle a cada ingeniero que configure agentes de forma independiente.

Las Automations crean agentes siempre activos activados por calendarios o eventos de servicios como GitHub, Linear, Slack, PagerDuty y webhooks. Cada ejecución inicia una sandbox en la nube y sigue las instrucciones configuradas, las opciones de modelo y las conexiones MCP. Trabajos apropiados incluyen triage de reportes de bugs, investigar builds fallidos, actualizar dependencias y preparar pull requests rutinarios.

Para flujos de trabajo que necesitan lógica de aplicación, el beta público del Cursor SDK expone el mismo runtime de agente usado en los productos de Cursor para escritorio, CLI y web. Los desarrolladores pueden lanzar agentes locales o en la nube desde TypeScript o Python, transmitir su trabajo e incorporarlos en sistemas de CI o herramientas internas. Las actualizaciones de junio añadieron herramientas personalizadas, almacenes de estado configurables, subagentes anidados y una capa de auto-revisión que puede retener llamadas a herramientas riesgosas para aprobación.

La capa de revisión es Bugbot, el revisor de pull requests de Cursor con precio por uso. Los equipos pueden establecer el esfuerzo de revisión y conectar contexto adicional a través de MCP. Cursor dice que Bugbot puede aprender reglas de revisión a partir de reacciones y comentarios humanos, creando un bucle de retroalimentación entre los estándares de un equipo y futuras revisiones automatizadas. Esas cifras de rendimiento y resolución siguen siendo mediciones propias de Cursor.

La gobernanza se vuelve el factor limitante

Ejecutar varios agentes es sencillo. Darles credenciales de producción, acceso a la red y permiso para fusionar código es la decisión organizacional más difícil.

Cursor Enterprise ahora soporta organizaciones, equipos y grupos con distintos presupuestos, modelos aprobados y permisos de agentes. Los administradores pueden separar usuarios experimentales de equipos de producción, restringir acceso a repositorios y MCP, aplicar políticas de red, controlar la ejecución de comandos e inspeccionar el uso. El modo de auto-revisión de Cursor también enruta operaciones inciertas de shell, MCP y fetch a través de un clasificador antes de permitir la ejecución o solicitar aprobación humana.

Un equipo agentico funcional necesita, por tanto, límites explícitos: ramas o worktrees aislados, entornos reproducibles, criterios de aceptación por escrito, credenciales restringidas, pruebas deterministas y propiedad humana de las fusiones finales. Los agentes en paralelo aumentan la producción y también pueden multiplicar pruebas inestables, cambios conflictivos y pull requests innecesarios.

Origin es la respuesta propuesta por Cursor a la presión de coordinación creada por esa producción. Su valor estratégico dependerá de la calidad de la revisión, la aplicación de políticas y el soporte de migración más que del simple rendimiento de commits. El lanzamiento del 11 de agosto traslada la pregunta inmediata de cuándo llegará Origin a si Cursor puede proporcionar los detalles operativos y la compatibilidad que los equipos de ingeniería necesitan antes de mover su sistema de registro.