Tenés un agente que busca vuelos. Otro que consulta el clima. Otro que aplica políticas corporativas. ¿Cómo los hacés trabajar juntos?
Strands Agents ofrece 5 patrones para coordinar múltiples agentes. Cada uno resuelve un problema distinto. La diferencia clave: quién decide el orden de ejecución. El modelo, los agentes entre sí, o vos en el código.
En este artículo explico cada patrón con código, muestro las diferencias con una tabla comparativa, y te doy un framework de decisión para elegir el correcto.
Todos los ejemplos usan Strands Agents (junio 2026). El código completo está en github.com/ricardoceci/curso-strands-agentcore-2026/tree/main/clase-3.
El caso de ejemplo: Travel Agent corporativo
Todos los ejemplos usan el mismo caso: un agente de viajes corporativo que coordina búsqueda de vuelos, consulta de clima, y generación de recomendaciones. Tres capacidades, tres agentes especializados.
from strands import Agent, tool
@tool
def search_flights(origin: str, destination: str, date: str) -> dict:
"""Search one-way flights via Duffel sandbox."""
# ... llamada a la API de Duffel
return {"route": f"{origin} -> {destination}", "offers": [...]}
@tool
def get_weather(city: str, target_date: str) -> dict:
"""Get weather forecast for a city on a specific date."""
# ... llamada a Open-Meteo
return {"city": city, "max_temp_c": 28, "precipitation_mm": 0.5}
Patrón 1: Agents as Tools
Un agente orquestador usa a otros agentes como si fueran tools. El orquestador decide cuándo delegar y a quién.
Cómo funciona
Pasás el sub-agente directo en el array de tools del agente principal. El SDK lo convierte a tool automáticamente. Cuando el modelo del orquestador decide que necesita esa capacidad, invoca al sub-agente. Todo corre en el mismo proceso Python.
Si necesitás más control, usá .as_tool() para customizar nombre y descripción, o el decorator @tool para wrappear la llamada completa.
# Sub-agente especializado en clima
weather_agent = Agent(
tools=[get_weather],
system_prompt="Sos un experto en clima. Respondé conciso.",
)
# El agente principal recibe al sub-agente directo en tools[]
travel_agent = Agent(
tools=[search_flights, weather_agent], # <-- el SDK lo convierte a tool
system_prompt="Sos un asistente de viajes corporativos.",
)
response = travel_agent("Vuelos de EZE a MIA el 20 de agosto. ¿Cómo va a estar el clima?")
Cuándo usarlo
Cuando tenés pocos sub-agentes con capacidades claramente distintas y querés que el modelo principal decida cuándo llamar a cada uno. Es el patrón más directo. Requiere la menor coordinación.
Cuándo NO usarlo
Si necesitás que los agentes se comuniquen entre sí (no solo con el orquestador) o si el orden de ejecución importa. En esos casos, Graph o Swarm son mejores opciones.
Patrón 2: Swarm
Un grupo de agentes que se coordinan autónomamente mediante handoffs (transferencias de control). Cada agente decide cuándo pasarle el trabajo a otro.
Cómo funciona
Strands equipa a cada agente del Swarm con herramientas de coordinación: un handoff tool para transferir control a otro agente, y un shared context que todos pueden leer. Los agentes deciden solos el orden de ejecución.
from strands.multiagent import Swarm
flight_agent = Agent(
name="flight_agent",
tools=[search_flights],
system_prompt="Buscás vuelos. Cuando termines, pasá el control al weather_agent.",
)
weather_agent = Agent(
name="weather_agent",
tools=[get_weather],
system_prompt="Consultás el clima en destino.",
)
summary_agent = Agent(
name="summary_agent",
system_prompt="Combinás vuelos y clima en una recomendación clara.",
)
swarm = Swarm([flight_agent, weather_agent, summary_agent])
response = swarm("Necesito viajar de Buenos Aires a Miami el 20 de agosto")
Cuándo usarlo
Cuando el problema se descompone en partes que distintos especialistas resuelven mejor, y el orden puede variar según la tarea. Swarm es ideal para problemas donde no sabés de antemano qué agente debería actuar primero.
Cuándo NO usarlo
Si necesitás un flujo de ejecución predecible y repetible. Swarm decide el orden en runtime. Dos ejecuciones del mismo prompt pueden seguir caminos distintos.
Patrón 3: Graph
Un grafo dirigido donde cada nodo es un agente y las aristas definen el flujo de ejecución. Vos definís la estructura, el framework ejecuta en orden.
Cómo funciona
GraphBuilder te da una API para definir nodos (agentes) y aristas (conexiones). El framework pasa la salida de un nodo como entrada al siguiente. Soporta grafos acíclicos (pipelines) y cíclicos (loops de refinamiento), lo que te da flexibilidad para implementar iteraciones de revisión entre agentes.
from strands.multiagent import GraphBuilder
graph = (
GraphBuilder()
.add_node("search", flight_agent)
.add_node("weather", weather_agent)
.add_node("summary", summary_agent)
.add_edge("search", "weather")
.add_edge("weather", "summary")
.build()
)
response = graph("Viaje de Buenos Aires a Miami, 20 de agosto")
Cuándo usarlo
Cuando el flujo de trabajo tiene un orden estricto que no debería cambiar. Por ejemplo: buscar vuelos primero, después consultar clima, después generar recomendación. Si el pipeline es el mismo cada vez, Graph es el patrón correcto.
Cuándo NO usarlo
Si necesitás flexibilidad en el orden de ejecución. Un Graph con muchos niveles de profundidad también suma latencia, porque cada nodo espera al anterior.
Patrón 4: Workflow
Un grafo de tareas con dependencias explícitas y ejecución paralela automática. Cada tarea se asigna a un agente con un system_prompt específico.
Cómo funciona
A diferencia de Graph (que opera con agentes como nodos), Workflow opera con tareas. Cada tarea tiene un ID, una descripción, dependencias, y prioridad. El framework resuelve el orden de ejecución, paraleliza lo que puede, y pasa resultados entre tareas.
from strands import Agent
from strands_tools import workflow
agent = Agent(tools=[workflow])
agent.tool.workflow(
action="create",
workflow_id="travel_planning",
tasks=[
{
"task_id": "search_flights",
"description": "Buscar los 5 vuelos más baratos de EZE a MIA el 20 de agosto",
"system_prompt": "Sos un experto en búsqueda de vuelos.",
"priority": 5,
},
{
"task_id": "check_weather",
"description": "Consultar el clima en Miami para el 20 de agosto",
"system_prompt": "Sos un experto en clima.",
"priority": 5,
},
{
"task_id": "generate_report",
"description": "Combinar vuelos y clima en un reporte ejecutivo",
"dependencies": ["search_flights", "check_weather"],
"system_prompt": "Sos un analista de viajes corporativos.",
"priority": 3,
},
],
)
agent.tool.workflow(action="execute", workflow_id="travel_planning")
En este ejemplo, search_flights y check_weather corren en paralelo (no tienen dependencias entre sí). generate_report espera a que ambos terminen.
Cuándo usarlo
Cuando tenés un proceso repetible con pasos que se pueden paralelizar. Workflow es el patrón más cercano a un pipeline de datos tradicional: dependencias explícitas, ejecución determinista, resultados que fluyen entre tareas.
Cuándo NO usarlo
Si necesitás que los agentes tomen decisiones sobre qué hacer a continuación. Workflow ejecuta exactamente lo que vos definiste, sin autonomía.
Patrón 5: A2A (Agent-to-Agent)
Un protocolo abierto (creado por Google, ahora en la Linux Foundation) para que agentes se comuniquen entre sí via HTTP. Los agentes pueden estar escritos en distintos frameworks, en distintos servidores.
Cómo funciona
Un agente se expone como servidor A2A con una Agent Card (metadata JSON en /.well-known/agent-card.json). Otro agente lo consume como cliente. La comunicación es HTTP/JSON.
Servidor:
from strands import Agent
from strands.multiagent.a2a import A2AServer
import uvicorn
weather_agent = Agent(
name="weather_agent",
description="Consulta pronósticos de clima por ciudad y fecha",
tools=[get_weather],
)
a2a_server = A2AServer(agent=weather_agent)
app = a2a_server.to_fastapi_app()
uvicorn.run(app, host="0.0.0.0", port=9000)
Cliente:
from strands import Agent
from strands.agent.a2a_agent import A2AAgent
remote_weather = A2AAgent(
agent_url="http://localhost:9000",
)
# Usarlo como nodo en un Graph
graph = (
GraphBuilder()
.add_node("search", flight_agent)
.add_node("weather", remote_weather)
.add_edge("search", "weather")
.build()
)
Cuándo usarlo
Cuando los agentes viven en servidores distintos, están escritos en frameworks distintos (Strands, LangGraph, CrewAI), o pertenecen a equipos u organizaciones distintas. A2A es el único patrón que cruza la frontera del proceso local.
Cuándo NO usarlo
Si todos los agentes corren en el mismo proceso. A2A agrega latencia de red (50-1000ms por llamada, según benchmarks de la comunidad). Para comunicación local, los otros patrones son órdenes de magnitud más rápidos.
Comparación entre los 5 patrones Multi-Agent
| Aspecto | Agents as Tools | Swarm | Graph | Workflow | A2A |
|---|---|---|---|---|---|
| Quién decide el orden | El modelo orquestador | Los agentes (handoffs) | Vos (aristas) | Vos (dependencias) | N/A (protocolo) |
| Comunicación | In-process | In-process | In-process | In-process | HTTP/JSON |
| Latencia | Microsegundos | Microsegundos | Microsegundos | Microsegundos | 50-1000ms |
| Ejecución paralela | No nativa | Decidida por agentes | Soportada | Automática | N/A |
| Grafos cíclicos | No | No | Sí | No | No |
| Cross-framework | No | No | No | No | Sí |
| Composable | Sí (como tool) | Sí (nodo en Graph) | Sí (nodo en otro Graph) | No | Sí (nodo en Graph) |
Framework de decisión
Cuando tenés que elegir un patrón, seguí estas preguntas:
¿Los agentes están en el mismo proceso?
Si no: A2A (es el único que cruza la red).
¿El orden de ejecución importa?
Si sí, ¿es siempre el mismo?: Graph (estructura fija).
Si sí, ¿con tareas paralelas?: Workflow (dependencias + paralelismo).
¿Los agentes necesitan decidir solos quién actúa?
Si sí: Swarm (handoffs autónomos).
¿Es delegación directa de un orquestador a especialistas?
Si sí: Agents as Tools (el más directo).
¿Ninguno encaja perfecto?
Los patrones se componen entre sí. Un Graph puede tener un Swarm como nodo. Un agente con tools puede incluir un A2AAgent remoto. Strands te deja mezclar patrones sin restricciones.
Preguntas frecuentes
¿Swarm usa A2A internamente?
No. Swarm usa llamadas de función Python dentro del mismo proceso. La confusión viene porque ambos involucran "comunicación entre agentes", pero Swarm es local (microsegundos) y A2A es remoto (HTTP).
¿Graph soporta ejecución condicional?
Sí. Las aristas pueden tener condiciones que se evalúan en runtime. Esto te da grafos que se comportan como árboles de decisión: según el output de un nodo, el flujo toma un camino u otro.
¿Puedo combinar patrones?
Sí, y es una de las fortalezas de Strands. Un Swarm puede vivir como nodo dentro de un Graph. Un Graph puede usar un A2AAgent remoto como nodo. Un agente con tools puede incluir otro agente como tool. La composición es libre.
¿Cuál es el más eficiente en tokens?
Agents as Tools y Graph consumen menos tokens porque la coordinación es determinista. Swarm puede consumir más porque los agentes razonan sobre a quién pasarle el control. A2A agrega overhead de protocolo HTTP.
¿Workflow reemplaza a Graph?
No. Workflow es una tool de Strands (viene de strands-agents-tools), mientras que Graph es un orquestador nativo del SDK. Workflow opera con tareas, Graph opera con agentes. Si necesitás que cada nodo sea un agente completo con su propio system prompt y tools, usá Graph. Si necesitás un pipeline de tareas con dependencias, usá Workflow.
Conclusión
Los 5 patrones no compiten entre sí. Cada uno resuelve una necesidad distinta de coordinación. La clave es empezar con el más directo que funcione para tu caso (probablemente Agents as Tools) y escalar hacia patrones más complejos cuando lo necesites.
Si querés ver estos patrones implementados en vivo con el caso del Travel Agent corporativo, están todos en el repositorio del curso:
github.com/ricardoceci/curso-strands-agentcore-2026
Y si querés aprender Strands desde cero, el curso completo (gratuito, en español) está en ricardoceci.dev.
Top comments (0)