Patrones de Flujo de Trabajo de Agentes de IA: 7 Patrones y Cuándo Gana Cada Uno (2026)

Patrones de Flujo de Trabajo de Agentes de IA: 7 Patrones y Cuándo Gana Cada Uno (2026)

Los patrones de flujo de trabajo de agentes de IA por fin tienen cifras: en enero de 2026, Google Research evaluó 180 configuraciones de agentes y descubrió que el mismo cambio de coordinación mejoraba el razonamiento financiero paralelizable un 80,9% mientras hundía la planificación secuencial hasta un 70% en PlanCraft. Misma palanca, resultados opuestos. La variable que decide es la descomponibilidad de la tarea, no el número de agentes, y los siete patrones de abajo se juzgan contra datos publicados, no contra diagramas de proveedores.

• Importan siete patrones: secuencial, enrutamiento, paralelización, orchestrator-workers, reflexión, ReAct y plan-and-execute.
• La descomponibilidad de la tarea decide el ganador. El trabajo paralelizable gana; el trabajo secuencial se degrada.
• Empieza con un agente. Añade un segundo solo cuando el primero se estanque por debajo del ~85% de precisión.

Patrones de Flujo de Trabajo de Agentes de IA de un Vistazo: Qué Dice la Data

Los siete patrones de agentes de IA son secuencial (encadenamiento de prompts), enrutamiento (handoff), paralelización (fan-out/fan-in), orchestrator-workers, reflexión (evaluador-optimizador), ReAct y plan-and-execute. Cinco documentaciones de proveedores los nombran de forma distinta, pero estas siete formas cubren todas las taxonomías que Anthropic, OpenAI, Vercel, Microsoft y Google Cloud publican actualmente. Human-in-the-loop no es uno de los siete: es una capa de control que envuelve a cualquiera de ellos.

Lee la columna de mediciones con escepticismo. Tres filas llevan cifras reales; cuatro llevan "sin medición pública", que es el estado honesto del campo en 2026. Cinco proveedores publican cinco nombres distintos para lo que en realidad son tres o cuatro formas subyacentes. La última columna existe para que puedas mapear cualquiera de esos nombres de vuelta a la forma subyacente, algo que el resto del post desgrana familia por familia.

Dos columnas que nadie en la SERP discute son el coste de tokens y el presupuesto de latencia. Secuencial y enrutamiento gastan lo mínimo en ambos; orchestrator-workers gasta lo máximo en ambos; la paralelización cambia gasto de tokens por tiempo real. Elige el patrón según el recurso que tu tarea realmente restringe, no según el diagrama que parezca más impresionante.

Qué Son los Patrones de Flujo de Trabajo de Agentes de IA (y Cuáles Son las 4 Etapas de un Flujo de IA)

Los patrones de diseño de flujo de trabajo de agentes de IA son formas reutilizables de organizar llamadas a LLMs, uso de herramientas y lógica de control dentro de un sistema. Los siete que reaparecen en todas las taxonomías de proveedores son secuencial, enrutamiento, paralelización, orchestrator-workers, reflexión, ReAct y plan-and-execute. Cada uno intercambia de forma distinta coste de tokens, latencia y precisión, así que la elección correcta depende de la estructura de la tarea, no del framework que uses por casualidad.

Un flujo de trabajo típico de un agente de IA recorre cuatro etapas, en bucle:

1. Planificar: el modelo decide qué hacer a continuación, dado el objetivo y el historial hasta ahora.
2. Actuar: llama a una herramienta, que en 2026 normalmente significa un servidor MCP o una function call. El Model Context Protocol (MCP) estandariza esa capa de herramientas entre modelos.
3. Observar: el resultado de la herramienta vuelve al contexto como un mensaje nuevo.
4. Reflexionar / iterar: el modelo juzga si el resultado es suficientemente bueno y luego itera o se detiene.

Cada patrón de este post es una forma distinta de cablear esas cuatro etapas. El secuencial fija el orden en el código. ReAct deja que el modelo elija la siguiente etapa en cada turno. Orchestrator-workers reparte el bucle entre varios modelos.

Una distinción importa antes del catálogo. Un workflow son rutas de código predeterminadas; un agente cede el control al modelo. Anthropic traza la línea así en Building Effective Agents: "Los workflows ofrecen previsibilidad y consistencia para tareas bien definidas, mientras que los agentes son la mejor opción cuando se necesitan flexibilidad y toma de decisiones dirigida por el modelo a escala."

Si llegaste buscando los tipos clásicos de agentes en IA (reflejo simple, basado en modelo, basado en objetivos, con aprendizaje), esa taxonomía es anterior a los LLMs; los siete patrones de arriba son los que deciden si tu proyecto llega a producción.

Los Patrones Deterministas: Secuencial, Enrutamiento y Paralelización

Tres patrones mantienen el control en tu código, no en el modelo. Son los más baratos de ejecutar y los más fáciles de depurar, y la guía del equipo de Claude de marzo de 2026 es directa sobre dónde empezar: "Empieza con el patrón más simple que resuelva tu problema. Por defecto, secuencial."

Secuencial (encadenamiento de prompts)

Una llamada alimenta la siguiente. Divides una tarea difícil en pasos ordenados y cada paso recibe la salida del paso anterior como entrada. La ganancia es legibilidad: puedes inspeccionar cada resultado intermedio y cachear cada paso. Evítalo cuando las subtareas son independientes, porque estás pagando latencia por un orden que no necesitas. Si el estado tiene que sobrevivir entre pasos o entre sesiones, eso es un problema de memoria, no de encadenamiento; mira nuestra guía de memoria de agentes para ver la separación. Su único respaldo publicado es ser el valor por defecto: ningún estudio mide una ganancia del encadenamiento en sí, porque es la línea base a la que todos los demás patrones pagan extra por superar.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Enrutamiento (handoff)

Un clasificador barato lee la entrada y la despacha a un prompt o modelo especialista. OpenAI lo enmarca así en la documentación del Agents SDK: "Un agente de triaje enruta la conversación a un especialista, y ese especialista se convierte en el agente activo durante el resto del turno." Evita el enrutamiento cuando el clasificador es menos fiable que ejecutar simplemente una ruta general única, porque cada mal enrutamiento es una respuesta incorrecta silenciosa. El modo de fallo con nombre aquí es la pérdida de contexto durante el handoff: el especialista solo ve lo que el enrutador le reenvía. Cargar el rastro completo es una decisión de context engineering, y fallar en eso es por lo que los sistemas enrutados parecen olvidadizos. La matemática de tokens favorece al enrutamiento de todos modos: el clasificador corre en un modelo pequeño (gpt-4o-mini arriba), así que un enrutador añade unos pocos cientos de tokens baratos por petición en vez de una segunda llamada cara.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Paralelización (fan-out/fan-in)

Las subtareas independientes se ejecutan a la vez y luego un paso de fusión las combina. Anthropic divide esto en seccionado (dividir el trabajo) y votación (ejecutar la misma tarea varias veces y comparar). Esta es la forma que Google Research midió en +80,9% sobre un agente único en razonamiento financiero paralelizable en enero de 2026, precisamente porque la tarea se descomponía limpiamente. Evítala en el momento en que el paso n+1 dependa de la salida del paso n; paralelizar una cadena de dependencias solo reordena las respuestas incorrectas más rápido. La latencia es la otra mitad de la ganancia: las llamadas independientes corren en paralelo, así que el tiempo real cae aproximadamente con el número de workers mientras el gasto total de tokens se mantiene plano.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs Plan-and-Execute: ¿Qué Patrón de Razonamiento Deberías Usar?

ReAct intercala razonamiento con acción: el modelo piensa, llama a una herramienta, observa el resultado y solo entonces decide el siguiente paso. Plan-and-execute escribe el plan completo antes de que se ejecute ninguna herramienta y luego ejecuta los pasos en orden. ReAct se adapta a las sorpresas a mitad de ejecución; plan-and-execute paga una llamada de planificación grande por adelantado y confía en la ruta.

ReAct decide su siguiente paso después de cada observación; plan-and-execute se compromete con la ruta completa antes de la primera llamada a herramienta.

ReAct viene de Yao et al. (arXiv 2210.03629, v1 octubre de 2022, v3 marzo de 2023), que reportó +34% absoluto de éxito en ALFWorld y +10% en WebShop sobre líneas base de imitación y aprendizaje por refuerzo, usando solo uno o dos ejemplos en contexto. Es el bucle por defecto detrás de la mayoría de agentes que usan herramientas, y es un hueco en el tercer resultado de la SERP: la documentación de orquestación de Microsoft Learn, de 7.133 palabras, omite ReAct por completo. Esa cadencia de observar-decidir es por lo que ReAct maneja las tareas abiertas ("navega hasta encontrar X") mejor que cualquier plan previo: el plan tendría que adivinar qué contienen las páginas antes de leerlas.

Plan-and-execute viene de Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), que primero idea un plan que divide la tarea en subtareas y luego las ejecuta. El paper reporta superar al chain-of-thought zero-shot en los diez datasets evaluados; no citamos ninguna cifra única porque el abstract del paper no publica ninguna. Úsalo cuando la ruta es predecible y replanificar después de cada paso desperdiciaría tokens. La contrapartida es la fragilidad: si el paso tres falla, un bucle plan-and-execute necesita un gancho explícito de replanificación, mientras que ReAct replanifica por construcción.

La fila de evidencia medida es la señal honesta. ReAct tiene un paper de 2022 con cifras a nivel de tarea; plan-and-execute tiene un barrido de diez datasets y ninguna cifra titular, que es una razón por la que se cita más a menudo de lo que se benchmarkea.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Ese límite de iteraciones no es opcional. Un bucle ReAct sin salida quema tokens hasta que tu presupuesto lo haga; max_steps es la barandilla más barata de todo este post. Plan-and-execute necesita la misma barandilla un nivel más arriba: limita las replanificaciones, no solo los pasos, o un plan fallido se regenerará indefinidamente.

Los Patrones de Calidad: Reflexión, Evaluador-Optimizador y Human-in-the-Loop

Los patrones de calidad gastan tokens extra para subir la calidad de salida, y solo rinden cuando la calidad es medible. La reflexión (Anthropic la llama evaluador-optimizador) ejecuta un generador y un crítico en un bucle: un modelo redacta, otro critica, el borrador mejora. Si no puedes puntuar la salida con un test, una rúbrica o un modelo evaluador, el crítico son solo tokens extra discutiendo consigo mismo. Construir ese puntuador es la parte difícil; nuestra guía sobre evaluar agentes en producción cubre lo que requiere una función de puntuación utilizable. Cuando se cumple la precondición, el patrón es un seguro barato: Anthropic describe el evaluador-optimizador como dos llamadas a LLM en un bucle, una generando y otra criticando, lo que compra una mejora de calidad medible por unos segundos extra de latencia.

El modo de fallo que nadie diagrama es la reflexión desbocada: el crítico y el generador iteran para siempre, o peor, oscilan. El arreglo es un límite duro de iteraciones más una ruptura por no mejora, escrita en código en vez de pedida en el prompt:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop es una capa de control, no un octavo patrón. Envuelve a cualquiera de los siete: un humano aprueba antes de que se ejecute un paso irreversible. Solo 2 de los 6 primeros resultados de la SERP lo cubren. Coloca la puerta en las acciones irreversibles, el gasto real y cualquier cosa que salga de tu sistema como comunicación externa. Todo lo demás debería ejecutarse sin supervisión o no ejecutarse. La puerta en sí debería ser código tonto, no otro LLM: una cola de aprobación, un umbral de gasto, una lista blanca de dominios. Poner a un modelo a cargo de decidir si un humano debería mirar derrota el propósito.

¿Vale la Pena el Multi-Agente por 15× los Tokens? Qué Dicen Realmente los Benchmarks

Orchestrator-workers es el séptimo patrón: un agente líder descompone una tarea, delega piezas a agentes trabajadores y fusiona lo que devuelven. "Multi-agente" es este patrón llevado a su extremo, no una forma separada, así que la pregunta es realmente cuándo el orquestador justifica su sobrecoste.

¿Cuándo deberías usar multi-agente en vez de un agente único? Solo cuando un agente único se estanca por debajo de un 85% de precisión en la tarea. Esa regla práctica circuló en r/AI_Agents (2026-04-23) junto al estudio de Google Research, y coincide con la data medida: por encima de esa barra, los agentes añadidos suman coste y amplificación de errores sin sumar precisión.

Aquí está cada cifra publicada que pudimos verificar, lado a lado:

Una advertencia antes de que hagas clic: cada cifra de Google Research de arriba viene del post de blog del 2026-01-28, y el paper detrás (arXiv 2512.08296) ha sido revisado desde entonces, así que su versión actual reporta 260 configuraciones y R² = 0,373 en vez de los 180 y 0,513 del blog. La dirección se mantiene en ambos casos; las cifras exactas dependen de qué versión estés leyendo.

Dos de estas filas se citan mal rutinariamente, así que aquí va la aritmética. La cifra de 15× de Anthropic se mide contra una interacción de chat, y su cifra de agente único es 4×. Así que el multi-agente cuesta aproximadamente 15 / 4 = 3,75× los tokens de un agente único, no 15×. Y la amplificación de errores de Google Research de 17,2× para agentes independientes versus 4,4× para centralizados significa que un orquestador contiene aproximadamente 17,2 / 4,4 = 3,9× menos amplificación de errores que dejar a los agentes correr sin supervisión.

Leyendo el análisis de Anthropic contra las cifras de Google Research, nuestra lectura es que la descomponibilidad, no el número de agentes, es la variable que decide. La tarea de investigación de Anthropic se dividía limpiamente en sub-búsquedas paralelas, así que más agentes ayudaron. Las tareas de planificación secuencial de Google no se dividían, así que más agentes se estorbaban entre sí.

Eso coincide con lo que dicen los profesionales cuando los sistemas llegan a producción. En r/AI_Agents, un hilo titulado "Multi agent systems are a total nightmare in production" (2026-04-23, 56 puntos, 68 comentarios) venía de un OP que ha lanzado más de 20 sistemas para clientes: "Los que realmente siguen funcionando... son casi vergonzosamente simples", y "cada vez que un agente habla con otro, pierdes contexto. Es como ese juego del teléfono." El comentario principal destila toda la sección: "intenta resolver tu problema con un agente único. Si este agente tiene >85% de precisión, un sistema multi-agente no añadirá más valor."

Antes de añadir un agente, prueba los arreglos baratos que Anthropic midió: una descripción de herramienta mejorada produjo una caída del 40% en el tiempo de completado de tareas, y las llamadas a herramientas en paralelo recortaron el tiempo de investigación hasta un 90%. Ambos superan a un segundo agente en coste. Si de todos modos vas a multi-agente en una herramienta real, los subagentes de Claude Code son orchestrator-workers que puedes inspeccionar línea a línea.

Mismo Patrón, Cinco Nombres: Una Tabla Rosetta de Frameworks

Las mismas cuatro formas aparecen bajo nombres distintos en la documentación de cada proveedor, y la nomenclatura no se transfiere entre frameworks. "Magentic" y "group chat" de Microsoft no significan nada en el OpenAI SDK hasta que los traduces, y ese impuesto de traducción es un coste real que esta tabla elimina.

Cinco proveedores, cinco vocabularios, tres o cuatro formas reales. El coste práctico aparece cuando cambias de framework: un equipo que pasa del Agent Framework de Microsoft al OpenAI SDK tiene que remapear "magentic" a agents-as-tools y "group chat" a un grafo de handoff antes de transferir una sola línea de código. La taxonomía de once nombres de Google Cloud es la más larga, la lista de siete nombres de Anthropic es la más citada, y los tres nombres del blog de Claude son los que implementarás primero. Lee la forma, luego lee el SDK. Las cabeceras de columna son las documentaciones mismas: Anthropic, el blog de Claude, el OpenAI Agents SDK, el Vercel AI SDK, Microsoft Learn y Google Cloud. Una vez que ves las formas, elegir un framework es una decisión separada; nuestro repaso de los mejores frameworks de agentes de IA en 2026 y la comparativa LangGraph vs CrewAI vs el OpenAI Agents SDK cubren esa.

¿Cuándo NO Deberías Usar un Flujo de Trabajo de Agentes?

A menudo, no deberías. La escalera de decisión más votada en r/AI_Agents (2026-03-09) lo dice sin rodeos: "Si unas sentencias if…then funcionan, usa eso. Luego, si los workflows tradicionales funcionan, usa eso. Si no, usa IA agéntica." Dos de los tres primeros resultados de la SERP son documentación de la nube que estructuralmente no puede decirte que construyas menos. Nosotros sí podemos. La data de este post apunta en la misma dirección: las dos mayores ganancias medidas (+80,9% y +90,2%) vinieron de tareas que se descomponían limpiamente, y la peor pérdida medida (−70%) vino de forzar agentes sobre una tarea que no lo hacía.

Los modos de fallo tienen nombre, y cada uno tiene ahora una cifra asociada:

• Pérdida de contexto entre handoffs: cada mensaje de agente a agente pierde estado (la queja del "teléfono" de r/AI_Agents, 2026-04-23).
• Amplificación de errores: 17,2× para agentes independientes versus 4,4× centralizados (Google Research, 2026-01-28).
• Bucles de reflexión desbocados: limita las iteraciones y rompe cuando no haya mejora, como en el código de arriba.
• Degradación de tareas secuenciales: 39–70% peor cuando paralelizas trabajo que no se descompone (Google Research, 2026-01-28).
• Descontrol de costes: aproximadamente 15× los tokens de chat para un sistema multi-agente (Anthropic, 2025-06-13).

Cada uno de esos modos de fallo tiene un límite que puedes escribir en diez líneas de código, y el límite es siempre más barato que el agente que ibas a añadir.

Walden Yan de Cognition hizo el mismo argumento desde el lado del constructor en Don't Build Multi-Agents (2025-06-12): "Comparte contexto, y comparte trazas completas del agente, no solo mensajes individuales", y "Las acciones llevan decisiones implícitas, y las decisiones en conflicto llevan malos resultados." La comparación de r/AI_Agents es la que seguimos recordando: "el multi-agente empieza a parecerse mucho a los microservicios. Poderoso cuando los límites son reales, doloroso cuando son inventados."

Cómo Enfoca Techsy la Selección de Patrones

La escalera de abajo es nuestra lectura de los hallazgos de Google Research y Anthropic más los hilos de profesionales, no un resultado medido propio. La recorremos de arriba abajo y paramos en la primera fila que encaje:

Tres cosas se siguen de la data de este post. Empieza en secuencial, porque Anthropic lo dice y nada en la SERP lo desmiente. Paraleliza solo lo que se descompone, porque el mismo cambio de coordinación medido en +80,9% también se midió en −70%. Y trata un segundo agente como último recurso, porque la factura de tokens es real y la amplificación de errores está medida. El hilo conductor es que añadir agentes es una jugada de escalado, no de calidad: los benchmarks la premian solo donde el trabajo se divide, y los hilos de profesionales lo confirman en todas partes. Si quieres una segunda opinión sobre una arquitectura antes de construirla, obtén una consulta gratuita.

Preguntas Frecuentes

¿Cuáles son los 7 patrones de agentes de IA?

Los siete son secuencial (encadenamiento de prompts), enrutamiento (handoff), paralelización (fan-out/fan-in), orchestrator-workers, reflexión (evaluador-optimizador), ReAct y plan-and-execute. Reaparecen bajo nombres distintos en todas las taxonomías de proveedores, desde Anthropic hasta Google Cloud. Human-in-the-loop se discute junto a ellos pero es una capa de control que envuelve a cualquiera de los siete, no un octavo patrón.

¿Cuáles son las 4 etapas del flujo de trabajo de un agente de IA?

Planificar, actuar, observar, reflexionar. El modelo planifica un siguiente paso, actúa llamando a una herramienta, observa el resultado de la herramienta entrando en contexto y luego reflexiona sobre si el objetivo se cumple e itera o se detiene. Cada patrón de este post es una forma distinta de cablear juntas esas cuatro etapas.

¿Cuál es la diferencia entre un workflow de IA y un agente de IA?

Un workflow sigue rutas de código predeterminadas; un agente deja que el modelo dirija su propio flujo de control. La regla de Anthropic: workflows para previsibilidad en tareas bien definidas, agentes para flexibilidad cuando se necesitan decisiones dirigidas por el modelo a escala. La mayoría de sistemas en producción son workflows con unos pocos pasos de agente dentro.

ReAct vs plan-and-execute: ¿cuál debería usar?

Usa ReAct cuando el siguiente paso depende de lo que devolvió la última herramienta y la ruta puede cambiar a mitad de ejecución. Usa plan-and-execute cuando la ruta es predecible de antemano y replanificar después de cada paso desperdiciaría tokens. ReAct midió +34% en ALFWorld (Yao et al., 2022); plan-and-execute superó al CoT zero-shot en diez datasets (Wang et al., 2023).

¿Necesito un framework como LangGraph para usar estos patrones?

No. Cada bloque de código de este post es una llamada SDK simple, y los patrones son anteriores a los frameworks que los nombran. Un framework se gana el pan en la persistencia de estado, los reintentos y el trazado, no en el patrón en sí. Si estás eligiendo uno, nuestra comparativa de frameworks cubre las contrapartidas.

¿Cómo evito que un bucle de reflexión corra para siempre?

Dos guardas, ambas en código: un límite duro de iteraciones (usamos 4 rondas) y una ruptura por no mejora que detiene el bucle en el momento en que la reescritura del crítico no puntúa mejor que el borrador actual. No confíes en que el prompt termine el bucle; el modelo no tiene idea de cuánto cuestan las cosas.

¿Cuándo es suficiente un agente único?

Cuando supera aproximadamente el 85% de precisión en la tarea. Esa heurística, circulada en r/AI_Agents (2026-04-23) junto al estudio de Google Research, coincide con los benchmarks: por encima de esa barra, los agentes extra suman coste y amplificación de errores sin sumar precisión. Mide la línea base del agente único antes de diseñar nada más grande.

¿Dónde puedo encontrar ejemplos de patrones de flujo de trabajo de agentes de IA con código?

Los cinco bloques de Python de arriba cubren secuencial, enrutamiento, paralelización, ReAct y reflexión, todos como llamadas SDK simples que puedes copiar directamente. Para ejemplos con sabor de proveedor, el Vercel AI SDK trae TypeScript ejecutable por patrón y la documentación del OpenAI Agents SDK cubre handoffs y agents-as-tools. Los enlaces a ambos están en la lista de Fuentes de abajo.

Fuentes

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); paper: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (actualizado 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)