Idea en 30 segundos
Orchestration Topologies es una forma de organizar la interaccion entre varios agentes en un mismo sistema.
No se trata de "prompts mas inteligentes", sino de estructura: quien recibe la tarea, quien ejecuta subtareas y como vuelve el resultado.
Cuando se necesita: cuando un agente ya no alcanza por si solo y se requieren varios roles o equipos de agentes.
El LLM puede proponer un plan, pero la topologia de orquestacion define el camino de ejecucion seguro y predecible.
Problema
Cuando en el sistema aparecen varios agentes sin una topologia clara, el proceso se vuelve caotico rapidamente.
Problemas tipicos:
- no esta claro que agente es responsable de que;
- las subtareas se duplican o se pierden;
- los agentes "rebotan" la tarea entre ellos sin terminarla;
- es dificil controlar stop conditions y limites globales a nivel de todo el sistema;
- es dificil localizar un error porque no hay una ruta explicita de ejecucion.
Como resultado, el sistema consume mas recursos y bajan la calidad y la previsibilidad.
Solucion
Agregar Orchestration Topology como esquema explicito de coordinacion para un sistema multi-agent concreto: quien orquesta, quien ejecuta, como ocurren los handoff y cuando todo se detiene.
Esto da una ruta transparente de la tarea desde el inicio hasta el resultado final.
Analogia: como una red de transporte publico.
Un pasajero puede ir por rutas distintas, pero hay nodos claros, transbordos y estacion final.
Orchestration Topology define del mismo modo la ruta de la tarea entre agentes.
Como funcionan Orchestration Topologies
Orchestration Topology es un esquema explicito de coordinacion entre un coordinador y un equipo de agentes, que define el orden de handoff de subtareas y agregacion de resultados.
Runtime funciona dentro de cada agente, por eso no se muestra como nodo separado en el diagrama.
Descripcion del flujo completo: Decompose → Route → Execute → Merge → Stop
Decompose
El coordinador divide la tarea en subtareas o decide que no hace falta dividir.
Route
La topologia decide a quien pasar cada subtarea: a un agente concreto o a un grupo de agentes.
Execute
Cada agente ejecuta su parte por Runtime y devuelve un resultado estructurado.
Merge
El coordinador fusiona resultados, elimina conflictos y forma una respuesta integral.
Stop
El sistema finaliza por stop conditions: resultado listo, limites de pasos/tiempo o error.
Este ciclo da una ruta controlada de la tarea entre agentes y reduce el caos en un sistema multi-agent.
Orchestration Topologies tipicas
| Topologia | Cuando elegir | Que considerar |
|---|---|---|
| Centralized | Se necesita control simple y un punto unico de decision | El coordinador puede volverse cuello de botella |
| Hierarchical | Hay muchos equipos/dominios y se necesita coordinacion multinivel | Es mas dificil depurar rutas entre niveles |
| Pipeline | Hay una secuencia clara de pasos: recopilacion -> analisis -> respuesta | Mayor latencia total si una etapa se retrasa |
| Parallel | Las subtareas son independientes y pueden ejecutarse en paralelo | Se necesitan reglas de merge solidas para resultados en conflicto |
| Hybrid | Distintos tipos de tareas requieren rutas distintas en un mismo sistema | La mas flexible, pero tambien la mas dificil de mantener |
Guia rapida de eleccion:
- Centralized - cuando se necesita control simple y transparente con un solo coordinador.
- Pipeline - cuando cada paso siguiente depende del anterior.
- Parallel - cuando las subtareas son independientes y la velocidad importa por ejecucion simultanea.
- Hierarchical - cuando hay varios niveles de coordinacion (direccion equipo/subequipo).
- Hybrid - cuando en un sistema se necesitan esquemas de ruteo distintos para tareas distintas.
En codigo se ve asi
class OrchestrationTopology:
def __init__(self, coordinator, agents, max_handoffs=12):
self.coordinator = coordinator
self.agents = agents
self.max_handoffs = max_handoffs
def run(self, task):
queue = [task]
results = []
handoffs = 0
while queue and handoffs < self.max_handoffs:
current = queue.pop(0)
plan = self.coordinator.route(current)
target = plan["agent"]
if target not in self.agents and target != "finish":
return self.coordinator.fallback(results, reason="unknown_agent")
if target == "finish":
return self.coordinator.merge(results)
outcome = self.agents[target].execute(plan["payload"])
results.append(outcome)
queue.extend(self.coordinator.next_steps(outcome))
handoffs += 1
return self.coordinator.fallback(results, reason="handoff_limit_reached")
Como se ve en ejecucion
Solicitud: "Prepara una comparacion de 3 CRM y da una recomendacion para pequena empresa"
Step 1
Coordinator: Decompose -> [recopilacion de datos, evaluacion de costos, recomendacion final]
Topology: Route -> Agent A (recopilacion de datos), Agent B (evaluacion de costos)
Step 2
Agent A: devuelve comparacion de funciones
Agent B: devuelve comparacion de precios y limitaciones
Coordinator: Merge -> pasa a Agent C (recomendacion final)
Step 3
Agent C: forma la respuesta para el usuario
Topology: Stop -> final_answer + traza
Orchestration Topology no reemplaza a los agentes, organiza su trabajo conjunto en un proceso predecible.
Cuando encaja - y cuando no
Orchestration Topologies se necesitan cuando las tareas se resuelven mejor con un equipo de agentes. Para tareas simples one-shot suele ser excesivo.
Encaja
| Situacion | Por que encaja Orchestration Topologies | |
|---|---|---|
| ✅ | La tarea tiene varios dominios distintos (investigacion, analisis, resumen) | La topologia distribuye subtareas entre agentes especializados. |
| ✅ | Se necesita handoff controlado entre agentes | Reglas explicitas de ruteo y stop conditions eliminan transferencias aleatorias. |
| ✅ | Se necesita observabilidad de la ruta y de las razones de parada | La topologia da una traza transparente: quien recibio, ejecuto y devolvio que. |
No encaja
| Situacion | Por que Orchestration Topologies no encajan | |
|---|---|---|
| ❌ | Tarea one-shot que un solo agente resuelve de forma fiable | La topologia multiagente agregara complejidad y latencia innecesarias. |
| ❌ | Todos los pasos estan codificados de forma determinista en el backend flow sin decisiones autonomas | Normalmente basta un workflow engine clasico o la logica de negocio del servicio. |
En estos casos, a menudo basta una llamada simple:
response = single_agent.run(task)
Problemas y fallos tipicos
| Problema | Que pasa | Como prevenir |
|---|---|---|
| Routing loop entre agentes | La subtarea "da vueltas" continuamente y no termina | max_handoffs, route-guard y stop conditions |
| Cuello de botella en el coordinador | Un nodo frena todo el pipeline | Paralelizacion, colas y escalado del coordinador |
| Conflicto de resultados | Diferentes agentes devuelven conclusiones contradictorias | Reglas explicitas de merge, prioridad de fuentes y validacion final |
| Fallo parcial de un agente | Una rama falla y bloquea todo el run | Timeout, fallback-agent y degradacion sin detener todo el proceso |
| Unowned task | Se crea una subtarea, pero no tiene agente responsable | Route validation + explicit owner assignment |
La mayoria de estos problemas se resuelve con ruteo explicito, limites de handoff y traza transparente de cada rama.
Como se combina con otros patrones
Orchestration Topologies describen la arquitectura de interaccion entre agentes y no reemplazan otras capas del sistema.
- Agent Runtime - Runtime ejecuta los pasos de cada agente, y la topologia define la ruta entre agentes.
- Tool Execution Layer - cada agente en la topologia llama herramientas por un execution layer controlado.
- Memory Layer - la topologia define que memoria es compartida y cual es local para un agente concreto.
- Policy Boundaries - policy rules verifican transiciones y acciones permitidas en cada rama.
En otras palabras:
- Agent Patterns define como piensa un agente concreto
- Orchestration Topologies define como varios agentes ejecutan una tarea juntos
En que se diferencia de Orchestrator Agent
| Orchestrator Agent | Orchestration Topologies | |
|---|---|---|
| Nivel | Patron de agente independiente (rol de un coordinador) | Esquema arquitectonico para todo el sistema multi-agent |
| Que describe | El comportamiento del agente coordinador | Rutas, nodos, handoff y reglas de interaccion entre agentes |
| Cuando es suficiente | Cuando basta un coordinador | Cuando se necesitan esquemas distintos: centralizado, jerarquico, hibrido |
| Resultado principal | Coordinacion organizada desde un agente | Interaccion predecible y escalable de todo el equipo de agentes |
Orchestrator Agent es el rol de un agente.
Orchestration Topologies es el mapa arquitectonico de todo el sistema de agentes.
Resumen
Orchestration Topologies:
- define la ruta de la tarea entre varios agentes
- define reglas de handoff, merge y stop conditions
- reduce el caos en ejecucion multi-agent
- hace transparentes la traza y las razones de parada
FAQ
Q: Como elegir entre Pipeline, Parallel y Hierarchical topology?
A: Si los pasos dependen entre si - Pipeline. Si las subtareas son independientes - Parallel. Si hay varios niveles de coordinacion - Hierarchical.
Q: Se puede empezar con una topologia simple y complicarla despues?
A: Si. A menudo se empieza con esquema centralizado y luego se agrega jerarquia o ramas hibridas cuando crecen las tareas.
Q: La topologia reemplaza policy rules?
A: No. La topologia responde por ruta y coordinacion, y Policy Boundaries por que acciones y transiciones estan permitidas.
Q: Que elegir: Orchestrator Agent o Orchestration Topology?
A: No son opciones excluyentes. Orchestrator Agent puede ser un nodo dentro de la topology elegida.
Que Sigue
La topologia explica como se mueve una tarea por el sistema. Despues, mira como volver ese movimiento controlado y seguro:
- Hybrid Workflow Agent - como combinar etapas fijas con decisiones del agente.
- Agent Runtime - como ejecutar pasos con razones de parada controladas.
- Human-in-the-Loop Architecture - donde una persona debe conservar la autoridad final de decision.
- Production Stack - como escalar la topologia a operaciones de produccion.