Swarm: el experimento de OpenAI para agentes multi-rol

Enjambre de puntos luminosos conectados representando agentes coordinados

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. En un momento en que medio ecosistema discute si los agentes autónomos son el siguiente salto o una moda, el gesto tiene peso.

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 otra dirección: 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.

Diferencias con CrewAI y LangGraph

CrewAI parte de la metáfora organizacional. Hay roles, hay tareas asignadas a esos roles, hay un flujo que puede ser secuencial o jerárquico, y todo ello se declara por adelantado. Es una herramienta excelente cuando el problema ya se entiende en términos de reparto de responsabilidades estables: un redactor, un revisor, un publicador. El precio es que reconfigurar el flujo exige reconfigurar la crew.

LangGraph va al otro extremo y ofrece el grafo como primitiva. Cada nodo es una función, cada arista una transición, y el estado es un objeto tipado que atraviesa el grafo. Esto habilita patrones imposibles de expresar limpiamente en CrewAI: ciclos controlados, puntos de pausa para intervención humana, reanudación desde checkpoint. Es la opción natural cuando el flujo es largo, auditable y tiene que sobrevivir a caídas.

Swarm renuncia a ambas cosas. No hay grafo, no hay roles declarados, no hay persistencia. Cada llamada a client.run() es stateless: se le pasa el historial completo de mensajes y el agente actual, y se devuelve el resultado. Esa austeridad es el punto. Te obliga a pensar en el handoff como una decisión del modelo, no como un arco de un diagrama.

Ejemplo mínimo

El ejemplo canónico es un triage que deriva al especialista adecuado. La función de transferencia devuelve otro agente, y Swarm interpreta ese retorno como cambio de control.

from swarm import Agent, Swarm

def transfer_to_specialist():
    return specialist_agent

triage = Agent(
    name="Triage",
    instructions="Enruta al cliente hacia el agente adecuado.",
    functions=[transfer_to_specialist],
)

specialist_agent = Agent(
    name="Specialist",
    instructions="Resuelve cuestiones técnicas de producto.",
)

client = Swarm()
response = client.run(
    agent=triage,
    messages=[{"role": "user", "content": "Mi dispositivo no arranca"}],
)

Lo interesante no es el código sino lo que no aparece en él. No hay registro de agentes, no hay router configurado, no hay tabla de rutas. El enrutamiento ocurre porque el modelo, leyendo las instrucciones del triage y viendo la función disponible, decide llamarla.

Lo que esta simplicidad cuesta

Swarm paga un precio proporcional a lo que ahorra en abstracciones. No persiste estado entre llamadas: cada ejecución parte del historial de mensajes y nada más. No tiene streaming en su primera versión, así que las respuestas llegan en lote. El manejo de errores es mínimo y la integración con modelos que no sean de OpenAI exige envolver un cliente compatible a mano. En producción, cualquiera de esas ausencias se convierte en un incidente el primer mes.

Tampoco se apoya en la Assistants API. Habría sido la elección obvia para heredar hilos, herramientas y persistencia, pero la Assistants API es demasiado pesada para lo que Swarm quiere transmitir. Swarm se queda en Chat Completions porque esa es la superficie más pequeña posible.

Para qué sirve realmente

La utilidad de Swarm es doble. Como material educativo, es probablemente la mejor introducción pública que existe al patrón de handoffs: menos de quinientas líneas, legibles de principio a fin, con ejemplos que cubren atención al cliente, reservas aéreas y escalado de soporte. Quien quiera entender cómo OpenAI piensa la coordinación entre agentes tiene ahí la respuesta sin traducción.

Como banco de pruebas, también funciona. Para un prototipo de fin de semana, para una demo interna, para validar si un flujo conversacional tiene sentido antes de invertir en infraestructura seria, Swarm es más rápido que cualquiera de sus alternativas. Cuando el prototipo convence, la migración a CrewAI, LangGraph o a la futura SDK de agentes que OpenAI ya está preparando es un ejercicio de traducción, no de rediseño.

Lo que no debe hacerse es poner Swarm delante de usuarios reales. La advertencia del README no es decorativa. Sin persistencia, sin streaming y sin garantías operativas, cualquier despliegue serio termina reimplementando esas capas, y llegado ese punto, lo sensato es elegir un framework que ya las traiga.

Swarm es, en el fondo, una carta abierta. OpenAI está diciendo que el futuro de los agentes pasa por modelos más capaces y frameworks más ligeros, no al revés. Habrá que ver si la industria le sigue, pero el gesto de publicar quinientas líneas honestas, con sus limitaciones impresas a fuego, ya es una contribución. Leer ese código ahora, antes de que llegue su sucesor en producción, es una de las inversiones de tiempo más rentables que un desarrollador de agentes puede hacer este otoño.

Entradas relacionadas