Ejecutar workspaces agénticos en la nube a escala

Ejecutar un agente de workspace en la nube es un truco de productividad. Ejecutar diez de forma confiable es una disciplina de ingeniería. La diferencia entre ambas cosas no es la capacidad de cómputo, sino la reproducibilidad del entorno, la gestión cuidadosa de secretos, la autenticación en repositorios privados, la asignación del presupuesto de límites de tasa y un pipeline de revisión que no colapse ante el volumen de trabajo de los agentes.

Esta es la Parte 3 de la serie Agentic Workspaces. El artículo principal decía que el ciclo diario es «el mismo ciclo, con un harness diferente», y es cierto. Pero configurar el harness para un agente y hacerlo para una flota no es el mismo problema. Este artículo trata sobre cómo aprovisionar, paralelizar, reforzar y observar ese ciclo a escala de flota.

El July 8, 2026 revisé la documentación y los registros de cambios oficiales de Cursor Cloud Agent, así como la documentación de Claude Code on the web, Routines y Ultrareview. Las capacidades de los productos están respaldadas por fuentes y fechadas; varias funciones están en vista previa de investigación y se identifican como tales. Las recomendaciones arquitectónicas se señalan como inferencia editorial: verifica el comportamiento actual antes de depender de él, porque ambas plataformas evolucionan rápido.

Audiencia: ingenieros y arquitectos que están implementando flotas de agentes en la nube, con una perspectiva sobre el ritmo de entrega para PMs y scrum masters.

Resumen

• La restricción principal a escala es la capacidad humana de revisión, no los tokens ni el cómputo (criterio editorial). Diseña tu límite de WIP en función de las horas disponibles para revisar, no de cuántas sesiones puedes costear.
• El entorno como código es el requisito fundamental. Cursor usa .cursor/environment.json (+ Dockerfile); Claude Code on the web usa scripts de configuración y hooks SessionStart con snapshots en caché.
• Los secretos son la principal fuente de fallas en una flota (inferencia). Limita su alcance al mínimo, inyéctalos mediante el almacén de secretos de la plataforma y nunca incorpores tokens en los contenedores ni los incluyas en commits.
• Los submódulos privados necesitan autenticación explícita. Cursor ahora ofrece entornos nativos multi-repo (disponibilidad general May 2026); las configuraciones basadas en submódulos todavía necesitan un token de alcance limitado + git insteadOf en un paso de configuración.
• Distribuye el trabajo con un agente por rama, repositorio o tarea, actívalos desde chat, PR, programación o API, y coloca siempre la URL de la sesión en el cuerpo del PR para garantizar la trazabilidad.
• Las ejecuciones de alcance acotado (sincronización + auditoría, sin escribir código) se pueden automatizar de forma segura sin pasar por la revisión; las ejecuciones que implementan cambios completos no.

Qué aprenderás aquí

• Cómo clona y aprovisiona realmente un agente en la nube tu workspace, tanto en Cursor como en Claude Code
• Cómo hacer que los entornos sean reproducibles mediante configuración como código y snapshots en caché
• Una taxonomía para limitar el alcance de los secretos y el patrón de autenticación de submódulos privados para VMs en la nube
• Tres topologías de distribución y cómo elegir entre ellas
• Cómo ejecutar de forma segura automatizaciones de alcance acotado, programadas o activadas por eventos
• Observabilidad, límites de costos y el modelo de capacidad de revisión que necesitan los PMs

1. El problema de la flota: un clon frente a muchos

Una sesión local hereda tu máquina: herramientas instaladas, dependencias en caché, tus dotfiles y tus credenciales. Un agente en la nube no hereda nada más que el repositorio. Cada supuesto que tu ciclo hace sobre el entorno debe estar codificado en algún lugar que la VM pueda leer.

Con un agente, eso es una pequeña comodidad. Con diez agentes ejecutándose en paralelo, se convierte en un requisito estricto, porque:

• cada clon debe aprovisionarse de forma idéntica o los resultados divergen
• cada uno necesita credenciales sin filtrarlas
• comparten límites de tasa y un presupuesto de gasto
• su producción llega a una misma cola de revisión humana

La ganancia del paralelismo es real, pero viene con un costo de reproducibilidad del entorno. El resto de este artículo explica cómo pagar ese costo una sola vez, en código.

2. Clonar el workspace: qué sucede en la VM

Cursor Cloud Agents hacen checkout de una rama, aíslan el trabajo en ella y envían los cambios a tu repositorio remoto; el entorno se resuelve en este orden: environment.json → configuración personal guardada → configuración de equipo guardada (configuración de Cursor Cloud Agent).

Claude Code on the web aprovisiona una VM nueva por sesión (documentada con 4 vCPU / 16 GB / 30 GB), autentica el repositorio mediante una GitHub App o un flujo /web-setup y no conserva tu configuración de usuario ~/.claude (Claude Code on the web). Todo lo específico del proyecto debe vivir en el repositorio.

El problema con los submódulos: históricamente, los agentes en la nube clonan sin recorrer los submódulos de forma recursiva por defecto. En Cursor, la solución preferida hoy son los entornos nativos multi-repo (disponibilidad general May 13, 2026). Para workspaces basados en submódulos —y en plataformas sin una función nativa multi-repo— todavía debes autenticarte y recorrerlos de forma explícita (ver §4).

3. Reproducibilidad del entorno

Cursor: environment.json (+ Dockerfile)

{
  "build": { "dockerfile": "Dockerfile", "context": ".." },
  "install": "npm install && pip install -r requirements.txt"
}

Cursor solo reconstruye las capas de Docker que cambiaron (el artículo de May 2026 señala que la caché de capas acelera considerablemente las reconstrucciones), crea un snapshot del entorno después de la instalación y, si el snapshot falla o caduca, recurre a la imagen base con una advertencia visible en lugar de fallar por completo (blog de Cursor: entornos de desarrollo para agentes en la nube).

Claude Code: script de configuración + hook SessionStart

{
  "hooks": {
    "SessionStart": [
      { "matcher": "startup|resume",
        "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/scripts/install.sh" } ] }
    ]
  }
}

#!/bin/bash
# scripts/install.sh — only do heavy setup in the cloud
[ "$CLAUDE_CODE_REMOTE" != "true" ] && exit 0
npm install
pip install -r requirements.txt

CLAUDE_CODE_REMOTE=true se establece automáticamente en las sesiones en la nube (según la documentación de Claude Code on the web; verifica la variable exacta en la documentación actual). Prefiere los scripts de configuración (que Claude Code almacena en caché entre ejecuciones; consulta la documentación actual para conocer el TTL) para instalaciones grandes; usa hooks SessionStart para configuraciones ligeras por sesión que también deban ejecutarse localmente.

El ciclo de vida del snapshot

First run                          Subsequent runs
─────────                          ───────────────
clone repo                         clone repo
run setup / Dockerfile             restore cached snapshot
take snapshot ───────────────────► load deps from disk (fast)
agent starts                       agent starts

on failure/expiry: base-image fallback + warning + install re-runs

AGENTS.md específico para la nube

Como una VM en la nube solo hereda el repositorio (§1), cada supuesto sobre el entorno que necesita el agente debe estar documentado donde pueda leerlo. Una sección de AGENTS.md específica para la nube es el lugar para esos supuestos:

## Cloud environment notes
- Node 20 (nvm), Python 3.12, pnpm preferred
- Run `pnpm install` before any test command
- Integration tests need DATABASE_URL (injected as a secret)
- apps/api and apps/web are both present; open one PR per repo; push api before web

4. Secretos y autenticación de submódulos privados

Limita el alcance de todo al mínimo. Cursor ofrece secretos de workspace/equipo, secretos con alcance de entorno, secretos de compilación con alcance de Dockerfile y la posibilidad de asumir un rol de AWS IAM (documentación de configuración). Claude Code on the web almacena variables de entorno en la configuración del entorno y, a July 2026, no tiene un almacén de secretos dedicado; por eso, mantén esos valores al mínimo, rótalos y prefiere el proxy de GitHub para autenticar el repositorio en lugar de incorporar tokens.

Para los submódulos privados en una VM en la nube, cuando no se usa un entorno nativo multi-repo, este es el complemento en tiempo de ejecución de los fragmentos de checkout de CI de la Parte 2:

#!/bin/bash
# setup step — token comes from the platform secrets store, never committed
git config --global url."https://${GH_ORG_PAT}@github.com/".insteadOf "https://github.com/"
git submodule update --init --recursive

Dos hechos operativos que suelen causar problemas a los equipos:

• Los valores de los secretos suelen ocultarse en la salida de las herramientas por seguridad. No imprimas un secreto para depurar; imprime solo una huella segura (por ejemplo, los últimos 4 caracteres) para confirmar que se inyectó.
• El token predeterminado de CI tiene alcance para un solo repositorio. Para varios submódulos privados, usa un PAT de permisos granulares o un token de GitHub App con alcance limitado exactamente a esos repositorios (consulta la Parte 2 para ver los fragmentos de checkout).

5. Topología de distribución

                ┌─────────────────────────────────────────┐
                │  Trigger: sprint start / API / PR comment │
                └───────────────┬───────────────────────────┘
                                │
                ┌───────────────▼───────────────────────────┐
                │  Workspace clone + environment snapshot    │
                │  (skills, knowledge, AGENTS.md baked in)   │
                └──────────┬───────────┬───────────┬─────────┘
                           │           │           │
                 ┌─────────▼──┐ ┌──────▼──────┐ ┌─▼──────────┐
                 │ Agent A    │ │ Agent B     │ │ Agent C    │
                 │ feat/1 api │ │ fix/2 api   │ │ docs/ web  │
                 └──────┬─────┘ └──────┬──────┘ └────┬───────┘
                        └──────────┬───┘             │
                                   ▼                 ▼
                    ┌──────────────────────────────────────┐
                    │  PRs → human review queue             │
                    │  session URL in each PR body (audit)  │
                    └──────────────────────────────────────┘

 rate-limit ceiling ───────── review-capacity ceiling (the real WIP limit) ──►

Tres patrones:

• Un agente por rama: funcionalidades o correcciones paralelas en el mismo repositorio. Vigila los cambios en la rama base mientras se ejecutan las sesiones.
• Un agente por repositorio: una funcionalidad que abarca varios repositorios; un PR por submódulo; exige un orden de merge (API antes que UI).
• Un agente por tarea: distribución granular para tareas independientes; mayor rendimiento, pero también mayor carga de revisión.

Activadores: Cursor se activa desde Slack, comentarios @cursor en GitHub, Linear, una API, iOS y el panel web. Claude Code transfiere el trabajo desde la CLI con --cloud y se ejecuta sin supervisión mediante Routines (programación, API, evento de GitHub), una capacidad en vista previa de investigación a July 2026 (Routines).

6. Ejecuciones de alcance acotado, programadas o activadas por eventos

La automatización más segura es de solo lectura: sincroniza submódulos y audita conocimiento, genera un informe y no escribe código. Una rutina nocturna de auditoría de conocimiento activada desde CI después de un merge importante:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/<routine_id>/fire \
  -H "Authorization: Bearer <token>" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Recent merges: PR #142 (api), PR #89 (web). Check .knowledge/ for drift."}'

Diseña el prompt según el alcance: una rutina de auditoría informa sobre las desviaciones y, como máximo, crea un PR de conocimiento; no implementa funcionalidades. El equivalente de Cursor son las automatizaciones activadas por chat o PR (@cursor en Slack/GitHub/Linear). Verifica los encabezados beta y los endpoints exactos en la documentación actual: estas API en vista previa cambian.

7. Observabilidad y límites de costos

• Atribución. Claude Code agrega un trailer Claude-Session a los commits y a los cuerpos de los PRs (v2.1.179+), lo que te proporciona una URL de sesión como evidencia de auditoría. Cursor muestra la versión del entorno por ejecución y mantiene un registro de auditoría de los cambios en el entorno.
• Costo. Cursor cobra según las tarifas de la API y exige un límite de gasto; configúralo antes de ejecutar una flota. Claude Code consume el uso de la suscripción y utiliza créditos para los excedentes y para funciones en vista previa como Ultrareview.
• Control de calidad. Ultrareview (vista previa de investigación; confirma la versión y el estado actuales en el registro de cambios de Claude Code) ejecuta una flota de agentes de revisión y ofrece un comando no interactivo claude ultrareview para CI. Si se usa como control previo al merge, reduce la carga humana de revisión trivial; según la documentación, su precio se basa en créditos.
• Interruptores de emergencia. Pausa las rutinas; configura la desactivación administrativa y los topes de gasto de Cursor. Ten una forma de detener todo antes de distribuir el trabajo.

8. Modos de falla a escala de flota

9. Qué necesitan los PMs y scrum masters

Los agentes en la nube pueden producir PRs más rápido de lo que cualquier sprint ha completado tickets. Ese no es el cuello de botella: lo es la capacidad de revisión. Un equipo que revisa 2 PRs/día y ejecuta 20 sesiones acumula 18 diffs sin revisar, lo cual es peor que no ejecutar agentes porque la deuda de revisión se acumula.

Un modelo práctico:

• Establece el límite de WIP de los agentes según reviewer-hours-per-day ÷ avg-review-time-per-PR, no según «cuántas sesiones podemos costear».
• Las rutinas de alcance acotado (solo auditoría, sin escritura) se pueden ejecutar de forma segura sin pasar por la revisión: el resultado es un informe, no un diff.
• La definición de terminado sigue aplicando: un PR de un agente no está terminado hasta que una persona lo apruebe y CI esté en verde. El trailer de sesión es tu evidencia de cumplimiento y trazabilidad.
• Mide el rendimiento de los agentes y el rendimiento de revisión como métricas separadas. Cuando el rendimiento de los agentes supere al de revisión por ~2x durante dos sprints, pausa los nuevos activadores hasta que la revisión se ponga al día.

Lista de preparación

Antes de tu primera ejecución de flota

1. Entorno como código incluido en un commit (environment.json o script de configuración) y probado desde un clon limpio.
2. Autenticación de submódulos privados funcionando mediante un token de alcance limitado o un entorno nativo multi-repo.
3. Límite de gasto / presupuesto de uso establecido.

Antes de la décima 4. Snapshot y caché validados; recurso a la imagen base observado al menos una vez. 5. URL de sesión en el cuerpo de cada PR; trailer de atribución habilitado. 6. Límite de WIP vinculado a la capacidad de revisión y aplicado en la capa de activación.

Antes de automatizar los activadores 7. Prompts de alcance acotado para ejecuciones programadas (solo auditoría/sincronización). 8. Interruptor de emergencia probado (pausar rutinas, desactivación administrativa). 9. Comprobación de conflictos de merge / cambios en la rama base en la rutina de revisión.

Conclusión

El patrón de workspace es independiente del harness, pero la escala deja al descubierto todo lo que este ocultaba: supuestos sobre el entorno, alcance de las credenciales y capacidad finita de revisión humana. Codifica el entorno una sola vez, limita estrictamente el alcance de los secretos, distribuye el trabajo de forma deliberada y trata la capacidad de revisión —no el cómputo— como el verdadero límite de WIP. Así, una flota de agentes de workspace se convierte en un recurso valioso en lugar de una acumulación de diffs sin revisar.

En la siguiente entrega de la serie: las herramientas MCP que permiten a estos agentes rastrear, clasificar y depurar sistemas reales.

Fuentes

Fuentes primarias consultadas el July 8, 2026:

• Descripción general de Cursor Cloud Agents — cursor.com/docs/cloud-agent
• Configuración de Cursor Cloud Agent (entornos, secretos, multi-repo) — cursor.com/docs/cloud-agent/setup
• Mejores prácticas de Cursor Cloud Agent — cursor.com/docs/cloud-agent/best-practices
• Blog de Cursor: entornos de desarrollo para agentes en la nube (May 13, 2026) — cursor.com/blog/cloud-agent-development-environments
• Claude Code on the web — code.claude.com/docs/en/claude-code-on-the-web
• Claude Code Routines (vista previa de investigación) — code.claude.com/docs/en/routines
• Claude Code Ultrareview (vista previa de investigación) — code.claude.com/docs/en/ultrareview

Inferencia editorial (no son afirmaciones de los proveedores): la capacidad de revisión como restricción principal del WIP; la configuración incorrecta de secretos como uno de los principales modos de falla de una flota; la distinción entre multi-repo nativo (Cursor) y submódulo + token (en otras plataformas); las rutinas de alcance acotado como herramienta básica de mantenimiento. Las funciones en vista previa (Routines, Ultrareview) y la situación de «todavía sin almacén de secretos» pueden cambiar con el tiempo: vuelve a verificarlas.

Artículos relacionados de esta serie:

• Parte 1: Workspaces agénticos: submódulos, skills, conocimiento y entrega guiada por especificaciones
• Parte 2: Los submódulos como contrato de dependencias
• Parte 4: Rastrear, clasificar, depurar: herramientas MCP para workspaces agénticos
• Relacionado: Diseño de subagentes en la nube
• Relacionado: Cómo crear PRs desde tu teléfono con Claude Code