**
Una idea arquitectónica ampliamente difundida en la comunidad de IA está llevando a muchos equipos por el camino equivocado.
La Conclusión Primero
Si estás considerando nombrar múltiples Agentes de IA como "Product Manager", "Arquitecto" e "Ingeniero de Pruebas", y hacer que se pasen documentos y colaboren como departamentos de una empresa—por favor, detente.
Este modelo parece intuitivo y lógicamente sólido, pero tiene fallos fundamentales en ingeniería. Más importante aún, ninguno de los tres grandes proveedores—Anthropic, OpenAI y Google—utiliza este modelo al construir sus propios sistemas de Agentes.
Esto no es una coincidencia.
¿Qué es la Arquitectura de "Tres Departamentos y Seis Ministerios"?
Esta metáfora se refiere a una clase de ideas de diseño multi-agente muy populares en la comunidad, conocidas por diferentes nombres en varios frameworks y artículos: agentes basados en roles, equipos virtuales, división del trabajo estilo CrewAI, u organización estilo MetaGPT. Este artículo las denomina colectivamente como el modelo "Departamentalizado".
El patrón central es: descomponer una tarea compleja en varias funciones, donde cada Agente desempeña un rol—PM para requisitos, Tech Lead para arquitectura, Dev para implementación y QA para pruebas. Las tareas fluyen entre Agentes como una línea de ensamblaje.
Este modelo se ve genial en un diagrama. Satisface la intuición humana de "división del trabajo" y hace que el concepto de un "equipo de IA" sea concreto y explicable. Frameworks como CrewAI han acumulado muchos usuarios gracias a esto.
El problema es que resuelve cuellos de botella humanos, no cuellos de botella de IA.
Por Qué Esta Analogía es Fundamentalmente Incorrecta
Los humanos necesitan división del trabajo porque:
- Una sola persona tiene atención limitada y no puede procesar toda la información simultáneamente.
- Los humanos tienen barreras profesionales y altos costos de aprendizaje/cambio.
- Los humanos necesitan interfaces para coordinarse entre sí.
Pero las características de los LLM son completamente diferentes:
- El mismo modelo puede escribir tanto PRDs como código; no existen "límites profesionales".
- El cuello de botella para los modelos no es la capacidad de atención, sino la profundidad de razonamiento y la integridad de la información.
- Los modelos carecen de "cultura" y "conocimiento tácito" para compensar la pérdida de información.
Etiquetar a un Agente como "Product Manager" no lo hace más profesional—lo hace negarse a cruzar límites. Un Agente encasillado en un rol de "Ingeniero de Pruebas" podría pasar por alto un problema arquitectónico porque "no está dentro de mi alcance". El razonamiento más valioso a menudo ocurre en los límites, y el modelo Departamentalizado sella esta posibilidad a nivel del sistema.
La interpretación de roles crea límites falsos. Este es el primer problema.
El Segundo Problema: La Información Muere en Tránsito
En el modelo Departamentalizado, el Agente A produce un documento y se lo pasa al Agente B.
Este proceso transmite conclusiones, no el proceso de razonamiento.
B recibe el documento, lo reinterpreta y reconstruye el contexto. La intención original se degrada, las suposiciones ocultas se pierden y cada traspaso acumula errores. Cuanto más largo es el flujo de trabajo, más se convierte el resultado final en "localmente correcto pero globalmente desviado"—cada nodo parece razonable, pero el conjunto se ha desviado del objetivo original.
Las organizaciones humanas dependen de reuniones, cultura y comunicación informal para compensar esta pérdida de información. Los Agentes no tienen estos mecanismos.
Hay una refutación común: ¿Acaso las soluciones de los tres grandes proveedores (progress.txt, archivos de especificaciones, runbooks) también implican "pasar archivos"? ¿Cuál es la diferencia?
La diferencia radica en quién lo escribe, para quién es y cómo se actualiza.
El flujo de información departamentalizado es un traspaso unidireccional entre roles: A termina y se lo da a B; B no mira atrás, y A no sabe cómo B usó el documento. La información se comprime en conclusiones, el proceso de razonamiento se pierde y el traspaso es un punto de ruptura.
Los archivos de estado externos son registros incrementales de la misma tarea: La entidad ejecutora añade al mismo registro en cada punto de control, y la siguiente sesión lee el historial completo de la tarea, no la conclusión de salida de un "colega" anterior. La persona que escribe el estado y la persona que lo lee son el mismo rol, solo que en momentos diferentes. La información no se "comprime y transmite"; se "acumula continuamente".
Esta diferencia determina si la cadena de razonamiento puede permanecer continua entre sesiones.
Una cantidad masiva de tokens se desperdicia en "archivos de traspaso" entre Agentes en lugar de en razonamiento real. Obtienes un sistema que simula el comportamiento de una empresa, no un sistema que resuelve problemas.
Cómo lo Hacen Realmente los Tres Grandes Proveedores
Es notable que cuando Anthropic, OpenAI y Google construyen sus sistemas de Agentes de grado de producción, sus documentos de ingeniería casi nunca mencionan "interpretación de roles" o "división departamental".
Anthropic: Ingeniería de Contexto + Archivos de Estado Explícitos
Anthropic ha actualizado la "Ingeniería de Prompts" a "Ingeniería de Contexto": La pregunta no es cómo escribir un buen prompt, sino qué configuración de tokens produce mejor el comportamiento deseado.
Al construir los sistemas Claude Code y Research, su desafío central fue: los Agentes deben trabajar en sesiones discretas, y cada nueva sesión no tiene memoria de lo que sucedió antes. Su metáfora son "ingenieros de turno"—cada nuevo turno de ingenieros no sabe nada sobre el trabajo del turno anterior.
La solución no es que los Agentes interpreten diferentes roles, sino:
- claude-progress.txt: Un registro de trabajo entre sesiones que el Agente actualiza al final de cada sesión y lee al inicio de la siguiente.
- Historial de Git: Sirviendo como anclas de estado, registrando cada cambio incremental.
- Agente Inicializador: Se ejecuta solo en la primera sesión para configurar el entorno, expandir la lista de funciones y escribir el runbook para todas las sesiones posteriores.
Perspectiva clave: La continuidad de la cadena de razonamiento no depende de que el modelo "recuerde"; depende de un estado externo explícito para anclarla.
También descubrieron que codificar "suposiciones de capacidad del modelo" en el harness es peligroso. Sonnet 4.5 tenía "ansiedad de contexto"—se apresuraba a concluir al acercarse al límite de contexto, por lo que agregaron un reinicio de contexto al harness. Pero en Opus 4.5, este comportamiento desapareció y el reinicio se volvió peso muerto. Esto demuestra que el harness necesita evolucionar con el modelo; cualquier "solución permanente" es solo un compromiso de ingeniería para la etapa actual.
En los sistemas de Investigación multi-agente, la arquitectura de Anthropic es orquestador-trabajador: un agente principal descompone tareas y coordina subagentes, que exploran diferentes direcciones en paralelo, con resultados que fluyen de vuelta al agente principal para su síntesis. Descubrieron que el consumo de tokens por sí solo explicaba el 80% de las diferencias de rendimiento—el valor de los multi-agentes no es la "división del trabajo", sino usar más tokens para cubrir un espacio de búsqueda más grande.
Hay un punto de confusión aquí: los subagentes de Anthropic podrían parecer "división del trabajo", pero la esencia es diferente. La departamentalización es división funcional—diferentes roles manejan diferentes tipos de trabajo (PM a Dev a QA). Los subagentes de Anthropic son paralelismo funcional—múltiples agentes idénticos buscan diferentes direcciones simultáneamente, no hay "siguiente traspaso", y todos los resultados convergen de vuelta al mismo orquestador. El primero es una carrera de relevos; el segundo es echar una red amplia.
OpenAI: Compactación + Habilidades + Archivos de Especificaciones Estructurados
Los principios de OpenAI para tareas de largo horizonte son aún más directos: planificar la continuidad al inicio de la tarea.
En sus experimentos con Codex, los ingenieros dieron al agente un archivo de especificaciones (congelando el objetivo para evitar que el agente hiciera algo "impresionante pero en la dirección equivocada"), le hicieron generar un plan basado en hitos, y luego usaron un archivo runbook para decirle al agente cómo operar. Este runbook también es una memoria compartida y un registro de auditoría.
Resultado: GPT-5.3-Codex se ejecutó durante aproximadamente 25 horas continuas, completando una herramienta de diseño completa mientras mantenía la coherencia en todo momento.
La compactación del lado del servidor sirve como un primitivo predeterminado, no como un recurso de emergencia. En tareas de múltiples pasos, previous_response_id permite que el modelo continúe trabajando en el mismo hilo en lugar de reconstruir el contexto cada vez.
También introdujeron el concepto de Habilidades—conjuntos de instrucciones reutilizables y versionados montados en contenedores, dando a los agentes estándares operativos estables para tareas específicas. Estos no son "roles"; son herramientas y procedimientos operativos, que son fundamentalmente diferentes.
Google: 1M de Contexto + Desarrollo Impulsado por Contexto
La dirección de Google es forzar la ventana: el contexto de 1M de tokens de Gemini es una estrategia de diferenciación clara. Su lógica es que técnicas previamente forzadas como el corte de RAG y el descarte de mensajes antiguos pueden ser reemplazadas por "simplemente ponerlo todo" dado un tamaño de ventana suficientemente grande.
Pero admiten que incluso esto no es suficiente. Google lanzó la extensión Conductor para Gemini CLI, con una idea central idéntica a la de Anthropic: mover la intención del proyecto fuera de la ventana de chat y hacia archivos Markdown persistentes en el código base. La filosofía: "No confíes en el historial de chat inestable; confía en archivos formales de especificaciones y planes."
Gemini 3 también introdujo Firmas de Pensamiento: guardar nodos clave de la cadena de razonamiento en sesiones largas para prevenir la "deriva de razonamiento"—el problema de inconsistencia lógica en contextos largos.
¿Cuáles son los Principios Arquitectónicos Reales?
De las prácticas de ingeniería de estas tres empresas, se pueden extraer varios principios comunes:
La cadena de razonamiento no puede romperse; solo puede ramificarse y fusionarse. El uso correcto de multi-agentes no es una línea de ensamblaje, sino un agente principal que mantiene la intención completa, con subllamadas utilizadas para profundizar en subproblemas, y resultados que fluyen de vuelta al agente principal, no al siguiente agente.
Estado externo explícito, no confíes en la memoria del modelo. Ya sea progress.txt, historial de git, archivos de especificaciones o bases de datos—la forma no importa. El principio es: los nodos clave de la cadena de razonamiento deben externalizarse a almacenamiento persistente.
El valor de los multi-agentes es la cobertura en paralelo, no la división del trabajo. La conclusión del sistema de Investigación de Anthropic es clara: las ganancias de rendimiento provienen de "gastar más tokens", no de "mejor división del trabajo". Los multi-agentes son adecuados para tareas de amplitud primero—escenarios que requieren exploración simultánea de direcciones independientes. No son adecuados para escenarios que requieren razonamiento continuo y dependencia profunda del contexto.
El Agente Verificador es un negador, no un corredor de relevos. Si se usan multi-agentes para control de calidad, el diseño correcto es tener un Agente que encuentre específicamente problemas en el trabajo de otro, en lugar de "pasar el resultado del trabajo". Pruebas adversariales, no transferencia en línea de ensamblaje.
Las herramientas son herramientas, no roles. Con qué herramientas equipas a un Agente (bash, E/S de archivos, búsqueda, ejecución de código) es mucho más importante que la etiqueta que le pongas. Las herramientas determinan lo que un Agente puede hacer; las etiquetas de rol solo limitan lo que está dispuesto a hacer.
¿Por Qué es Popular el Modelo "Departamentalizado"?
Porque es fácil de explicar.
"Este Agente es el PM, ese es el QA"—cualquiera puede entenderlo. Satisface el deseo humano de explicabilidad de los sistemas de IA y la imaginación de la gerencia de que "la IA trabaje como un equipo".
También es fácil de demostrar. Dibujado como un diagrama de flujo con departamentos, flechas y traspasos, es muy intuitivo.
Pero ser fácil de explicar y demostrar es diferente de ser sólido desde el punto de vista de la ingeniería.
Una razón más profunda es que la mayoría de los equipos que adoptan este modelo no se han enfrentado realmente al problema de la "pérdida de contexto durante la transferencia multi-agente". Sus tareas podrían no ser lo suficientemente complejas, o el problema está enmascarado por otros factores. Una vez que la complejidad de la tarea aumenta y el sistema comienza a mostrar errores de "localmente correcto pero globalmente incorrecto", el problema queda expuesto.
Consejos Prácticos
El mejor sistema multi-agente no se parece a una empresa. Se parece más a los múltiples borradores de un pensador—el mismo cerebro expandiendo el razonamiento a través de diferentes dimensiones y finalmente fusionándolos en una conclusión coherente.
Basado en este principio:
No preguntes "¿Cuántos Agentes necesito?"; pregúntate "¿Cuál es la estructura de dependencia de información de esta tarea?"
Si una tarea requiere razonamiento continuo y alta dependencia del contexto (por ejemplo, escribir un documento de diseño para una función compleja), un solo Agente + buena ingeniería de contexto suele ser superior a los multi-agentes.
Si una tarea requiere exploración simultánea de direcciones independientes (por ejemplo, investigar 10 competidores simultáneamente), el paralelismo multi-agente es razonable—la tarea de cada subagente es independiente, y el costo de la pérdida de información se minimiza.
Si una tarea abarca múltiples sesiones, los archivos de estado externos son obligatorios. Un archivo de estado efectivo debe contener cuatro tipos de información:
- Objetivo de la Tarea (Invariable, se lee al inicio de la sesión para evitar la deriva)
- Pasos Completados (Se añaden, no se sobrescriben, para mantener el historial completo)
- Estado Actual (Se sobrescribe para reflejar el progreso más reciente)
- Errores Conocidos (Se añaden para evitar repetir errores en la siguiente sesión)
Estos cuatro tipos de información, mantenidos por separado y combinados, proporcionan el contexto completo necesario para el "yo futuro".
Si se añade un paso de verificación, haz que la única tarea del Agente Verificador sea encontrar problemas, no "tomar el testigo y continuar". Pruebas adversariales, no transferencia en línea de ensamblaje.
Finalmente: Las capacidades de los modelos están mejorando rápidamente. Las soluciones alternativas necesarias en el harness hoy podrían convertirse en peso muerto en seis meses. Anthropic ya ha demostrado esto—la ansiedad de contexto de Sonnet 4.5 desapareció en Opus 4.5. Mantener la evolucionabilidad arquitectónica es más importante que elegir una "arquitectura perfecta".
La departamentalización es una ilusión que se siente bien pero es costosa desde el punto de vista de la ingeniería. Su verdadero costo no es el fracaso directo, sino hacer que tu sistema se degrade de maneras difíciles de diagnosticar a medida que aumenta la complejidad—donde cada nodo "parece estar funcionando", pero el conjunto está a la deriva.
Para cuando encuentres el problema, la línea de ensamblaje ya es muy larga.
Referencias: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
