Cómo ejecutar más de 300 trabajos de subagentes: ¿es realmente posible y están preparadas las aplicaciones LLM y RAG?

TL;DR

Puedes diseñar sistemas que procesen más de 300 trabajos acotados de subagentes, pero la respuesta honesta depende de qué signifique «ejecutar».

Si te refieres a 300 trabajos independientes a lo largo del tiempo, la arquitectura es conocida: ponerlos en una cola, limitar la concurrencia, persistir los artefactos y evaluar los resultados antes de sintetizarlos.

Si te refieres a 300 workers LLM activos dentro de una sola solicitud interactiva, no lo trates como una arquitectura predeterminada. Solo tiene sentido después de comprobar las cuotas del proveedor, el presupuesto, la latencia, los límites de las herramientas dependientes y las restricciones de verificación. Los primeros límites que encontrarás no suelen ser si «el modelo puede pensar». Son la capacidad de procesamiento de tokens, los límites de tasa, el costo, la coordinación de resultados, el trabajo duplicado, la saturación de herramientas, la calidad de la recuperación y la capacidad de revisión humana.

Mi respuesta práctica:

• En mi experiencia, los sistemas LLM se justifican mejor para más de 300 subagentes cuando el trabajo explora múltiples frentes, tiene un alto valor y es mayormente independiente.
• Un RAG ingenuo basado únicamente en búsqueda vectorial es una base riesgosa para un fan-out a gran escala. Para sistemas con 300 workers, exigiría calidad de recuperación medida, referencias a las fuentes, controles de vigencia, evals a nivel de componentes y pruebas del comportamiento ante evidencia insuficiente o consultas sin respuesta.
• La arquitectura en la que confiaría primero no es un enjambre gigante. Son oleadas de workers acotados detrás de un supervisor, una cola, un almacén de memoria y artefactos, un controlador de presupuesto y un verificador.
• El enfoque desde producto importa: la pregunta no es «¿podemos lanzar 300?», sino «¿qué decisión mejora lo suficiente como para justificar 300 workers?».

Qué aprenderás aquí

• Qué puede significar «más de 300 subagentes» en la práctica.
• Por qué ayudan las ventanas de contexto separadas, pero no resuelven la coordinación por arte de magia.
• Dónde están los límites reales: tokens, límites de tasa, límites de batch, latencia, calidad de RAG y carga de revisión.
• Una arquitectura de referencia para ejecutar cientos de subagentes en oleadas.
• Ejemplos concretos de cuándo tienen sentido más de 300 workers y cuándo no.
• Una lista de verificación de capacidad que ingenieros y PMs pueden usar juntos.
• Qué debe tener una aplicación RAG antes de alimentar a cientos de agentes.

Cómo se relaciona con los artículos anteriores

Este artículo no reemplaza la guía básica de delegación de Cuándo usar subagentes y cuándo usar el hilo principal del chat, la arquitectura de creador y verificador de Cómo construir un agente con nivel de ingeniero sénior, la comparación de frameworks de Cómo diseñar subagentes en la nube, ni la guía detallada de diseño de RAG de Aplicaciones RAG en la práctica.

Este artículo se centra en la siguiente pregunta operativa: una vez que ya entiendes los subagentes y RAG, ¿qué condiciones deben cumplirse para que cientos de workers acotados sean una decisión de producto responsable?

Primero, el filtro de producto

Antes de pensar en la arquitectura, pregúntate si 300 workers mejoran una decisión lo suficiente como para justificar el costo y la carga de revisión.

Usa una matriz de evaluación como esta:

Si la evaluación no es favorable, haz un piloto con 10 trabajos acotados. No empieces con 300.

La pregunta central

La versión orientada al usuario suena emocionante:

¿Puedo ejecutar 300 subagentes?

La versión para producción es menos romántica:

¿Puedo crear 300 intentos acotados, cada uno con suficiente contexto para hacer trabajo útil, sin desbordar el presupuesto, los límites de tasa, la calidad de la recuperación o la capacidad de revisión?

Ese enfoque importa porque los subagentes no son neuronas gratuitas. Son ejecuciones de modelos separadas, con sus propios prompts, ventanas de contexto, llamadas a herramientas, logs y modos de falla.

La razón por la que la gente los quiere es válida. Un subagente puede leer logs con mucho ruido, inspeccionar una base de código, buscar en la web, evaluar fuentes, probar una idea o revisar un borrador sin llenar el hilo principal. La documentación del SDK de Claude Code describe los subagentes como instancias de agente separadas que aíslan el contexto, ejecutan tareas en paralelo y devuelven solo el mensaje final al agente principal. El patrón de subagentes de LangChain usa un supervisor que llama a agentes worker sin estado como herramientas, y cada invocación trabaja en una ventana de contexto limpia. La documentación de subagentes de Vercel AI SDK expresa la misma idea de forma explícita: un subagente se ejecuta de manera independiente con su propia ventana de contexto, y la aplicación puede controlar lo que ve el modelo principal con toModelOutput.

Esa es la buena noticia: los subagentes son una primitiva real para gestionar el contexto.

La mala noticia: aislar el contexto no es lo mismo que orquestar.

Los tres significados de «ejecutar 300 subagentes»

Antes de diseñar nada, distingue estos tres casos.

1. Fan-out en batch

Tienes 300 elementos y cada uno necesita la misma operación acotada.

Ejemplos:

• revisar 300 tickets de soporte para detectar vacíos en las políticas
• resumir 300 entrevistas con clientes en evidencia etiquetada
• clasificar 300 documentos por riesgo y responsable
• evaluar 300 respuestas RAG con una rúbrica

Este es el caso más sencillo. No necesitas una megaconversación. Necesitas una cola, trabajos idempotentes, resultados estructurados, reintentos y revisión por muestreo.

2. Investigación en múltiples frentes

Tienes una pregunta amplia con muchas líneas de investigación independientes.

Ejemplos:

• identificar a todos los proveedores de un mercado
• comparar requisitos regulatorios entre jurisdicciones
• auditar toda la documentación pública para el lanzamiento de un producto
• investigar muchas explicaciones posibles de un incidente

Aquí es donde los sistemas multiagente pueden encajar muy bien. Según datos del sistema interno Research de Anthropic, descritos en una publicación de ingeniería del June 13, 2025, un agente principal Claude Opus 4 con subagentes Claude Sonnet 4 superó a un único agente Claude Opus 4 por 90.2% en una eval interna de investigación. La misma publicación indica que el sistema funciona bien para consultas que exploran múltiples frentes, pero también que los agentes usan aproximadamente 4x más tokens que el chat y que los sistemas multiagente usan aproximadamente 15x más tokens que los chats.

Ese equilibrio entre beneficios y costos está en el centro de este artículo.

3. Un enjambre interactivo gigante

Quieres 300 workers activos dentro de una sola solicitud del usuario.

Este es el caso de mayor riesgo. Puede ser apropiado para análisis costosos y de alto valor donde se permite una latencia de minutos y la respuesta necesita una cobertura amplia. Por lo general, no encaja bien con el chat habitual de una aplicación, las modificaciones de código, el soporte al cliente ni los flujos de trabajo donde cada worker depende de todos los demás.

Si los 300 agentes necesitan contexto compartido, coordinación constante o un único plan en evolución, probablemente no necesitas 300 subagentes. Necesitas menos agentes, una mejor descomposición o un flujo de trabajo determinista.

Una arquitectura de referencia más segura

Piensa en oleadas, no en enjambres.

Aquí también importan los patrones de responsabilidad. La documentación de orquestación de OpenAI distingue entre transferencias, donde un especialista toma el control de la conversación, y agentes como herramientas, donde un gestor sigue siendo responsable de la respuesta final. Para sistemas con 300 workers, normalmente mantendría al gestor en control y trataría a los workers como herramientas acotadas, a menos que un especialista realmente necesite hacerse cargo de la parte de la conversación visible para el usuario.

User / trigger
      |
      v
+------------------+
| Supervisor       |
| plan + budget    |
+--------+---------+
         |
         v
+------------------+       +------------------+
| Task planner     | ----> | Durable task log |
| 300 bounded jobs |       | status/artifacts |
+--------+---------+       +------------------+
         |
         v
+------------------+
| Queue            |
| priority + caps  |
+--------+---------+
         |
         v
  wave 1: measured worker cap
  wave 2: measured worker cap
  wave 3: measured worker cap
         |
         v
+------------------+
| Verifier         |
| evals + citations|
+--------+---------+
         |
         v
+------------------+
| Synthesizer      |
| final answer     |
+------------------+

El supervisor no debería limitarse a decir «lanza 300». Debería producir una lista de tareas con:

• un ID de tarea estable
• un objetivo específico
• fuentes y herramientas permitidas
• el esquema de salida esperado
• un presupuesto de tokens y llamadas a herramientas
• un límite de reintentos
• una regla de verificación
• la ubicación del artefacto

Los workers deberían escribir los artefactos en un lugar duradero: almacenamiento de objetos, una base de datos, archivos de un worktree de git o un directorio de ejecución. El agente principal debería recibir referencias y resúmenes, no cada token intermedio.

Bad:
  worker -> 20,000 token narrative -> supervisor context

Better:
  worker -> artifact.json + 8-line summary + source IDs

Esto evita el «juego del teléfono» en el que cada resultado se comprime repetidamente a través del modelo principal.

Las APIs batch no son enjambres activos

Para el fan-out fuera de línea, usa procesamiento batch cuando la latencia pueda ser de minutos u horas. La Message Batches API de Anthropic procesa solicitudes de forma asíncrona, con límites documentados como 100,000 solicitudes o 256 MB por batch y sin respuestas en streaming. La Batch API de OpenAI también es asíncrona, tiene un grupo separado de límites de tasa y documenta límites como hasta 50,000 solicitudes y un archivo de entrada de 200 MB por batch, además de límites de tokens de prompt encolados específicos de cada modelo.

Eso es útil para clasificación, generación de evals, auditorías de documentos y otros trabajos no interactivos.

Pero la capacidad de procesamiento batch no es lo mismo que tener 300 subagentes activos que interactúan con herramientas dentro de una sola solicitud interactiva.

Offline batch:
  submit jobs -> wait -> download results -> verify -> synthesize

Interactive agent fleet:
  plan -> retrieve -> call tools -> adapt -> retry -> verify -> respond

No presentes la capacidad de procesamiento de la Batch API como concurrencia interactiva en vivo. Es una promesa de producto diferente.

Un runbook para 300 workers

Este es un criterio inicial concreto para un piloto serio, no un benchmark general:

Las métricas para los PMs deberían ser igual de concretas:

cost per verified finding
time to decision
coverage gained vs. manual review
review hours created
percentage of outputs escalated

Si esas cifras no mejoran la decisión, la ejecución de 300 workers es puro espectáculo.

Un ejemplo concreto: auditoría de políticas de 320 documentos

Imagina que una empresa quiere saber si 320 documentos de políticas internas están listos para un asistente de soporte con IA.

Un plan ingenuo:

Put every document into a vector database.
Ask one agent: "Are we ready?"

Es probable que esto produzca una respuesta amplia con poca trazabilidad porque el sistema no ha exigido evidencia a nivel de documento, responsables ni verificación.

Un plan más seguro con más de 300 subagentes:

1. Split documents by policy family and owner.
2. Create one audit job per document or section.
3. Run workers in measured waves, starting small and increasing only after observing quotas, latency, tool load, and review capacity.
4. Each worker returns structured findings:
   - doc_id
   - policy_area
   - stale_claims
   - missing_source_ids
   - contradictions
   - risk_level
   - recommended_owner_action
5. Run a verifier over a sample and all high-risk findings.
6. Synthesize only verified findings into a PM-facing readiness report.

Ejemplo de resultado de un worker:

{
  "task_id": "policy-audit-184",
  "doc_id": "refund-policy-enterprise-v7",
  "risk_level": "high",
  "findings": [
    {
      "claim": "Enterprise refunds are approved within 24 hours.",
      "issue": "Conflicts with source policy that says 3 business days.",
      "source_ids": ["billing-policy-2026-03#refunds", "support-macro-51"]
    }
  ],
  "recommendation": "Block this doc from assistant grounding until Billing confirms the SLA."
}

Es un buen caso para cientos de trabajos de subagentes porque el trabajo es independiente, el resultado está estructurado y el verificador puede revisar una muestra o centrarse en los elementos de alto riesgo.

Otro ejemplo: 300 hipótesis sobre un incidente

No toda ejecución útil de 300 workers es una auditoría de una base de conocimiento RAG. Imagina un incidente de producción con muchas causas plausibles entre servicios, despliegues recientes, cambios de configuración, dashboards y runbooks.

300 incident jobs
  120 inspect recent deploy and config changes by service
   80 compare dashboard anomalies against known failure modes
   50 review logs for one bounded hypothesis each
   30 verify top hypotheses against source evidence
   20 cluster duplicate findings and prepare the incident lead brief

Un piloto medido podría verse así:

total jobs:                300
initial wave:              10
next wave:                 measured from RPM/TPM, tool QPS, and reviewer capacity
expected tokens/job:       estimated before launch, measured after wave 1
retry cap:                 1 retry for transient failures
review rule:               all high-severity findings, sample the rest
kill switch:               stop on budget cap, high 429 rate, or low verifier pass rate

Este patrón solo funciona si cada worker tiene una hipótesis específica y escribe artefactos respaldados por evidencia. Falla si cada worker intenta depurar todo el incidente.

Un mal ejemplo: 300 agentes editando una funcionalidad

Ahora imagina que un equipo les pide a 300 agentes que modifiquen el mismo flujo de pago de un producto.

300 workers
   |
   +--> same files
   +--> overlapping product assumptions
   +--> inconsistent tests
   +--> merge conflicts
   +--> no single owner of tradeoffs

Eso no es paralelismo. Es un generador de conflictos.

Para el trabajo de código, usa un paralelismo más reducido:

• un planificador
• unos pocos intentos de implementación aislados en worktrees separados
• un revisor
• un ejecutor de pruebas
• una persona o un orquestador que decida el diff final

Los subagentes ayudan con la exploración, la revisión y la verificación. No eliminan la necesidad de que haya un responsable claro del cambio.

El cálculo de capacidad

No necesitas una fórmula perfecta. Necesitas una comprobación de plausibilidad antes de que la arquitectura se convierta en una factura.

Usa esta estimación aproximada como ayuda para planificar, no como una garantía del proveedor:

tokens_per_worker =
  prompt_tokens
+ retrieved_context_tokens
+ tool_result_tokens
+ expected_output_tokens

worker_cap =
  min(
    requests_per_minute_capacity,
    input_tokens_per_minute_capacity / input_tokens_per_worker,
    output_tokens_per_minute_capacity / output_tokens_per_worker,
    downstream_tool_qps_capacity,
    queue_capacity,
    review_capacity
  )

safe_worker_cap =
  floor(worker_cap * safety_factor)

Las dimensiones exactas varían según el proveedor y el endpoint. OpenAI documenta límites de solicitudes por minuto y tokens por minuto para el uso síncrono, además de límites separados para la Batch API. Anthropic separa las solicitudes por minuto, los tokens de entrada por minuto y los tokens de salida por minuto para la Messages API. Las cuotas de ejecución de Amazon Bedrock son específicas de cada modelo y región, y a menudo cuentan juntos los tokens de entrada y salida.

Como regla inicial, usa un safety_factor conservador y luego ajústalo según la tasa de reintentos, la variación de latencia, la tasa de errores 429 y la capacidad de revisión medidas.

Ejemplo:

token-derived cap:      80 workers
request-derived cap:    120 workers
tool QPS cap:           40 workers
review cap:             25 workers
safety factor:          0.5

safe worker cap ~= 12

Eso no significa «ejecuta los 300 ahora». Significa que el sistema debería procesar el trabajo en oleadas cuyo tamaño dependa del cuello de botella más restrictivo que se haya medido, y continuar a medida que se libere capacidad.

La documentación oficial de los proveedores concreta este punto operativo. Los límites de tasa de OpenAI se miden con métricas como solicitudes por minuto y tokens por minuto. La documentación de la API de Anthropic separa las solicitudes por minuto, los tokens de entrada por minuto y los tokens de salida por minuto. Amazon Bedrock también regula el tráfico de inferencia con cuotas de tokens por modelo que varían según el endpoint, el modelo y la región.

Si el plan de producto dice «300 agentes», el plan de ingeniería debería decir:

300 total jobs
measured worker cap
bounded queue
retry with jitter
budget cap
kill switch
partial results allowed

Por qué la calidad de RAG se convierte en el factor limitante

Cuando ejecutas un agente con una recuperación deficiente, obtienes una respuesta cuestionable.

Cuando ejecutas 300 agentes con una recuperación deficiente, obtienes 300 variantes seguras de sí mismas del mismo problema de calidad de datos.

Weak RAG
  |
  +--> missing chunks
  +--> stale chunks
  +--> duplicate chunks
  +--> no source IDs
  +--> weak citations
  |
  v
300 workers amplify the mess

El Comprehensive RAG Benchmark (CRAG), publicado en la categoría Datasets and Benchmarks de NeurIPS 2024, es una advertencia útil. Reporta que los LLM avanzados alcanzaron como máximo 34% de precisión en CRAG, que un RAG básico solo mejoró hasta 44% y que los sistemas RAG de la industria evaluados en CRAG respondieron sin alucinaciones solo el 63% de las preguntas del benchmark. Estos son resultados específicos del benchmark, no una estimación general de precisión en producción, pero la lección es amplia: la recuperación ingenua no es una capa de confiabilidad.

RAGChecker, también de NeurIPS 2024, plantea un punto complementario. La evaluación de RAG es difícil porque RAG es modular: la recuperación y la generación fallan de maneras distintas. Su framework diagnostica por separado las métricas del recuperador y las del generador, incluido si el modelo usó fielmente el contexto recuperado y si el contexto irrelevante introdujo ruido.

Eso es exactamente lo que necesita un sistema de 300 agentes.

La lista de verificación de preparación de RAG

Antes de darles a cientos de subagentes acceso a una base de conocimiento, comprueba que tenga estas propiedades.

Esta lista combina las lecciones de los benchmarks CRAG y RAGChecker con los controles de recuperación para producción documentados en Databricks AI Search y Azure AI Search.

1. IDs de fuente estables

Cada fragmento recuperado debería tener suficiente información de procedencia para auditarlo después: como mínimo, ID del documento, sección o página, versión o fecha y hora de actualización, y responsable de la fuente cuando el corpus tenga responsables.

Fuente deficiente:

chunk_1827

Mejor fuente:

billing-policy/refunds.md#enterprise-sla@2026-05-14

2. Recuperación híbrida y filtros

Para documentos de políticas, código, finanzas, soporte y producto, la similitud semántica por sí sola a menudo no es suficiente. La guía de calidad de recuperación de AI Search de Databricks, actualizada por última vez el June 17, 2026, recomienda ajustar primero con base en evaluaciones y después usar búsqueda híbrida, filtros de metadatos y reranking cuando las necesidades de calidad justifiquen la latencia.

A una escala de 300 workers, normalmente añadiría:

• búsqueda por palabras clave
• búsqueda vectorial
• filtros de metadatos
• reranking
• reglas de vigencia
• jerarquía de documentos
• reglas de exclusión para borradores y páginas obsoletas
• campos de citas o referencias, como en el modelo de grounding y referencias de Azure AI Search

3. Presupuestos de contexto por worker

Cada subagente necesita un presupuesto máximo de contexto. Sin uno, un worker puede recuperar demasiada evidencia, ocultar el dato relevante y degradar la calidad de la respuesta.

Esto no es teórico. Los modelos estudiados en el artículo «Lost in the Middle», publicado en TACL 2024, a menudo obtuvieron mejores resultados cuando la información relevante estaba cerca del principio o del final del contexto, y su desempeño se degradó cuando estaba en el medio. NoLiMa, un benchmark de contexto largo de ICML 2025, encontró una degradación significativa en 13 modelos de contexto largo a medida que aumentaba la longitud del contexto cuando se minimizaba la coincidencia literal entre la pregunta y la evidencia.

El contexto largo ayuda. No elimina la necesidad de diseñar el contexto.

4. Evals a nivel de componentes

Para cada tipo de worker, evalúa:

• recall de recuperación: ¿obtuvimos la evidencia necesaria?
• precisión del contexto: ¿cuánta evidencia irrelevante incluimos?
• exactitud de las citas: ¿las fuentes citadas respaldan la afirmación?
• fidelidad de la respuesta: ¿el resultado se mantuvo fundamentado?
• comportamiento ante evidencia insuficiente o consultas sin respuesta: ¿el worker dijo «no hay suficiente evidencia» cuando correspondía?
• cumplimiento del formato: ¿el worker devolvió una salida estructurada válida?

5. Agentes verificadores que no compartan el mismo modo de falla

No permitas que quien crea el resultado se evalúe a sí mismo.

Para resultados de alto riesgo, ejecuta un verificador con:

• herramientas de solo lectura
• una rúbrica más estricta
• acceso a los artefactos de las fuentes
• comprobaciones deterministas de citas cuando sea posible
• un prompt, modelo o ruta de recuperación diferente para el trabajo de alto riesgo
• permiso para marcar el trabajo como fallido
• ninguna presión para producir una respuesta pulida

Esto es especialmente importante cuando el resultado final afecta a clientes, dinero, seguridad, decisiones legales o código de producción.

Un patrón sencillo de ejecución

Esta es la estructura con la que empezaría, en pseudocódigo de estilo TypeScript. Lo importante no es la biblioteca. Es el ciclo de control.

type AuditTask = {
  id: string;
  objective: string;
  sourceIds: string[];
  maxInputTokens: number;
  maxToolCalls: number;
};

type AuditResult = {
  taskId: string;
  status: "pass" | "needs_review" | "failed";
  summary: string;
  claims: Array<{
    text: string;
    sourceIds: string[];
    confidence: "low" | "medium" | "high";
  }>;
};

async function runAuditBatch(tasks: AuditTask[], concurrency: number) {
  const queue = [...tasks];
  const results: AuditResult[] = [];

  async function worker() {
    while (queue.length > 0) {
      const task = queue.shift();
      if (!task) return;

      const result = await runBoundedSubagent(task, {
        timeoutMs: 120_000,
        maxToolCalls: task.maxToolCalls,
        maxInputTokens: task.maxInputTokens,
      });

      await writeArtifact(task.id, result);
      results.push(await verifyResult(result));
    }
  }

  await Promise.all(
    Array.from({ length: concurrency }, () => worker()),
  );

  return synthesizeVerifiedResults(results);
}

En un sistema real, reemplaza la cola en memoria por una cola duradera y haz que cada tarea sea idempotente. Añade prioridades, presupuestos por tenant, reintentos con jitter y un mecanismo de parada.

Marco de decisión para PMs

Para los PMs, la pregunta de viabilidad no es solo técnica. También es económica y operativa.

Pregúntate:

• ¿La tarea tiene suficiente valor para justificar un gasto en tokens considerablemente mayor, usando como referencia las cifras reportadas por Anthropic de 4x para agentes frente a chat y 15x para multiagente frente a chat?
• ¿Se puede descomponer el trabajo en unidades mayormente independientes?
• ¿Los resultados parciales pueden ser útiles?
• ¿Hay un verificador o una rúbrica de aceptación claros?
• ¿Conocemos el costo por trabajo completado?
• ¿Cuál es la alternativa cuando falla el 20% de los workers?
• ¿Quién revisa los resultados de alto riesgo?
• ¿Qué promesa le hacemos al usuario sobre la latencia?

Si las respuestas no son sólidas, empieza con 10 workers, no con 300.

Marco de preparación para ingeniería

Para los ingenieros, el sistema está listo cuando existen estos controles:

• Límite de concurrencia: el supervisor no puede lanzar workers ilimitados.
• Presupuesto de tokens: cada ejecución tiene un gasto máximo.
• Presupuesto de herramientas: cada worker tiene un número máximo de llamadas a herramientas.
• Estado duradero: el estado de las tareas sobrevive a los reinicios.
• Almacén de artefactos: los resultados grandes no tienen que pasar por el contexto del agente principal.
• Salidas estructuradas: los workers devuelven datos que se pueden analizar.
• Paso de verificación: los resultados de alto riesgo se comprueban antes de la síntesis.
• Observabilidad: las trazas muestran qué hizo cada worker y por qué.
• Backpressure: los sistemas sobrecargados encolan, degradan el servicio o rechazan solicitudes de forma controlada.
• Escalamiento a personas: la ambigüedad y los riesgos relacionados con políticas llegan a una persona.

Sin estos controles, 300 subagentes son solo un ciclo de prompts costoso.

Entonces, ¿están preparados los LLM y las aplicaciones RAG?

Mi respuesta actual al June 26, 2026:

En mi experiencia, los LLM pueden ser útiles para trabajos acotados y paralelos de subagentes cuando la tarea explora múltiples frentes y tiene un alto valor. La investigación, las auditorías, la generación de evals, la clasificación, el análisis competitivo y la revisión de fuentes son buenos candidatos.

No confiaría en que los LLM coordinen 300 workers estrechamente acoplados como si fueran una organización de ingeniería madura. Todavía necesitan orquestación determinista, presupuestos explícitos, colas, almacenes de artefactos, evals y escalamiento a personas.

Solo confiaría en RAG para este patrón cuando sea más que búsqueda vectorial. Una aplicación RAG que no pueda citar fuentes estables, medir la calidad de la recuperación, rechazar casos con evidencia insuficiente o preguntas sin respuesta y diagnosticar las fallas de recuperación frente a las de generación no debería alimentar cientos de trabajos de subagentes.

El camino práctico es:

1 worker
  -> prove output quality
10 workers
  -> prove decomposition and review
50 workers
  -> prove queueing, cost, and evals
300 workers
  -> prove operations, governance, and value

No empieces por el número. Empieza por la unidad de trabajo. Si la unidad es confiable, acotada, verificable y justifica su costo, escalar a cientos se convierte en un problema de ingeniería.

Si la unidad es vaga, carece de fundamento y es difícil de evaluar, 300 subagentes solo harán que la incertidumbre llegue más rápido.

Fuentes

• Anthropic Engineering, «Cómo construimos nuestro sistema de investigación multiagente», publicado el June 13, 2025. Usado para la arquitectura de orquestador y workers, las ventanas de contexto separadas, el resultado de 90.2% en una eval interna, las advertencias sobre el gasto en tokens y las lecciones de producción.
• Documentación de Claude Code, «Subagentes en el SDK». Usada para las afirmaciones sobre aislamiento de contexto, paralelización y acceso especializado a herramientas.
• Documentación de LangChain, «Subagentes» y «Multiagente». Usada para el patrón de supervisor que utiliza subagentes como herramientas, los subagentes sin estado y el enfoque de ingeniería de contexto.
• Documentación de Vercel AI SDK, «Agentes: subagentes». Usada para las ventanas de contexto independientes de los subagentes y el control de resúmenes con toModelOutput.
• Documentación de la API de OpenAI, «Orquestación y transferencias». Usada para el enfoque de responsabilidad en agentes como herramientas frente a transferencias.
• Documentación de la API de OpenAI, «Límites de tasa». Usada para el enfoque de cuotas RPM/TPM y el seguimiento de límites mediante encabezados de respuesta.
• Documentación de la API de OpenAI, «API batch». Usada para el procesamiento batch asíncrono, los límites separados de la Batch API, el plazo de 24 horas y las restricciones de solicitudes y archivos por batch.
• Documentación de la API de Anthropic, «Límites de tasa». Usada para el enfoque de cuotas de RPM, tokens de entrada por minuto y tokens de salida por minuto.
• Documentación de la API de Anthropic, «Procesamiento batch». Usada para los límites asíncronos de Message Batches, la advertencia sobre la ausencia de streaming y la distinción entre batch e interactivo.
• Documentación de Amazon Bedrock, «Cuotas de Amazon Bedrock» y «Cuotas para el endpoint bedrock-runtime». Usada para el enfoque de cuotas de tokens por modelo.
• Documentación de Databricks, «Guía de calidad de recuperación de AI Search», actualizada por última vez el June 17, 2026. Usada para las afirmaciones sobre búsqueda híbrida, filtrado de metadatos, reranking y ajuste de la calidad de recuperación.
• Microsoft Learn, «Generación aumentada por recuperación en Azure AI Search» y «Consultar una base de conocimiento mediante API o MCP». Usada para los datos de grounding, las citas, las referencias y el enfoque de recuperación agéntica.
• Xiao Yang et al., «CRAG - Benchmark integral de RAG», NeurIPS 2024 Datasets and Benchmarks. Usado para las advertencias sobre precisión de RAG y preparación frente a las alucinaciones.
• Dongyu Ru et al., «RAGChecker: un framework detallado para diagnosticar la generación aumentada por recuperación», NeurIPS 2024 Datasets and Benchmarks. Usado para el enfoque de evaluación de RAG a nivel de componentes.
• Xiangyu Peng et al., «Evaluación de preguntas sin respuesta para la generación aumentada por recuperación», ACL 2025. Usado para el comportamiento ante consultas sin respuesta y evidencia insuficiente.
• Nelson F. Liu et al., «Perdidos en el medio: cómo usan los modelos de lenguaje los contextos largos», TACL 2024. Usado para las advertencias sobre la posición de la información y la degradación en contextos largos.
• Ali Modarressi et al., «NoLiMa: evaluación de contextos largos más allá de la coincidencia literal», ICML 2025. Usado para las limitaciones de los contextos largos cuando se eliminan las pistas de coincidencia literal.