Un agente o varios: cuándo conviene trabajar en paralelo
Antes de pedir «crea un equipo de agentes», escribe qué tiene que quedar terminado. Si no puedes separar las entregas, añadir agentes puede multiplicar los borradores que tendrás que reconciliar.
Aquí hablamos de subagentes de IA que reciben un encargo y devuelven trabajo a un agente principal. No hace falta programar un sistema nuevo para decidir el reparto. Si todavía estás eligiendo entre conversación, automatización y autonomía, empieza por agente de IA frente a chatbot.
La guía incluye un caso documental del trabajo editorial de Ranquia y un contrato que puedes adaptar. El caso acredita responsabilidades, entregas y correcciones; no mide cuánto tiempo ahorró usar varios agentes.
Decide el reparto antes de abrir más agentes
Esta es nuestra regla práctica de organización, no un número óptimo universal de agentes:
| Situación | Reparto recomendado | Qué debe quedar acordado |
|---|---|---|
| Investigar preguntas distintas que ya están definidas | Varios en paralelo | Una pregunta por agente; fuentes y dudas en la entrega |
| Redactar o implementar en archivos distintos, con requisitos estables | Varios, con integración posterior | Propietario de cada archivo y formato común |
| Reescribir el mismo archivo o cambiar una decisión compartida | Un responsable de edición; otros pueden revisar | Observaciones separadas, sin sobrescribir el candidato |
| Verificar, editar o probar algo que todavía no existe | En secuencia | Versión de entrada y condición que permite comenzar |
| Resolver una consulta breve o un cambio localizado | Un agente | Resultado esperado y comprobación suficiente |
La distinción entre trabajo independiente y trabajo dependiente también aparece en los patrones de sistemas con agentes de Google Cloud: el patrón paralelo reúne resultados de subtareas que pueden ejecutarse al mismo tiempo. Eso permite organizar el trabajo; no demuestra por sí solo que tu encargo vaya a salir antes o mejor.
Haz una comprobación sencilla: ¿el agente B puede terminar sin esperar una decisión de A? Si la respuesta es no, escribe esa dependencia. Puedes adelantar otra parte independiente, pero no pedir la aprobación final de un archivo que aún está cambiando.
Un caso real: dos guías, archivos separados y revisiones por etapa
Para preparar dos guías de Ranquia —una sobre MCP y otra sobre adaptación de skills— se asignaron borradores y recursos a agentes de redacción distintos. Los informes de la tanda del 4 de octubre de 2026 registran entregas separadas, verificación de hechos, curaduría de imágenes y revisión de lectura e interacción.
El siguiente mapa resume esas responsabilidades. No es un cronograma ni afirma qué agentes estuvieron activos simultáneamente.
| Trabajo documentado | Entrega conservada | Dependencia para la etapa siguiente |
|---|---|---|
| Redactor de la guía MCP | Borrador, dos programas didácticos y registro de una consulta local | Verificar texto y evidencia antes de editar sus afirmaciones |
| Redactor de la guía de skills | Otro borrador, diferencias entre archivos y comprobación estática | Distinguir archivos válidos de funcionamiento en asistentes |
| Verificación de hechos | Informes con fuentes, límites y versión revisada | Resolver correcciones antes de cerrar el contenido |
| Curaduría de imágenes | Diagrama del intercambio MCP y fragmento del diff de la skill | Mantener la misma evidencia y no fingir capturas comerciales |
| Integración y revisión final | Candidatos integrados y revisión de páginas renderizadas | Comprobar texto, enlaces, imágenes y recursos juntos |
Qué permite repartir este caso: cada redactor tenía un artículo y recursos propios. La revisión de hechos entregaba un informe distinto del archivo que se iba a editar; la curaduría entregaba assets que después debían integrarse. Las tareas tenían salidas que se podían inspeccionar por separado.
Qué seguía dependiendo de una entrega anterior: la imagen sobre MCP debía representar el intercambio realmente documentado. La revisión final debía leer la versión que ya incluía texto e imágenes, y comprobarla dentro del sitio. Dibujar el resultado antes de tener la evidencia o aprobar un borrador anterior habría roto esa correspondencia.
Hubo una corrección concreta al integrar: las lecturas relacionadas de ambas guías necesitaban el identificador del archivo de la página de tokens, que no coincidía con su slug público. Se corrigió ese metadato y se conservó la URL del enlace en el cuerpo. La comprobación del conjunto cubría así algo que no se resolvía solo con redactar bien cada artículo.
Los reportes de verificación, imágenes y revisión final vincularon sus conclusiones a versiones concretas mediante SHA-256. Esa huella permite reconocer los mismos bytes; no certifica que el contenido sea correcto. Para eso seguían siendo necesarias las fuentes y las comprobaciones descritas en cada informe.
El aprendizaje transferible es sencillo: reparte entregas, conserva sus dependencias y reserva tiempo para integrarlas. Los registros no incluyen una ejecución comparable con un solo agente, así que no permiten calcular aceleración, ahorro de tokens ni superioridad de un modelo.
Copia este contrato de delegación
Este ejemplo es una plantilla propuesta, no una transcripción de instrucciones internas ni una prueba nueva. Supone que tienes un borrador y una ficha de referencia autorizada. Cambia los nombres por los de tu proyecto y confirma que el agente pueda leerlos.
Objetivo
Comprobar si las afirmaciones del borrador están respaldadas
por la ficha de referencia y señalar qué falta verificar.
Entradas
- borrador.md, versión que entrega el coordinador.
- referencia.md, fuente que se debe usar para esta revisión.
Alcance y exclusiones
Lee ambos archivos. No los edites ni añadas hechos de memoria.
No hagas búsquedas externas para completar ausencias.
Si falta un archivo o hay versiones contradictorias, indícalo.
Archivo propio
Tu única salida es revision-hechos.md.
Otro agente trabaja en el proyecto: no modifiques sus entregas.
Formato de entrega
Una fila por hallazgo: afirmación del borrador, evidencia,
ubicación en la fuente y estado:
RESPALDADA / CONTRADICHA / SIN EVIDENCIA.
Incluye los archivos y la versión que revisaste.
Criterio de aceptación
Todas las afirmaciones verificables quedan cubiertas.
Las ausencias siguen marcadas; no se rellenan con suposiciones.
No cambió ninguno de los archivos de entrada.
Dependencia y cierre
Empieza cuando el coordinador confirme la versión del borrador.
Si cambia durante la revisión, avisa qué versión alcanzaste a leer.
Devuelve el informe con dudas pendientes; no declares publicado
ni aprobado el artículo. El coordinador integra las correcciones.
Una entrega útil debe permitir comprobar el resultado, no obligarte a reconstruir todo el trabajo del subagente. Para investigación, pide fuentes y fragmentos pertinentes. Para edición, pide archivos modificados y validación. Para revisión, pide ubicación, problema y evidencia.
En una tarea pequeña basta identificar claramente la versión del archivo. Cuando varios procesos lo modifican, usa un commit, una copia congelada o una huella para evitar que «revisado» termine refiriéndose a un contenido anterior.
Qué cambia entre Codex, Claude Code y Copilot
El criterio de reparto se puede reutilizar; la configuración y el contexto que recibe cada subagente dependen del cliente. Documentación consultada el 5 de octubre de 2026:
- Codex: la documentación describe delegación a subagentes y recopilación de resultados por el hilo principal. Puedes pedir que reparta partes independientes de un encargo. OpenAI advierte que cada subagente realiza su propio trabajo de modelo y herramientas, y que estos flujos consumen más tokens que ejecuciones comparables con uno solo. No confundas paralelismo con reducción de consumo. Subagentes en la documentación oficial de OpenAI.
- Claude Code: los subagentes trabajan con su propio contexto y pueden tener instrucciones, herramientas y permisos configurados. No todos arrancan con la misma información: la documentación distingue el contexto inicial de un subagente nuevo de un fork que hereda la conversación. Incluye siempre los inputs necesarios en el encargo. Subagentes de Claude Code.
- Copilot en VS Code: primero identifica el motor de la sesión, llamado harness en la documentación. El modo Local utiliza
runSubagent; el de Copilot gestiona la delegación mediante Copilot SDK. La guía también separa los modos Claude y Codex. No traslades automáticamente comandos o reglas de contexto de Local a todos ellos. Subagentes en VS Code.
Elegir otro modelo dentro del editor no basta para saber cómo se orquestan sus subagentes. Revisa la sesión concreta y pide una primera entrega acotada antes de encargar un reparto amplio.
Dónde puede perderse el beneficio
Estos son riesgos que conviene vigilar, no fallos que atribuyamos a todos los clientes ni resultados medidos del caso anterior:
- Investigación duplicada: dos encargos vagos llevan a consultar las mismas fuentes. Separa preguntas o declara que quieres contrastar enfoques deliberadamente.
- Contexto insuficiente: el subagente resuelve otra versión del problema. Dale los inputs, decisiones y restricciones que necesita, sin suponer que ve toda la conversación.
- Edición cruzada: dos agentes cambian la misma pieza. Asigna un propietario; el segundo puede devolver observaciones en su propio informe.
- Conclusiones sin prueba: «todo correcto» no indica qué se comprobó. Exige archivo, versión, evidencia y dudas pendientes.
- Integración omitida: las entregas pasan por separado, pero discrepan entre sí. Revisa el conjunto con los criterios originales antes de aceptarlo.
Tampoco cuentes dos opiniones coincidentes como dos pruebas independientes. Pueden apoyarse en la misma fuente o repetir la misma premisa. Si necesitas comparar salidas, aplica una rúbrica con evidencia y origen oculto antes de decidir por el tono de la respuesta.
Comprueba si compensa en tu trabajo
Compara encargos equivalentes hasta un resultado aceptado, incluyendo revisión e integración. Registra por separado:
| Dato | Qué anotar |
|---|---|
| Tiempo total transcurrido | Desde que comienza el encargo hasta que se acepta el conjunto; no sumes esperas que se solapan |
| Tiempo humano activo | Preparar, revisar, corregir e integrar |
| Reintentos y errores | Qué entregas hubo que repetir y qué fallos seguían abiertos |
| Consumo | El uso que muestre el cliente, con su unidad, modelo y alcance; si no aparece, «no medido» |
| Calidad aceptada | Los mismos criterios para ambos repartos |
Puedes adaptar el registro de tiempo ahorrado con IA, distinguiendo explícitamente la condición «un agente» de «varios» en lugar de mezclarla con una comparación manual/IA. Que una entrega llegue antes no basta si su integración exige más trabajo o queda por debajo de la calidad requerida.
En el caso documental de esta página, el ahorro temporal, el consumo comparable y el efecto sobre la calidad frente a un solo agente quedan no medidos. Lo observado son entregas delimitadas, correcciones trazables y revisiones del conjunto. Empieza aplicando ese reparto a una tarea que puedas verificar; aumenta la delegación solo cuando el resultado lo justifique.