No todas las tareas de código caben en el tiempo que tardas en tomar un café. Background Agents delega el trabajo largo a una máquina remota y te avisa cuando termina.
Composer y Chat en Cursor son síncronos: escribes una instrucción, el agente edita el buffer, tú revisas mientras esperas. Eso funciona bien para refactors de minutos, pero se vuelve incómodo para tareas que toman más tiempo — migrar un módulo grande, correr una suite de tests larga entre iteraciones, o explorar varias estrategias antes de converger en una. Background Agents saca esa tarea del hilo síncrono: la ejecuta en una máquina remota (una VM efímera con una copia del repo), sigues trabajando en tu editor local mientras corre, y recibes una notificación con el resultado — normalmente un branch o un diff listo para revisar.
Al lanzar una tarea en background, Cursor clona tu repositorio en un contenedor remoto, instala dependencias según la configuración del proyecto, y le da al agente acceso a terminal, sistema de archivos y la capacidad de correr comandos (tests, linters, builds) igual que si estuviera en tu máquina — pero de forma aislada, sin tocar tu working directory local. Esto es clave: puedes seguir editando otro archivo o incluso lanzar una segunda tarea en paralelo sin que choquen entre sí.
Tareas con un criterio de éxito verificable automáticamente (tests que pasan, build que compila, linter sin errores) son las que mejor encajan, porque el agente puede iterar solo sin que tú intervengas en cada paso — corre el test, ve el error, ajusta, repite, hasta que pasa o agota los intentos. Tareas ambiguas donde el criterio de "está bien" depende de juicio humano (¿esta refactorización de arquitectura se ve bien?) rinden menos en background, porque el agente no tiene forma de autoevaluarse sin ti — mejor usarlas en Composer, donde revisas en cada paso.
El entorno remoto no tiene automáticamente acceso a todos los secretos ni servicios externos que sí tiene tu máquina local (bases de datos de desarrollo, APIs internas con IP allowlisted) — si la tarea depende de eso, hay que configurar el entorno explícitamente o la tarea fallará en el paso de verificación. También consume cuota de forma distinta a Composer: una tarea larga con muchas iteraciones internas (correr tests, fallar, ajustar, repetir) puede consumir más que la misma tarea supervisada paso a paso, porque cada iteración interna del agente cuenta.
Equipos que lo adoptan bien tienden a usarlo para el "trabajo de fondo" del backlog — actualizar dependencias, aplicar un mismo patrón de refactor across el repo, generar tests faltantes para módulos con baja cobertura — mientras reservan Composer y Chat síncronos para el trabajo que requiere su criterio activo en cada paso. La combinación de ambos, no uno reemplazando al otro, es lo que da el mayor rendimiento en la práctica.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel