Swarm: el experimento de OpenAI para agentes multi-rol

Actualizado: 2026-05-03

El 10 de octubre de 2024, OpenAI publicó en GitHub un repositorio llamado Swarm con una advertencia inusual en letras grandes: no usar en producción. Esa frase, repetida en el README y en los ejemplos, no es humildad cortés —es una declaración de intenciones. Swarm no pretende competir con CrewAI, con LangGraph ni con su propia Assistants API. Es un laboratorio abierto donde el equipo de OpenAI deja ver, en menos de quinientas líneas de Python, cómo piensan ellos mismos la coordinación entre agentes.

Puntos clave

• Swarm reduce el vocabulario de sistemas multi-agente a dos conceptos: agentes y handoffs.
• El enrutamiento emerge del modelo, no de un grafo explícito ni de un planificador centralizado.
• Sus menos de 500 líneas de Python hacen el diseño completamente legible y el código fácil de adaptar.
• No es una solución de producción: carece de estado persistente, reintentos, observabilidad y manejo de errores robusto.
• La apuesta filosófica es que la coordinación no necesita infraestructura pesada si los modelos son capaces.

Por qué un framework experimental, y por qué ahora

Los frameworks multi-agente llevan un año largo acumulando abstracciones. CrewAI habla de crews, tasks y processes. LangGraph modela máquinas de estado con nodos, aristas y checkpointers. Cada capa resuelve problemas reales, pero también impone una ontología que el desarrollador debe aprender antes de escribir la primera línea útil.

Swarm responde en la dirección contraria: reducir el vocabulario a dos ideas y ver hasta dónde se llega.

Las dos ideas son agentes y handoffs. Un agente es una configuración con instrucciones y funciones. Un handoff es, literalmente, una función que devuelve otro agente. Cuando el modelo decide llamar a esa función, el control pasa al agente devuelto y la siguiente ronda de conversación ocurre bajo sus instrucciones. No hay grafo explícito, no hay máquina de estados, no hay planificador. El enrutamiento emerge del hecho de que los modelos, si se les dan funciones bien nombradas, saben cuándo invocarlas.

Es una apuesta filosófica: la coordinación entre agentes no necesita infraestructura pesada si los modelos que hay detrás son suficientemente capaces. Con GPT-4o como motor, OpenAI está diciendo que prefiere confiar en el razonamiento del modelo antes que en el andamiaje del framework.

Estructura de Swarm

El código central de Swarm cabe en un solo fichero. El cliente gestiona el bucle de conversación: envía el mensaje al modelo, recibe la respuesta, ejecuta las llamadas a herramientas y repite. La única adición sobre la API estándar de chat es el concepto de Agent como objeto Python y la lógica de handoff:

from swarm import Swarm, Agent

client = Swarm()

soporte = Agent(
    name="Soporte",
    instructions="Resuelve problemas técnicos. Si el problema es de facturación, transfiere a Facturación.",
)

facturacion = Agent(
    name="Facturación",
    instructions="Gestiona preguntas sobre facturas y pagos.",
)

def transferir_a_facturacion():
    return facturacion

soporte.functions = [transferir_a_facturacion]

response = client.run(
    agent=soporte,
    messages=[{"role": "user", "content": "Tengo un cargo incorrecto"}],
)

Cuando el modelo de soporte decide que debe transferir, llama a transferir_a_facturacion(), Swarm recibe el agente devuelto y continúa la conversación con las instrucciones de facturacion. No hay más framework que eso.

Diferencias con CrewAI y LangGraph

Las tres aproximaciones reflejan filosofías distintas sobre dónde debe vivir la inteligencia de coordinación.

CrewAI externaliza la coordinación en un Manager Agent que distribuye tareas. Es el modelo más próximo a una jerarquía organizativa tradicional: útil cuando los roles son estables y las tareas bien definidas, pero añade una capa de LLM llamadas extra para cada decisión de routing.

LangGraph modela el flujo como un grafo dirigido con nodos y aristas explícitas. La ventaja es la previsibilidad y la capacidad de hacer debugging visual del flujo; la desventaja es que requiere diseñar el grafo de antemano, lo que no siempre es posible para flujos dinámicos.

Swarm elimina ambas capas y confía en que el modelo de base, con instrucciones claras y funciones bien nombradas, tome las decisiones de routing en cada turno. Es más frágil —un modelo menos capaz puede tomar decisiones de handoff incorrectas— pero es también más transparente y más fácil de razonar sobre su comportamiento.

La Assistants API de OpenAI ya cubre casos de producción con estado persistente y threads gestionados. Swarm existe en el espacio conceptual, no para reemplazarla.

Patrones que emergen de Swarm

Aunque Swarm es experimental, varios patrones interesantes emergen de sus ejemplos:

• Triage agent: un agente inicial que analiza la petición y la transfiere al especialista correcto. Es el patrón más simple y el que funciona mejor con modelos menos potentes.
• Escalation chain: agentes en cadena donde cada uno puede escalar al siguiente cuando supera su competencia, similar a un sistema de tickets de soporte.
• Parallel agents simulados: varios agentes que procesan aspectos distintos de una petición y un agente sintetizador que combina las respuestas.

El límite de todos estos patrones es el mismo: sin estado persistente entre sesiones, sin reintentos automáticos, sin observabilidad integrada, son demostraciones de concepto —no sistemas productivos. Para sistemas multi-agente en producción con observabilidad de trazas, la Assistants API o frameworks maduros como LangGraph son la elección apropiada.

Valor real de Swarm

El valor real de Swarm no es el framework en sí —es el código. Leer las quinientas líneas de implementación es una de las mejores formas de entender qué hace realmente un framework de agentes por debajo de sus abstracciones: gestionar el historial de mensajes, ejecutar las llamadas a herramientas, manejar el bucle de conversación. Una vez que lees el código, el “misterio” de cómo funcionan los frameworks más complejos se reduce considerablemente.

También abre una conversación sobre si la complejidad de los frameworks actuales está justificada. Para muchos casos de uso, la respuesta de Swarm —“confía en el modelo y dale buenas funciones”— puede ser suficiente. Para otros, el estado persistente, los reintentos y la observabilidad de LangGraph o CrewAI no son opcionales. El mérito de Swarm es forzar esa conversación con código en lugar de con argumentos.

Conclusión

Swarm es un paper ejecutable, no un framework de producción. Su contribución más valiosa es demostrar que la coordinación entre agentes puede ser sorprendentemente sencilla cuando el modelo base es capaz, y que la mayor parte de la complejidad de los frameworks actuales existe para compensar la fragilidad de los modelos o para añadir características que Swarm deliberadamente omite. Para equipos que quieren entender cómo funcionan los sistemas multi-agente antes de adoptar un framework, leer el código de Swarm es el mejor punto de partida.