Ejecución Paralela en el Edge:
Self-Fetch Chain y Orquestación sin Límites

Las plataformas edge computing como Cloudflare Workers están optimizadas para respuestas rápidas: un request entra, se procesa en milisegundos, y sale. Pero ¿qué pasa cuando necesitas que varios agentes de IA colaboren durante 2-3 minutos en una misma tarea?

Los Workers tienen límites estrictos. El tiempo de CPU disponible es generoso en planes de pago, pero el wall-time — el reloj real entre que el request empieza y termina — es el verdadero cuello de botella. Si tu orquestación multi-agente necesita 3 pasos secuenciales de 60 segundos cada uno, ya estás fuera de los límites de un solo request.

La solución intuitiva — waitUntil() para trabajo en background — tiene sus propias limitaciones. En la práctica, el trabajo delegado vía waitUntil comparte el mismo contexto de ejecución, y en entornos con múltiples pasos encadenados, los timeouts y la estabilidad se degradan. Necesitábamos algo diferente.

La idea central es simple: un Worker puede hacer fetch a sí mismo. En lugar de ejecutar todos los pasos de orquestación dentro de un solo request, cada paso se ejecuta en una invocación independiente que, al terminar, dispara la siguiente.

Cada request tiene su propio presupuesto de CPU y wall-time completo. Un pipeline de 5 pasos que necesitaría 5 minutos seguidos ahora se ejecuta en 5 requests independientes de ~1 minuto cada uno. El edge ya no es un límite, es un multiplicador.

No todos los pasos necesitan ser secuenciales. Cuando el LLM orquestador planifica una tarea, asigna a cada paso un grupo paralelo (parallel_group). Los pasos dentro del mismo grupo se ejecutan concurrentemente; los grupos distintos se ejecutan secuencialmente.

{
  "plan": [
    { "agent": "Analista",   "role": "Investigar mercado",     "group": 1 },
    { "agent": "Diseñador",  "role": "Crear mockups",          "group": 1 },
    { "agent": "Redactor",   "role": "Escribir copy",          "group": 1 },
    { "agent": "Director",   "role": "Compilar y revisar",     "group": 2 }
  ]
}

En este ejemplo, los 3 primeros pasos se ejecutan en paralelo real dentro de la misma request vía Promise.all. Cada agente recibe su propio prompt con contexto, capacidades y outputs anteriores. Cuando los 3 terminan (o fallan), el sistema encadena al grupo 2, donde el Director compila los resultados.

En cualquier sistema distribuido que ejecuta IA, las cosas van a fallar. Los LLMs se cuelgan, las APIs externas no responden, los requests de generación de imagen tardan más de lo esperado. El truco no es evitar fallos — es contenerlos elegantemente.

Diseñamos un sistema de timeouts en cascada donde cada capa es un poco más permisiva que la anterior. Si la capa interna no detecta el problema, la siguiente lo atrapa. Y si ninguna lo atrapa, el sistema de auto-recovery lo limpia periódicamente.

Cuando tienes ejecución paralela, secuencial y retry, es tentador escribir la lógica de cada camino por separado. Al fin y al cabo, tienen contextos ligeramente diferentes: el paralelo ejecuta múltiples agentes a la vez, el secuencial uno por uno, y el retry necesita reconstruir el contexto de un paso que ya existía.

Pero el núcleo es idéntico: cargar contexto de datos del agente, construir el prompt con outputs anteriores, llamar al LLM con el provider correcto, y post-procesar el resultado según la capacidad (texto, imagen, audio, visión). Si plantas esa lógica en 3 sitios, cada bug hay que arreglarlo 3 veces. Cada mejora hay que copiarla 3 veces. Cada inconsistencia es una bomba de relojería.

La solución es extraer el core de ejecución en una función compartida. Esta función recibe el agente, el plan, los outputs previos y la configuración, y devuelve el resultado procesado. Los tres caminos la usan, pero cada uno maneja su propia lógica de estado, timeouts y encadenamiento alrededor de ella.

async function executeStep(agent, plan, prevOutputs, config) {
  // 1. Contexto de datos (si el agente tiene acceso)
  const dataContext = agent.dataAccess
    ? await loadOrganizationData(agent)
    : '';

  // 2. Búsqueda web (si el paso lo requiere)
  const webContext = plan.capability === 'web'
    ? await searchWeb(task.title)
    : '';

  // 3. Construir prompt con outputs anteriores
  const prompt = buildPrompt(agent, plan, prevOutputs, dataContext, webContext);

  // 4. Llamar al provider correcto
  const result = await callAI(config.provider, config.model, prompt);

  // 5. Post-proceso según capacidad (TTI → generar imagen, TTS → sintetizar, etc.)
  return await postProcess(result, plan.capability);
}

Esta deduplicación no es cosmética. Cuando detectamos un bug en el manejo de web search, o mejoramos el post-procesamiento de imágenes, el fix se aplica a los tres caminos simultáneamente. Pasamos de ~360 líneas triplicadas a ~120 líneas compartidas.

En una arquitectura stateless como Workers, no puedes guardar estado en memoria entre requests. Cada invocación de /continue empieza desde cero: carga la tarea, lee los pasos completados, identifica cuál es el siguiente, y ejecuta. La base de datos es la única fuente de verdad.

Esta granularidad por paso — no por tarea — es lo que hace posible el retry selectivo. El usuario puede ver en tiempo real qué pasos completaron, cuáles fallaron, y reintentar solo los problemáticos. El sistema reconstruye el contexto a partir de los outputs existentes y re-ejecuta exclusivamente lo necesario.

El patrón self-fetch chain abre la puerta a una UX que sería imposible con ejecución monolítica. Si toda la orquestación ocurriera en un solo request, el usuario vería un spinner durante 3 minutos sin saber qué está pasando. Con la cadena, el frontend puede pollear el estado y mostrar progreso real.