Plano de arquitectura de Claude Code Ultracode para Cursor y agentes personalizados

Resumen

• Claude Code Ultracode no es un modelo nuevo ni un nivel de esfuerzo de la API. Es una configuración de sesión que combina el esfuerzo de modelo xhigh con la orquestación automática de Dynamic Workflows para tareas sustanciales.
• Lo importante no es la palabra ultracode, sino el ciclo: decidir si se justifica la orquestación, planificar un grafo de tareas, distribuir el trabajo, verificar de forma independiente, converger y devolver un único resultado.
• A fecha de July 15, 2026, Cursor documenta parámetros de esfuerzo del modelo, subagentes automáticos y personalizados, Agent Skills, hooks, worktrees y un SDK. Mi evaluación es que estas primitivas cubren la mayor parte del ciclo funcional, pero no el runtime de workflows de Claude Code.
• Cursor no documenta actualmente un equivalente directo al runtime de workflows JavaScript generados de Claude Code, donde la orquestación y el estado intermedio residen fuera de la conversación y una ejecución puede inspeccionarse y reproducirse como código.
• La aproximación nativa más cercana en Cursor es un coordinador de alto esfuerzo con subagentes especializados en planificación y verificación, más una skill que define cuándo distribuir el trabajo.
• Para equipos que requieren reproducción explícita, presupuestos, checkpoints o programación de tareas, la arquitectura más controlable es un orquestador construido con el SDK de Cursor u otro SDK de agentes.
• No habilites este patrón para cada edición. Los agentes paralelos multiplican el contexto, los tokens, los posibles conflictos y el trabajo de revisión. Úsalo para auditorías, migraciones, investigaciones amplias y cambios con líneas de trabajo realmente independientes.

Qué aprenderás aquí

• Qué hace realmente la configuración Ultracode de Anthropic
• Qué partes corresponden al comportamiento del modelo y cuáles al harness de agentes
• Qué tan cerca pueden llegar los subagentes nativos de Cursor
• Cómo crear una política similar a Ultracode con agentes y skills de Cursor
• Cómo construir un ciclo de orquestación independiente del proveedor
• Dónde encajan los worktrees, hooks, checkpoints y la verificación independiente
• Cómo evaluar si la orquestación supera a una ejecución normal con un solo agente

Ultracode es una función del harness, no un modelo mágico

El anuncio de Anthropic del May 28, 2026 indica que Dynamic Workflows ya está disponible de forma general. Su documentación de workflows define Ultracode con precisión:

Ultracode combina el esfuerzo de razonamiento xhigh con la orquestación automática de workflows.

Esa definición tiene dos capas:

1. Capa del modelo: enviar a un modelo Claude compatible una configuración de esfuerzo xhigh.
2. Capa del harness: dejar que Claude Code decida cuándo una solicitud es lo suficientemente sustancial para convertirse en un Dynamic Workflow.

La segunda capa es la interesante.

Un Dynamic Workflow es un script de orquestación JavaScript escrito para la tarea. Claude Code ejecuta ese script fuera de la conversación principal. El script puede crear workers, ejecutar un pipeline sobre una lista de elementos, conservar resultados intermedios en variables y devolver únicamente el resultado coordinado a la conversación.

La documentación actual de workflows de Anthropic indica que el runtime permite hasta 16 agentes simultáneos y 1,000 agentes en una ejecución, según los recursos locales disponibles. Puede pausar y reanudar la ejecución dentro de la misma sesión de Claude Code, reutilizando los resultados completados.

Puedes activar este comportamiento de dos maneras:

• Incluye ultracode en un prompt, o solicita un workflow en lenguaje natural, para crear un workflow para esa tarea.
• Ejecuta /effort ultracode para que Claude Code tome esa decisión para las tareas sustanciales durante toda la sesión actual.

Iniciar Claude Code con claude --effort ultracode requiere Claude Code v2.1.203 o posterior. La función Dynamic Workflow en sí requiere v2.1.154 o posterior.

La distinción de sesión importa. Ultracode solo se aplica a la sesión actual y se restablece al iniciar una nueva sesión de Claude Code. Anthropic advierte que cada solicitud puede usar más tokens y tardar más, y recomienda volver a /effort high para el trabajo rutinario.

Los workflows también deben estar disponibles y habilitados. En Pro, habilita Dynamic Workflows en /config; Anthropic documenta que están habilitados de forma predeterminada en Max, Team, Enterprise y con acceso a la API. Cuando los workflows no están disponibles, la documentación de configuración de modelos indica que --effort ultracode recurre al esfuerzo xhigh sin la capa de orquestación.

La arquitectura portable

Si quitamos los nombres de productos, un sistema similar a Ultracode tiene siete partes:

User task
   |
   v
[1. Trigger gate]
   | routine ----------------------> single agent
   |
   | substantive
   v
[2. High-effort planner]
   |
   v
[3. Task graph + success criteria]
   |
   +----> [4a. Worker A in isolation] ----+
   +----> [4b. Worker B in isolation] ----+--> [5. Reducer]
   +----> [4c. Worker C in isolation] ----+         |
                                                    v
                                        [6. Verifier / refuter]
                                                    |
                                  failed <----------+----------> passed
                                     |                            |
                                     v                            v
                              bounded repair loop          [7. Final result]

Aquí, el reductor combina las salidas de los workers en un único resultado candidato. El refutador parte de forma independiente e intenta refutar ese resultado en lugar de limitarse a pulirlo.

Los roles y sus responsables deben ser explícitos:

Mantén separados tres controles:

• El esfuerzo del modelo controla la profundidad del razonamiento en una invocación del modelo.
• La cantidad de workers controla la amplitud y el paralelismo.
• El presupuesto de ejecución controla el total de tokens, tiempo, reintentos y uso de herramientas.

Aumentar uno no reemplaza a los demás.

Las decisiones de ingeniería clave son:

1. Activación: ¿Cuándo es insuficiente un solo agente?
2. Planificación: ¿Puede el coordinador producir un grafo de tareas que tenga en cuenta las dependencias?
3. Aislamiento: ¿Pueden los workers evitar editar los mismos archivos?
4. Estado: ¿Dónde residen los planes y los resultados intermedios?
5. Verificación: ¿Un agente con contexto nuevo cuestiona el resultado?
6. Convergencia: ¿Qué provoca otra iteración y qué detiene el ciclo?
7. Presupuesto: ¿Cuántos agentes, tokens, reintentos y minutos se permiten?

Por eso, copiar únicamente un prompt de sistema no reproduce Ultracode. Un prompt puede fomentar la delegación. Por sí solo no puede proporcionar estado duradero del workflow, controles de concurrencia, espacios de trabajo aislados ni capacidad de reanudación.

¿Qué tan cerca puede llegar Cursor hoy?

A fecha de July 15, 2026, Cursor documenta estas primitivas relevantes para una aproximación de comportamiento:

• Cursor 2.4, lanzado el January 22, 2026, introdujo la base actual de subagentes y Agent Skills.
• Cursor Agent puede delegar automáticamente trabajo complejo a subagentes cuando considera apropiada la delegación.
• Los subagentes personalizados residen en .cursor/agents/ y pueden tener sus propios prompts, modelos, configuración de solo lectura y comportamiento en segundo plano.
• Los subagentes usan ventanas de contexto aisladas y pueden ejecutarse en paralelo.
• La configuración del modelo admite parámetros específicos de cada modelo, como el esfuerzo de razonamiento. Cursor recomienda consultar los identificadores y valores de parámetros válidos con Cursor.models.list(), porque varían según el modelo.
• Las Agent Skills en .cursor/skills/ pueden definir un procedimiento de orquestación reutilizable y una descripción que ayude a Agent a decidir cuándo cargarlo.
• Los hooks pueden observar o controlar los eventos de inicio y finalización de subagentes, activar acciones posteriores acotadas y hacer cumplir políticas de herramientas.
• Los worktrees aíslan los cambios cuando los agentes necesitan escribir en paralelo.
• El SDK de Cursor ofrece agentes duraderos, ejecuciones por prompt, streaming, cancelación, uso de tokens, subagentes con nombre, herramientas personalizadas, sandboxes locales y máquinas virtuales en la nube.

Es una base útil, pero no ofrece una equivalencia exacta de funciones. La siguiente correspondencia es mi evaluación, no un benchmark del proveedor:

Mi conclusión: la configuración de Cursor puede crear una aproximación de comportamiento dirigida por el modelo dentro de una ejecución, pero no puede reproducir el runtime de workflows de Claude Code solo mediante configuración.

Elige la opción más sencilla que te proporcione los controles que necesitas:

Decide si necesitas orquestación antes de elegir una opción

El filtro de activación debe ejecutarse antes que el planificador o cualquier worker. Algunas señales positivas útiles son:

• Al menos dos líneas de trabajo independientes
• Exploración de muchos módulos, servicios, documentos o repositorios
• Una migración que se puede dividir por archivo, paquete, endpoint o cliente
• Un resultado que justifica una revisión crítica independiente o una comprobación cruzada de evidencias
• Trabajo que probablemente exceda una ventana de contexto

Las señales negativas importan tanto como las positivas:

• Un archivo pequeño o un cambio evidente
• Una tarea secuencial con mucho estado compartido
• Varios workers editarían la misma abstracción central
• La capacidad de revisión humana ya es el cuello de botella

Un filtro útil devuelve evidencia estructurada en lugar de solo un nivel de confianza:

{
  "substantive": true,
  "reasons": [
    "three independent audit surfaces",
    "findings require adversarial verification"
  ],
  "estimatedWorkers": 4,
  "writeConflictRisk": "low",
  "budgetClass": "medium"
}

Haz cumplir fuera del prompt los máximos de workers, los límites de tokens y tiempo transcurrido, las herramientas permitidas y las iteraciones de reparación. Las descripciones de las skills pueden mejorar su activación, pero las skills no garantizan su invocación ni mejores resultados.

Invariantes no negociables

1. Comienza en modo de solo lectura. Prefiere la exploración paralela antes de editar para reducir la exposición a conflictos de escritura.
2. Aísla a cada agente que escriba. Un alcance de escritura declarado es un metadato de planificación, no un mecanismo de control. Usa worktrees o ramas en la nube separados y valida las escrituras reales.
3. Detente ante dependencias faltantes. Nunca programes una etapa dependiente después de que falle un worker del que depende.
4. Verifica desde un contexto nuevo. Esto reduce el acoplamiento por contexto compartido; es una justificación de diseño, no una garantía de corrección.
5. Acota cada ciclo. Establece límites de workers, tokens, tiempo, reintentos y reparaciones antes de iniciar.
6. Conserva una instancia de aprobación humana. Exige aprobación para migraciones destructivas, cambios en producción, decisiones de seguridad o merges automatizados de gran alcance.

Una política inicial conservadora podría ser:

max concurrent workers: 4
max total workers: 12
max repair iterations: 2
max wall time: 30 minutes
max token budget: team-defined

Esos son límites de ejemplo, no valores predeterminados universales. Las cifras de Anthropic de 16 simultáneos y 1,000 en total son límites máximos del producto, no objetivos. Para flotas más grandes, consulta Cómo ejecutar más de 300 subagentes.

Aislamiento del runtime

Los hooks de Cursor sensibles para la seguridad deben usar failClosed: true; de lo contrario, los hooks de comando permiten continuar ante fallas de forma predeterminada. Las ejecuciones locales del SDK no usan sandbox de forma predeterminada. En las ejecuciones locales del SDK, habilitar el sandbox deniega el acceso de red saliente desde comandos de shell y procesos creados por ellos, a menos que los hosts estén autorizados. Controla el acceso a Fetch y MCP por separado mediante hooks y políticas de herramientas.

Entrada no confiable y credenciales

La revisión automática no es una frontera de seguridad. Trata el texto del repositorio, los tickets y el contenido obtenido como entradas no confiables; limita las credenciales de cada worker; y haz cumplir las rutas de escritura fuera de los prompts del modelo. Consulta Generación segura de código con agentes para conocer el modelo de amenazas más amplio.

Opción 1: Una aproximación basada solo en un prompt

La versión más rápida es una instrucción reutilizable:

For each request, first classify it as routine or substantive.

A substantive task has at least one of these properties:
- broad discovery across many files or services
- two or more independent work streams
- a migration or repetitive transformation
- a high-consequence result that needs an independent challenge
- evidence that must be cross-checked

For routine work, use the main agent.

For substantive work:
1. Define measurable success criteria.
2. Produce a dependency-aware plan.
3. Delegate independent discovery tasks in parallel.
4. Isolate any overlapping write tasks.
5. Use a fresh verifier to challenge the combined result.
6. Repair only verified failures, with at most two iterations.
7. Report tests, unresolved risks, and total delegated work.

Esto orienta al agente hacia el comportamiento deseado, pero ofrece garantías débiles. El modelo sigue decidiendo qué tan literalmente seguir el procedimiento, los resultados intermedios siguen pasando por el contexto de la conversación y no hay un controlador estricto de concurrencia o presupuesto.

Úsalo para probar la idea, no como diseño final de la plataforma. Para entender la diferencia entre una instrucción puntual y un sistema reutilizable, consulta Cuándo basta un prompt.

Opción 2: Reproducir la política con subagentes y skills de Cursor

Los subagentes personalizados de Cursor son archivos Markdown. Un planificador puede usar un modelo de alto esfuerzo y permanecer en modo de solo lectura:

---
name: workflow-planner
description: Use proactively for broad, multi-stage, high-risk, or parallelizable engineering tasks.
model: claude-opus-4-8[effort=high]
readonly: true
---

Turn the request into a dependency-aware task graph.

Return:
- success criteria
- independent read-only discovery tasks
- write tasks and their expected file ownership
- dependencies between tasks
- verification commands
- stop conditions and unresolved risks

Luego agrega un verificador:

---
name: workflow-verifier
description: Use after substantive changes to independently inspect and challenge the result.
model: inherit
readonly: true
---

Start from the task and success criteria, not from trust in the implementation.
Inspect the diff and supplied test output, look for missing cases, and try to
refute the claimed result. Report PASS, FAIL, or UNVERIFIED with concrete
evidence. List any commands that a separate test runner still needs to execute.

Por último, agrega una Agent Skill cuya descripción identifique el criterio de activación:

---
name: substantive-task-orchestrator
description: Use for broad, multi-stage, parallelizable, migration, audit, or high-consequence engineering tasks that need independent verification.
---

1. Decide whether normal single-agent work is sufficient.
2. If it is, continue normally and do not delegate.
3. Otherwise invoke workflow-planner.
4. Run independent read-only tasks in parallel.
5. Never run overlapping writers in one checkout. Start isolated worktrees or
   cloud branches first; otherwise execute write tasks sequentially.
6. Combine results against the original success criteria.
7. Invoke workflow-verifier with fresh context.
8. Run at most two repair-and-verify iterations.
9. Stop on budget exhaustion and report incomplete work honestly.

Esta configuración le proporciona al agente principal de Cursor una política general similar. También mantiene los roles versionados junto con el repositorio. El ejemplo fija high porque ese valor está documentado para esta configuración de modelo de Cursor; consulta los parámetros disponibles del modelo antes de seleccionar xhigh.

También debe quedar claro quién es responsable de la implementación. En la configuración nativa más sencilla de Cursor, el agente principal es el único que escribe y ejecuta las tareas de escritura secuencialmente. Si quieres agentes que escriban de forma concurrente, un operador o planificador de ejecución externo debe iniciar cada tarea en un worktree de Cursor o una rama en la nube separados antes de editar. La configuración de agentes y skills por sí sola no crea ese aislamiento del sistema de archivos.

Hay tres advertencias:

1. Una descripción sólida favorece la invocación automática, pero no crea un interruptor de sesión determinista.
2. Un plan de subagentes sigue siendo una orquestación dirigida por el modelo, no un programa generado con estado de ejecución explícito.
3. El verificador de solo lectura inspecciona la evidencia; un ejecutor separado debe realizar las comprobaciones que escriben cachés, artefactos de compilación o snapshots.

Esta opción puede ser suficiente cuando la programación dirigida por el modelo, el estado mantenido en la conversación y un único agente que escribe secuencialmente son aceptables. Si necesitas reproducción gestionada por la aplicación, presupuestos estrictos, checkpoints o programación auditable, traslada la política al código.

El criterio de finalización debería ser:

parent writer finishes in isolated worktree
  -> test runner executes required checks and stores raw output
  -> read-only verifier inspects task, diff, and test evidence
  -> human or policy approver accepts or rejects
  -> merge only after PASS + approval

Opción 3: Construir el orquestador con el SDK de Cursor

Cursor lanzó su SDK en beta pública el April 29, 2026. Ofrece el mismo runtime general de agentes para ejecuciones locales y en la nube, por lo que es una base práctica para construir un orquestador más explícito.

Comienza por identificar un modelo que admita un parámetro similar a xhigh, en lugar de codificar nombres específicos de un proveedor:

import { Agent, Cursor } from "@cursor/sdk";

const models = await Cursor.models.list();
const approvedModelIds = new Set(
  (process.env.APPROVED_DEEP_MODELS ?? "")
    .split(",")
    .map((id) => id.trim())
    .filter(Boolean),
);

if (approvedModelIds.size === 0) {
  throw new Error("Set APPROVED_DEEP_MODELS to an approved model allowlist.");
}

const deepCandidate = models
  .filter((model) => approvedModelIds.has(model.id))
  .map((model) => ({
    model,
    effort: model.parameters?.find((parameter) =>
      parameter.values.some((value) => value.value === "xhigh"),
    ),
  }))
  .find((candidate) => candidate.effort);

if (!deepCandidate) {
  throw new Error("No approved model exposes an xhigh effort parameter.");
}

const deepModel = {
  id: deepCandidate.model.id,
  params: [{ id: deepCandidate.effort!.id, value: "xhigh" }],
};

const coordinator = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: deepModel,
  mode: "plan",
  local: {
    cwd: process.cwd(),
    sandboxOptions: { enabled: true },
    autoReview: true,
  },
  agents: {
    explorer: {
      description: "Read-only repository exploration. Use for independent discovery lanes.",
      prompt: "Gather evidence and return concise file-and-line findings. Do not edit.",
    },
    verifier: {
      description: "Independent verifier. Use after substantive work is complete.",
      prompt: "Try to falsify the result against its success criteria. Do not trust prior claims.",
      model: "inherit",
    },
  },
});

try {
  const run = await coordinator.send(`
  Classify this request as routine or substantive: ${process.argv.slice(2).join(" ")}

  For a routine request, return a concise answer without delegation.
  For a substantive request, define success criteria, delegate independent
  read-only discovery lanes, combine their evidence, and invoke the verifier.
  Do not let multiple agents edit the same checkout in parallel.
  `);

  const result = await run.wait();

  if (result.status !== "finished") {
    throw new Error(result.error?.message ?? `Run ended with ${result.status}`);
  }

  console.log(result.result);
} finally {
  await coordinator[Symbol.asyncDispose]();
}

Este coordinador está diseñado para permanecer en modo de solo lectura, pero los prompts no hacen cumplir ese límite. Deniega Write y las llamadas de shell capaces de escribir mediante un hook preToolUse, monta un espacio de trabajo de solo lectura o ejecuta el proceso sobre un snapshot desechable. El patrón también requiere Node.js 22.13 o posterior, @cursor/sdk, CURSOR_API_KEY, una lista de modelos permitidos APPROVED_DEEP_MODELS, una tarea en la línea de comandos y la liberación explícita de los agentes. Consulta los requisitos del SDK de Cursor. Sigue estando dirigido por el modelo y no implementa el workflow completo de siete etapas.

Para una programación determinista, traslada el grafo de tareas y la máquina de estados a tu aplicación. Lo siguiente es pseudocódigo de arquitectura, no un ejemplo del SDK listo para usar:

type Step = {
  id: string;
  prompt: string;
  dependsOn: string[];
  writes: string[];
};

type WorkflowPlan = {
  substantive: boolean;
  successCriteria: string[];
  steps: Step[];
};

async function runWorkflow(task: string) {
  const plan = await planTask(task); // Parse and validate structured output.

  if (!plan.substantive) {
    return runSingleAgent(task);
  }

  const state = await checkpointStore.create({ task, plan });

  for (const wave of topologicalWaves(plan.steps)) {
    assertDeclaredWriteScopesDoNotOverlap(wave);

    const settled = await Promise.allSettled(
      wave.map((step) =>
        runWorker(step, {
          workspace: createIsolatedWorkspace(step.id),
          readOnly: step.writes.length === 0,
          writeAllowlist: step.writes,
          budget: budget.forWorker(step.id),
        }),
      ),
    );

    await checkpointStore.recordEach(state.id, wave, settled);

    const failedStepIds = wave
      .filter((_, index) => settled[index].status === "rejected")
      .map((step) => step.id);

    if (failedStepIds.length > 0) {
      await checkpointStore.markBlocked(state.id, failedStepIds);
      await cleanupWaveWorkspaces(wave);
      throw new Error(
        `Workflow blocked; dependent waves were not scheduled: ${failedStepIds.join(", ")}`,
      );
    }
  }

  const candidate = await reduceResults(state.id);
  const testResults = await runTestRunner(candidate, {
    workspace: createIsolatedWorkspace("verification"),
  });

  const [verification, refutation] = await Promise.all([
    verify(candidate, plan.successCriteria, testResults),
    refute(candidate, plan.successCriteria, testResults),
  ]);

  if (verification.passed && !refutation.foundBlockingIssue) {
    const approval = await requestApproval({
      task,
      candidate,
      testResults,
      verification,
      refutation,
    });

    if (!approval.approved) {
      throw new Error(`Merge rejected: ${approval.reason}`);
    }

    return mergeAcceptedChanges(candidate, approval);
  }

  return boundedRepairLoop({
    task,
    plan,
    candidate,
    verification,
    refutation,
    maxIterations: 2,
  });
}

La calidad de producción depende de las funciones auxiliares omitidas:

• planTask debe devolver una salida validada contra un esquema.
• topologicalWaves agrupa los pasos sin dependencias entre sí que pueden ejecutarse juntos.
• assertDeclaredWriteScopesDoNotOverlap comprueba el plan, mientras que la política posterior a la ejecución también debe rechazar las escrituras no declaradas.
• createIsolatedWorkspace proporciona a cada worker su propio snapshot o worktree y hace cumplir el modo de solo lectura o una lista de escritura permitida.
• checkpointStore mantiene el estado fuera del contexto del modelo.
• runWorker debe hacer cumplir los presupuestos de la aplicación y cancelar la ejecución del SDK cuando se exceda un límite.
• verify y refute deben comenzar con contextos nuevos.
• boundedRepairLoop debe detenerse, volver a ejecutar las pruebas y la verificación, y exigir aprobación antes de hacer merge de cualquier candidato reparado.
• El administrador de espacios de trabajo debe hacer merge de los cambios aceptados y gestionar conflictos, limpieza y worktrees abandonados.

Para un despliegue operativo, asigna estas responsabilidades:

El almacén de estado debe crear un checkpoint después de cada worker, no solo después de una etapa completa. Una ejecución reanudada debe usar claves de idempotencia para que el trabajo completado no se aplique dos veces.

Cuando el runtime informe el uso de tokens, lee los totales acumulados de run.usage o result.usage; el SDK documenta que cualquiera de los dos puede ser undefined. Mantén los hooks enfocados en políticas, telemetría del ciclo de vida, formato y acciones posteriores acotadas, en lugar de ocultar el planificador de ejecución dentro de scripts de hooks.

Puedes implementar la misma estructura con el SDK de agentes de otro proveedor, una cola más agentes CLI o un harness mínimo como Pi. Los invariantes importan más que el proveedor. Para conocer el patrón más amplio de planificador-worker-verificador, consulta El agente de ingeniería sénior.

Costo: El paralelismo no es inteligencia gratis

La documentación de subagentes de Cursor explica el tradeoff: cada subagente consume su propio contexto y presupuesto de tokens. Cinco subagentes pueden usar aproximadamente cinco veces los tokens de un solo agente.

Un modelo práctico de costos es:

workflow cost =
  trigger decision
  + planner
  + sum(all worker contexts)
  + reducer
  + verifier and refuter
  + repair retries
  + human review

La ejecución paralela puede reducir el tiempo transcurrido y al mismo tiempo aumentar el uso total de tokens. También puede incrementar la carga de revisión humana si los workers generan hallazgos superpuestos o de baja confianza.

Una métrica útil para decidir es el costo por resultado aceptado, no la cantidad de agentes iniciados.

Cómo evaluar tu clon

Compara cuatro modos con el mismo conjunto de tareas:

1. Un solo agente normal
2. Orquestación basada solo en un prompt
3. Subagentes de Cursor más skills
4. Workflow controlado por el SDK

Incluye tareas rutinarias como controles negativos. Un buen filtro de activación debe evitar la orquestación cuando no aporta valor.

Fija el commit del repositorio, la configuración del modelo y su esfuerzo, los límites de workers, la política de herramientas y los criterios de aceptación. Repite cada condición suficientes veces para poner en evidencia el no determinismo, en lugar de comparar una ejecución favorable de cada modo. Para más detalles sobre los tradeoffs de la delegación, consulta Cuándo usar subagentes frente al hilo de chat principal.

Registra:

Registra cada ejecución con una estructura consistente:

type WorkflowEval = {
  taskId: string;
  repeatIndex: number;
  mode: "single" | "prompt" | "cursor-native" | "sdk";
  orchestrated: boolean;
  accepted: boolean;
  triggerWasCorrect: boolean;
  workerCount: number;
  failedWorkers: number;
  retryCount: number;
  writeConflicts: number;
  undeclaredWrites: number;
  policyViolations: number;
  findingsReported?: number;
  truePositiveFindings?: number;
  expectedFindings?: number;
  verifierOpportunities: number;
  verifierCaughtDefects: number;
  totalTokens?: number;
  wallTimeMs: number;
  humanReviewMinutes: number;
};

Comienza con al menos 10 tareas representativas más controles negativos rutinarios, y repite cada combinación de tarea y modo cinco veces. Reporta la mediana de costo y latencia, el rango entre repeticiones y las tasas agregadas en lugar de elegir una ejecución favorable. Establece los umbrales de adopción antes de realizar la evaluación. Por ejemplo:

no high-severity policy violations
zero undeclared writes
trigger precision >= 80%
accepted-task rate > single-agent baseline
cost per accepted result <= team ceiling
human review time does not increase

Estos son criterios de ejemplo, no objetivos universales. La precisión de hallazgos es truePositiveFindings / findingsReported; la cobertura requiere un conjunto etiquetado de expectedFindings; la tasa de detección del verificador es verifierCaughtDefects / verifierOpportunities. Conserva el workflow solo si supera tus criterios predefinidos con suficiente frecuencia para justificar el costo adicional y la complejidad operativa.

Lo que no puedes copiar fielmente

Hay tres límites que conviene reconocer con honestidad.

Primero, Anthropic documenta el comportamiento de Dynamic Workflows, pero no todas las decisiones internas sobre cómo Claude Code reconoce una tarea “sustancial” o escribe un workflow óptimo. Un clon usará tu propio filtro de activación y planificador.

Segundo, seleccionar el mismo modelo y esfuerzo no recrea el mismo harness. El diseño de las herramientas, la composición del contexto, los permisos, la compactación, el estado del runtime y los prompts de los workers afectan los resultados.

Tercero, las fuentes citadas aquí no incluyen evaluaciones independientes comparativas que demuestren que Ultracode supera a enfoques más simples en tareas de programación de gran escala. Anthropic presenta ejemplos sólidos de su producto, pero los equipos aun así deberían realizar evaluaciones locales.

El objetivo no debería ser imitar el producto al píxel. Debería ser un sistema transparente que conserve los invariantes útiles:

deep reasoning when justified
+ explicit decomposition
+ safe parallelism
+ state outside chat
+ independent verification
+ bounded convergence
= an Ultracode-like engineering loop

Recomendación final

Si quieres este comportamiento dentro de Cursor hoy:

1. Comienza con dos subagentes personalizados: un planificador de solo lectura y un verificador escéptico.
2. Agrega una skill de orquestación de alcance acotado con criterios claros para activar tareas sustanciales.
3. Usa parámetros de esfuerzo del modelo solo después de consultar qué admite el modelo seleccionado.
4. Ejecuta la exploración en paralelo, pero aísla en worktrees a los agentes que escriben.
5. Agrega hooks para políticas, telemetría y acciones posteriores acotadas.
6. Construye un orquestador basado en el SDK cuando necesites reproducción gestionada por la aplicación, presupuestos, checkpoints o programación determinista.

Si estás construyendo una plataforma, deja de lado la idea de que un solo prompt extenso es un sistema de orquestación. Construye una máquina de estados pequeña con un grafo de tareas, aislamiento de workers, verificación independiente y condiciones estrictas de parada.

La lección más transferible de Ultracode no es “usa más agentes”.

Es esta:

Saca la coordinación de una conversación frágil y llévala a un workflow inspeccionable y acotado.

Esa es la parte que vale la pena reproducir en Cursor, otro IDE con agentes o un harness propio.

Lecturas relacionadas

• Construye un workflow de programación similar a Ultracode con Agno y AgentOS
• Construye un workflow de programación similar a Ultracode con LangGraph
• Subagentes de Cursor y /simplify de Claude Code: un workflow práctico
• El agente de ingeniería sénior: orquestación de subagentes e ingeniería de ciclos
• Skills frente a agentes predeterminados: ¿realmente mejoran las skills de programación a Claude Code y Cursor?
• Cuándo usar subagentes frente al hilo de chat principal

Fuentes

• Anthropic, “Introducción a los workflows dinámicos en Claude Code”, May 28, 2026.
• Claude Code Docs, “Orquestar subagentes a escala con workflows dinámicos”, consultado el July 15, 2026.
• Claude Code Docs, “Configuración de modelos”, consultado el July 15, 2026.
• Cursor Docs, “Subagentes”, consultado el July 15, 2026.
• Cursor Docs, “Agent Skills”, consultado el July 15, 2026.
• Cursor Docs, “Hooks”, consultado el July 15, 2026.
• Cursor Docs, “Worktrees”, consultado el July 15, 2026.
• Cursor Docs, “SDK de TypeScript de Cursor”, consultado el July 15, 2026.
• Cursor, “Subagentes, skills y generación de imágenes”, January 22, 2026.
• Cursor, “Construye agentes programáticos con el SDK de Cursor”, April 29, 2026.