flowchart TD
o["Orquestador"] --> w1["Trabajador 1"]
o --> w2["Trabajador 2"]
o --> w3["Trabajador 3"]
w1 --> s["Síntesis"]
w2 --> s
w3 --> s
classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
classDef control fill:#d7eddc,stroke:#4a9463,stroke-width:1.5px,color:#1c4a2e
class o,s modelo
class w1,w2,w3 control
13 Orquestación y frameworks
Cuando un solo agente con su lista de herramientas se queda corto, la respuesta habitual es multiplicar agentes. A veces es la correcta. Muchas veces es una forma elegante de multiplicar los problemas, así que conviene saber qué compra cada patrón y qué cuesta.
13.1 Los patrones que se repiten
Encadenado. Salida de uno, entrada del siguiente. No es un sistema multiagente, es un flujo de trabajo, y es la opción correcta muchas más veces de las que se admite. Predecible, barato y depurable.
Enrutado. Un clasificador decide a qué especialista va cada petición. Rinde mucho cuando el tráfico es heterogéneo y los casos son distinguibles: cada especialista lleva su prompt corto y su juego reducido de herramientas, en lugar de un prompt gigante que lo intenta todo. El clasificador puede ser un modelo pequeño y barato.
Paralelo. Varias llamadas simultáneas cuyos resultados se agregan. Sirve para trocear (analizar veinte documentos a la vez) y para votar (tres opiniones sobre lo mismo y mayoría). Corta latencia a cambio de coste.
Orquestador y trabajadores. Un agente central descompone la tarea, reparte a subagentes y monta el resultado. Es el patrón que la gente tiene en la cabeza cuando dice “multiagente”.
Evaluador y generador. Uno produce, otro critica con criterios explícitos, el primero corrige. Funciona bien cuando el criterio de calidad se puede escribir; se convierte en una discusión estéril y cara cuando no.
13.2 Lo que compra el reparto: contexto limpio
La razón de fondo para partir el trabajo no es “especialización” en abstracto. Es la cuarta operación sobre el contexto: aislar.
Un agente que investiga veinte fuentes acumula veinte respuestas de herramienta en su ventana, y para cuando llega a la última ya ha perdido de vista la primera. Si cada subagente investiga una fuente y devuelve solo su conclusión, el orquestador trabaja con veinte párrafos en lugar de con veinte documentos. El sistema multiagente es, en el fondo, un mecanismo de compresión de contexto.
Esa es también la forma de saber si merece la pena: si los subagentes van a devolver casi todo lo que recibieron, no habéis aislado nada y solo habéis añadido latencia y llamadas.
AdvertenciaLo que cuesta de verdad
Antes de dibujar la arquitectura con seis agentes conviene tener presente el precio:
- Los tokens se multiplican. Cada subagente arrastra su propio prompt de sistema y su propio historial. Un sistema multiagente puede consumir un orden de magnitud más que una sola llamada bien planteada.
- Los errores se propagan y no se anulan. Cinco pasos al 90% de fiabilidad dan un 59%. La intuición de que “entre varios se corrigen” es falsa salvo que exista un verificador objetivo.
- Depurar se vuelve arqueología. Sin trazas, averiguar en qué eslabón se torció algo es desesperante.
- La latencia se acumula, salvo en las ramas paralelas.
La regla que aplico: un agente bien construido antes que tres mal repartidos. La complejidad se añade cuando se ha demostrado que hace falta, no cuando se sospecha.
TipLos tres precios, medidos
El primer cuaderno de este capítulo monta las dos arquitecturas sobre el mismo caso y las mide. El reparto ahorra contexto de verdad, en torno a un tercio de los tokens, y ese ahorro se multiplica por el número de vueltas del bucle. Hasta ahí, lo esperado.
Lo que no se espera es el resto. El acierto sube muy poco, y al medir por separado cada pieza aparece el motivo: el sistema se queda clavado en la fiabilidad de su enrutador, muy por debajo de lo que dan los especialistas cuando se les manda lo suyo. Un sistema en cadena no puede superar a su peor eslabón, y aquí toda la ganancia del reparto se la come el que decide.
De propina, el cuaderno enseña una votación en la que los tres votantes se equivocan igual y en la que votar solo multiplica por tres el precio del mismo error.
13.3 Frameworks
El mercado se ha estabilizado en unas pocas familias con filosofías distintas. Lo importante no es cuál gana, es entender qué asume cada una y cuánto acoplamiento acepta uno a cambio.
| Familia | Ejemplos | Idea central | Encaja cuando |
|---|---|---|---|
| De grafo | LangGraph, LangChain | El flujo es un grafo explícito con estado | Hace falta control fino, ciclos y persistencia |
| De los proveedores | Agents SDK de OpenAI, ADK de Google, Claude Agent SDK de Anthropic, Strands de AWS, Microsoft Agent Framework | Abstracción ligera sobre el bucle | Se va a usar ese proveedor y se quiere lo mínimo |
| Tipada | Pydantic AI | Contratos y validación en la frontera | El equipo viene de Python con tipos y quiere probar |
| De roles | CrewAI, AutoGen | Agentes con rol que conversan | Prototipos rápidos, demostraciones |
| Ligera y multimodal | Agno, smolagents | Poca ceremonia, arranque y memoria mínimos | Importa la latencia por agente o hay muchos a la vez |
| Declarativa | DSPy | Se describe la tarea, no el prompt; un optimizador lo busca | Hay conjunto de evaluación y se quiere dejar de retocar texto a mano |
| De JavaScript | Mastra, Vercel AI SDK | El agente vive donde vive la aplicación web | El equipo es de front y no quiere un servicio Python aparte |
| Sin framework | Nada | El bucle a mano, unas 100 líneas | Se quiere entender qué pasa y no depender de nadie |
La fila declarativa merece una explicación aparte porque no compite con las demás, sino que ataca otro problema. Mientras los otros frameworks organizan el flujo, DSPy organiza el prompt: se declara qué entra y qué sale, y un optimizador busca la formulación y los ejemplos que mejor rinden contra un conjunto de evaluación. Es la respuesta más seria que existe al bucle de la desesperación, y su precio de entrada es justo lo que casi nadie tiene: el conjunto de evaluación. Sin él no hay nada que optimizar.
NotaEsta tabla caduca antes que el resto del capítulo
Los nombres de la segunda columna son los de 2026 y algunos no llegarán a 2028. Lo que sí aguanta son las familias: alguien tendrá que resolver el estado de un flujo con ciclos, alguien querrá la abstracción mínima de su proveedor y alguien preferirá escribir el bucle.
Si al leer esto un nombre ya no existe, mirad qué ocupa su casilla en lugar de buscar el sustituto exacto. Y si aparece una familia nueva que no encaja en ninguna fila, esa es la señal de que algo ha cambiado de verdad.
La última fila merece defensa, porque suele descartarse por prejuicio. El bucle de un agente es corto: llamar al modelo, mirar si pide una herramienta, ejecutarla, devolver el resultado, repetir. Escribirlo una vez enseña más sobre el sistema que cualquier tutorial y deja el control completo sobre lo que entra en el contexto, que es justo lo que más importa. Para casos sencillos es, a menudo, la mejor decisión de ingeniería.
Lo que sí conviene no reescribir: reintentos con criterio, persistencia del estado, trazas y ejecución duradera de procesos largos. Ahí un framework maduro ahorra semanas.
TipElegid pensando en la salida
El coste real de un framework no es aprenderlo, es abandonarlo. Antes de comprometerse, tres preguntas:
- ¿Puedo ver y modificar el contexto exacto que se envía? Si la respuesta es no, tarde o temprano vais a estar depurando a ciegas.
- ¿Emite trazas en un formato estándar? Las convenciones de OpenTelemetry para IA generativa son hoy el mínimo exigible.
- ¿Cuánto código habría que reescribir para cambiar de modelo o de framework? Si la lógica de negocio vive dentro de las abstracciones del framework, la respuesta es “todo”.
AdvertenciaLa tercera pregunta, respondida por las malas
El segundo cuaderno de este capítulo monta el mismo agente tres veces, y la comparación acaba en otro sitio del previsto. Al enchufar un modelo local al atajo que trae el framework para montar agentes, no salta ninguna excepción: la lista de llamadas a herramientas llega vacía y el modelo contesta de memoria, con los marcadores de la plantilla dentro de la respuesta.
Un agente montado así parece funcionar. Contesta, suena razonable y nunca consulta nada. Nadie se entera hasta que alguien comprueba una fecha.
La lección que deja es la que no aparece en ningún tutorial: el acoplamiento de un framework no está en su API, sino en qué modelos ha probado de verdad. Mientras se use un proveedor grande todo encaja; en cuanto se sale de ahí aparece el trabajo que la abstracción prometía ahorrar.
Declarando el grafo a mano y metiendo dentro la propia función de llamada al modelo, el mismo framework sí aporta lo que se le pide: estado persistente, historial recorrible y flujo explícito. Que es, exactamente, la lista de “lo que sí conviene no reescribir” de más arriba.
13.4 Cuando los agentes son de otros: A2A
MCP resuelve cómo un agente habla con herramientas. Queda cómo habla con otro agente que no controlamos, hecho por otro equipo o por otra empresa, con otro framework. (Y queda una tercera frontera, la de cómo habla con la persona, que tiene capítulo propio porque da para más de lo que parece.)
Ese es el hueco que ocupa A2A (Agent2Agent), donado a la Linux Foundation y con adopción amplia. Su pieza central es la agent card: un documento donde un agente declara qué sabe hacer, cómo se le invoca y cómo se autentica. Con eso, un agente puede descubrir a otro y delegarle una tarea sin que ninguno sepa nada de las tripas del otro.
flowchart LR
a1["Nuestro agente"] -->|MCP| t["Herramientas<br/>internas"]
a1 -->|A2A| a2["Agente<br/>de un tercero"]
classDef modelo fill:#e6ddf5,stroke:#7457bd,stroke-width:1.5px,color:#332757
classDef herramienta fill:#fae3c8,stroke:#bf7f28,stroke-width:1.5px,color:#573809
classDef externo fill:#ececf0,stroke:#868d9c,stroke-width:1.5px,color:#2b2f3a
class a1 modelo
class t herramienta
class a2 externo
En 2026 esto es más promesa que realidad cotidiana: la interoperabilidad entre organizaciones tropieza con la identidad, la responsabilidad y la facturación mucho antes que con el protocolo. Vale la pena seguirlo de cerca sin construir sobre ello lo que hay que entregar este trimestre.
ImportanteDelegar en un agente ajeno es confiar en un extraño
Nótese el color del diagrama: el agente de un tercero es gris. No controlamos su modelo, ni sus instrucciones, ni lo que le hayan inyectado. Todo lo que devuelva es contenido no confiable que entra en nuestro contexto, con las implicaciones que veremos en seguridad.
13.5 Los cuadernos
Este capítulo tiene dos, uno por cada mitad.
El de orquestación coge el problema que dejó abierto el capítulo anterior, el agente con doce herramientas que se atragantaba, y prueba a repartirlas entre tres especialistas con un enrutador delante. Mide las dos arquitecturas y además el techo de la segunda: qué daría si el enrutador nunca se equivocase. Esa tercera medida es la que enseña dónde está el problema de verdad.
El de frameworks monta el mismo agente tres veces: a mano, con el atajo que trae el framework y con el grafo declarado explícitamente. Termina contestando las tres preguntas del recuadro de más arriba con código delante en lugar de con impresiones, y con una respuesta a la tercera que no esperaba encontrar.
Y queda por desarrollar el primero de los cinco patrones, el encadenado, que se despachó arriba en dos líneas y da para bastante más: los flujos de trabajo.