# Ahora la orquestación es la arquitectura

Divide el god-agent (agente-dios) en diez agentes enfocados y cambias un problema de modelo por un problema de sistemas: ahora tienen que trabajar juntos, y la coordinación es más difícil que cualquier agente individual. La mayoría de los equipos tratan ese cableado como plomería. No lo es: es la arquitectura, es un sistema distribuido y falla como uno. Esto es lo que realmente es la orquestación, cómo se rompe y por qué no deberías recurrir a ella hasta que puedas nombrar el cuello de botella.

- **Author:** Fedor Chishchin
- **Published:** 2026-06-03
- **Tags:** agents, architecture, methodology
- **Source:** https://fedorthinks.com/es/blog/orchestration-is-the-architecture

---

La vez pasada argumenté que deberías
[dividir el god-agent (agente-dios)](/blog/one-agent-that-does-everything) en
agentes pequeños y enfocados que hagan una sola cosa bien, y terminé con una
trampa: hacer eso no elimina tu problema, lo cambia por uno nuevo. Ahora tienes
diez agentes que tienen que trabajar juntos, y lograr que lo hagan resulta ser
más difícil que cualquier cosa con la que un solo agente estaba batallando.

Esa coordinación es el tema de este post, porque la forma en que la mayoría de
los equipos la manejan es la razón silenciosa por la que sus sistemas
multiagente se vienen abajo.

## La coordinación no es la plomería. Es el sistema.

Cuando la gente construye un montaje multiagente, piensa en los agentes como el
sistema y en el cableado entre ellos como plomería: conectas las salidas a las
entradas y listo. Eso está al revés. Una vez que el trabajo se reparte entre
especialistas, los agentes son la parte fácil. **Ahora la coordinación es la
arquitectura**, y es la parte que casi nadie diseña a propósito.

Esa capa tiene un nombre: orquestación. Y no es un cable, es un conjunto de
responsabilidades reales:
[descomposición de tareas, enrutamiento, gestión de estado, agregación de
resultados, y manejo de errores y escalamiento](https://atlan.com/know/multi-agent-system-orchestration/).
La forma dominante en producción es el patrón **orchestrator-worker
(orquestador-trabajador)**, alrededor del
[70% de los despliegues](https://medium.com/@Micheal-Lanham/multi-agent-in-production-in-2026-what-actually-survived-f86de8bb1cd1),
donde un modelo capaz recibe la tarea, la desglosa, despacha cada pieza a un
worker / trabajador especialista barato, y arma los resultados. (Esa división,
un planificador inteligente sobre ejecutores baratos, es también
[de donde proviene buena parte del ahorro de costos](/blog/cheap-model-most-of-the-work):
40–60% en los casos reportados.) Ese orquestador no es pegamento. Es el
componente más importante que vas a escribir.

## Es un sistema distribuido, y falla como uno

Aquí está el cambio mental que vuelve tratable todo el asunto: un sistema
multiagente _es_ un sistema distribuido. Componentes independientes, que pasan
mensajes, que mantienen estado, que fallan parcialmente. Y en el momento en que
lo ves así, sus aterradores modos de falla dejan de ser misteriosos "problemas
de IA" y se convierten en los clásicos problemas de sistemas distribuidos que ya
conoces:

- **Cascadas.** Un agente alucina, le entrega su respuesta equivocada al
  siguiente como si fuera un hecho, y el error se compone a lo largo de la
  cadena: un mensaje corrupto propagándose por una tubería.
- **Bucles descontrolados.** Dos agentes se pasan una tarea de ida y vuelta, o
  uno reintenta para siempre, [inflando silenciosamente tu factura de API](https://www.digitalapplied.com/blog/multi-agent-orchestration-5-patterns-that-work):
  un reintento sin límite con el taxímetro corriendo.
- **Pérdida silenciosa de mensajes.** Un traspaso (handoff) desborda una
  ventana de contexto, información crítica se trunca sin que nadie lo note, y un
  agente río abajo actúa sobre medio mensaje: paquetes perdidos, sin que se
  levante ningún error.
- **Escalamiento muerto.** La ruta de "escalar a un humano" que todos diseñaron
  y nadie probó nunca se dispara de verdad: el manejador de errores que nunca
  estuvo en el happy path (camino feliz).

Esto no es fragilidad hipotética. Se ha medido que los sistemas multiagente
fallan en producción a tasas
[entre el 41% y casi el 87%](https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them),
con **las rupturas de coordinación por sí solas representando el 36.9%** de
todas las fallas: no es que los modelos sean tontos, es que la _coordinación_
está sin gestionar. La solución es traer la disciplina que los modos de falla
están pidiendo a gritos: contratos explícitos entre agentes, bucles y
reintentos acotados, estado que puedas observar, y rutas de error y
escalamiento que de verdad ejercites. Los problemas de sistemas distribuidos
quieren respuestas de sistemas distribuidos.

## No recurras a ella hasta que puedas nombrar el cuello de botella

Hay una segunda trampa, lo opuesto a tratar la coordinación como plomería:
recurrir a lo multiagente porque suena poderoso. Es poderoso, y es _caro_. La
coordinación tiene un costo real: los sistemas multiagente pueden quemar
[**15× los tokens** de una interacción de un solo agente](https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them),
más un gran sobrecosto solo por andar moviendo el estado de un lado a otro. El
sueño de 2024 de que "más agentes = más inteligencia" murió en su mayoría en
producción.

El consenso que lo reemplazó, en el que cinco grandes proveedores —
[Anthropic, OpenAI, Cognition, LangChain, AutoGen — convergieron](https://towardsdatascience.com/the-multi-agent-trap/),
es una regla útil: **la carga de la prueba recae sobre lo multiagente, no sobre
el agente único.** Empieza con un agente. Agrega otro solo cuando puedas nombrar
el cuello de botella específico que lo obliga: aislamiento de dominio, trabajo
genuinamente paralelo, una frontera de cumplimiento. "Se siente más sofisticado"
no es un cuello de botella. Cada agente que agregas compra capacidad y la paga
en coordinación, y ese intercambio solo vale la pena cuando algo concreto lo
exige.

## La verdadera falla es hacerlo por accidente

Junta las dos trampas y el problema real entra en foco. La mayoría de los
equipos no _deciden_ construir un sistema multiagente; lo _hacen crecer_. Le
pegan un agente a otro agente para tapar un hueco, luego otro, y la orquestación
emerge de forma implícita: ningún patrón elegido, ningún contrato, ningún manejo
de fallas, solo cableado acumulado que nadie diseñó. Así es exactamente como
terminas en la columna del 86%. Las consultas sobre sistemas multiagente se han
[disparado](https://towardsdatascience.com/the-multi-agent-trap/), pero la
coordinación está en su mayoría improvisada, y los sistemas distribuidos
improvisados fallan.

La solución no es un framework. Es una postura: trata la orquestación como un
artefacto de diseño de primera clase. Decide el patrón a propósito. Escribe el
contrato que cada agente honra. Decide qué pasa cuando un paso entra en bucle,
se trunca o falla, antes de que ocurra. El orquestador merece el mismo diseño
deliberado que le darías a cualquier sistema crítico, porque eso es lo que es.

Cuando construir se volvió barato y dividiste el trabajo en especialistas, no
eliminaste la arquitectura: la reubicaste. Antes vivía dentro del prompt de un
solo agente; ahora vive en la coordinación entre muchos. Diseña esa coordinación
como el sistema distribuido que es, a propósito, o mírala fallar como uno que
fingiste que era solo plomería.