Preview de los patrones

Descripción

Las lecciones 02 a 06 construyeron un criterio completo: qué es un sistema multi-agente, cuánto cuesta coordinarlo, cuándo ese costo se justifica y cuándo no. Todavía no construiste ningún mecanismo de coordinación en sí — solo el AgentMessage mínimo de la lección 05 y el dispatch_parallel de la lección 06, piezas sueltas. Esta lección cierra el módulo con un mapa: los cinco patrones que los Módulos 2 a 6 van a construir, uno por uno, cada uno resolviendo una pregunta de coordinación distinta que las lecciones anteriores ya te enseñaron a reconocer.

No vas a implementar ninguno de los cinco aquí — eso es, literalmente, el resto de la guía. Vas a ejecutar una función chica, choose_pattern, que toma las señales que ya conoces (¿hace falta decidir quién trabaja? ¿el orden es siempre el mismo? ¿las sub-tareas son independientes? ¿un agente cede el control a mitad de tarea? ¿hace falta un estado compartido?) y devuelve cuál de los cinco corresponde. Es un mapa, no un territorio — pero un mapa correcto hace que cada módulo que sigue se sienta como la continuación natural de algo que ya entendiste, no como un tema nuevo.

Conexión con el módulo

Esta lección no agrega ningún concepto nuevo — nombra, con precisión, los patrones a los que ya llegaste sin saberlo: el AgentMessage de la lección 05 es la forma mínima que supervisor (M2) va a usar; el dispatch_parallel de la lección 06 es exactamente el mecanismo que fan-out (M4) va a construir a fondo. El mini-proyecto de la lección 08 usa este mapa, junto con el criterio completo del módulo, para decidir entre "un agente" y, si hace falta multi-agente, cuál patrón.

Los cinco patrones, en una tabla

PATTERNS = {
    "supervisor": {
        "module": "Módulo 2",
        "question": "¿Quién debe trabajar depende de leer la petición cada vez?",
        "example": "el supervisor decide si delega a booking_agent, policy_agent o pricing_agent",
    },
    "pipeline": {
        "module": "Módulo 3",
        "question": "¿La tarea SIEMPRE necesita los mismos pasos, en el mismo orden?",
        "example": "cotizar -> validar política de cancelación -> confirmar la reserva",
    },
    "fan-out": {
        "module": "Módulo 4",
        "question": "¿Las sub-tareas son independientes y pueden correr a la vez?",
        "example": "get_quote y search_docs en el mismo turno (lección 06)",
    },
    "handoff": {
        "module": "Módulo 5",
        "question": "¿Un agente YA en curso se da cuenta de que necesita a otro especialista?",
        "example": "booking_agent está cotizando y el socio pregunta por la política de no-show",
    },
    "blackboard": {
        "module": "Módulo 6",
        "question": "¿Varios agentes necesitan leer/escribir un estado común, sin saber quién más lo usa?",
        "example": "member, cotización y booking_id compartidos entre los tres especialistas",
    },
}

print(f"{'patrón':12} {'módulo':10} pregunta que lo distingue")
for name, spec in PATTERNS.items():
    print(f"{name:12} {spec['module']:10} {spec['question']}")

Qué esperar:

patrón       módulo     pregunta que lo distingue
supervisor   Módulo 2   ¿Quién debe trabajar depende de leer la petición cada vez?
pipeline     Módulo 3   ¿La tarea SIEMPRE necesita los mismos pasos, en el mismo orden?
fan-out      Módulo 4   ¿Las sub-tareas son independientes y pueden correr a la vez?
handoff      Módulo 5   ¿Un agente YA en curso se da cuenta de que necesita a otro especialista?
blackboard   Módulo 6   ¿Varios agentes necesitan leer/escribir un estado común, sin saber quién más lo usa?

Lee cada example con el ejemplo de la lección que ya viviste al lado: supervisor es la forma completa del AgentMessage de la lección 05 —ahí solo viste un supervisor que decide delegar TODO a un especialista; el Módulo 2 construye la versión que elige entre varios—. Fan-out es la forma completa del dispatch_parallel de la lección 06 —ahí lo viste despachar tools dentro de un solo agente; el Módulo 4 lo usa para despachar agentes completos en paralelo—. Los otros tres —pipeline, handoff, blackboard— son patrones que este módulo nombró pero todavía no ejecutó: sus lecciones dedicadas los construyen de punta a punta.

Una función que elige el patrón, dadas las señales

Con las cinco preguntas de la tabla, se puede escribir una función de decisión — no para reemplazar el juicio del ingeniero, sino para hacer explícitas las señales que ya estás usando sin darte cuenta.

def choose_pattern(needs_routing, fixed_order, independent_subtasks,
                    mid_task_transfer, shared_state):
    """Dadas las señales de una tarea, sugiere cuál de los 5 patrones aplica.
    El orden de los `if` importa: blackboard y handoff son señales más
    específicas que casi siempre implican también routing o fan-out, así
    que se evalúan primero."""
    if shared_state:
        return "blackboard"
    if mid_task_transfer:
        return "handoff"
    if independent_subtasks:
        return "fan-out"
    if fixed_order:
        return "pipeline"
    if needs_routing:
        return "supervisor"
    return "ningún patrón -- un solo agente alcanza"


# Escenario 1: el sistema de la lección 05, ampliado a 3 especialistas --
# el supervisor tiene que LEER la petición para saber a quién mandarla.
print(choose_pattern(needs_routing=True, fixed_order=False,
                      independent_subtasks=False, mid_task_transfer=False,
                      shared_state=False))

# Escenario 2: siempre cotizar, después validar política, después reservar
# -- el orden nunca cambia, sin importar la petición.
print(choose_pattern(needs_routing=False, fixed_order=True,
                      independent_subtasks=False, mid_task_transfer=False,
                      shared_state=False))

# Escenario 3: el caso de la lección 06 -- get_quote y search_docs, ninguno
# depende del otro.
print(choose_pattern(needs_routing=False, fixed_order=False,
                      independent_subtasks=True, mid_task_transfer=False,
                      shared_state=False))

Qué esperar:

supervisor
pipeline
fan-out

Esta función no construye ningún patrón —eso lo hacen los cinco módulos que siguen— y deliberadamente no intenta ser exhaustiva: una tarea real puede tener más de una señal activa a la vez (por ejemplo, un supervisor que ADEMÁS necesita blackboard para compartir estado entre los especialistas que enruta — exactamente el Módulo 7, "orquestando el sistema completo"). Lo que sí hace es dejar explícito algo que hasta ahora viste solo en ejemplos sueltos: cada patrón responde a una pregunta de diseño distinta, no son cinco sabores intercambiables del mismo mecanismo.

Frontera con building-ai-agents-guide Módulo 8, en detalle

La lección 01 adelantó la diferencia de fondo; con los cinco patrones nombrados, vale la pena verla patrón por patrón. building-ai-agents-guide M08 cubre cuatro de estos cinco nombres, pero comprimidos en un módulo de un proyecto de 80 lecciones, sobre LangGraph:

Dos diferencias que vale la pena remarcar, porque cambian lo que vas a poder hacer al terminar cada guía: pipeline secuencial no existe como patrón con nombre propio en esa guía — ahí, un flujo de pasos fijos se resuelve con las herramientas genéricas de LangGraph, sin una lección dedicada a cuándo preferirlo sobre un supervisor (la pregunta central del Módulo 3 de esta guía). Y fan-out paralelo aparece mezclado con conceptos más avanzados (jerarquías de agentes, consensus entre respuestas) en una sola lección, en vez del módulo completo que esta guía le dedica —con el costo de coordinación medido, como en la lección 05, y no solo mostrado funcionando—.

Ninguna de las dos guías es "mejor" en abstracto — resuelven objetivos distintos. Si ya sabes LangGraph y quieres ver estos patrones en un framework de producción real, sobre un caso de investigación, building-ai-agents-guide M08 es el lugar. Si quieres entender qué hace un framework de orquestación por debajo, con cada pieza construida a mano y su costo medido antes de usarla, esta guía —las 8 completas— es la que sigue.

Errores comunes

1. Pensar que choose_pattern reemplaza el criterio del Módulo 1. Esta función asume que ya decidiste que hace falta multi-agente —el paso que las lecciones 01 a 06 enseñaron a evaluar—. Aplicarla sin haber pasado por ese criterio es saltarse el paso que evita el resultado de la lección 05 (coordinar sin necesidad).

2. Tratar los cinco patrones como mutuamente excluyentes para siempre. El Módulo 7 ("orquestando el sistema completo") combina varios en una sola corrida — un supervisor que enruta, con algunas sub-tareas en pipeline y otras en fan-out, todo sobre un blackboard compartido. choose_pattern, tal como está escrita, devuelve uno solo por simplicidad pedagógica; un sistema real puede necesitar más de uno a la vez.

3. Confundir "pipeline" con "supervisor que siempre delega en el mismo orden". La diferencia no es cosmética: un supervisor decide en cada corrida, leyendo la petición (aunque la decisión termine siendo la misma casi siempre); un pipeline no decide nada — el orden está fijo en el diseño del sistema, no en una llamada al modelo. El Módulo 3 desarrolla esta distinción con más cuidado.

4. Pensar que building-ai-agents-guide M08 es redundante ahora que viste esta tabla. Esa guía enseña a usar LangGraph en producción, con checkpointers, Send API y StateGraph reales — una habilidad valiosa y distinta a construir los patrones desde cero. La tabla de esta lección compara alcance y profundidad, no calidad.

5. Saltarse la lección 08 pensando que el módulo ya terminó. El mini-proyecto no es un resumen — es la primera vez que aplicas el criterio COMPLETO (no solo un patrón aislado) a escenarios que no viste antes, la prueba real de que el criterio se volvió tuyo.

Ejercicios

Ejercicio 1: Clasifica tres escenarios con la tabla (Fácil)

Sin ejecutar choose_pattern todavía, usa solo la tabla de patrones para decidir cuál corresponde a cada escenario: (a) un agente de Reservo que, a mitad de cotizar una sala, se da cuenta de que el socio en realidad quiere cancelar una reserva existente y transfiere el control sin volver a preguntarle a nadie más; (b) tres agentes que necesitan saber, en todo momento, cuál fue la última sala cotizada en la conversación, sin que ninguno le pregunte directamente a los otros dos; (c) una tarea que siempre resuelve, en este orden exacto, list_rooms → get_quote → book_room, sin ninguna variación posible.

Ejercicio 2: Ejecuta choose_pattern sobre los tres escenarios del Ejercicio 1 (Medio)

Traduce los tres escenarios del Ejercicio 1 en llamadas a choose_pattern (con las cinco señales booleanas correspondientes) y confirma que la función devuelve el mismo patrón que identificaste a mano.

# (a) handoff: un agente en curso transfiere el control a mitad de tarea.
print(choose_pattern(needs_routing=False, fixed_order=False,
                      independent_subtasks=False, mid_task_transfer=True,
                      shared_state=False))

# (b) blackboard: estado compartido, sin mensajes punto a punto.
print(choose_pattern(needs_routing=False, fixed_order=False,
                      independent_subtasks=False, mid_task_transfer=False,
                      shared_state=True))

# (c) pipeline: orden siempre fijo, sin decisión de ruteo.
print(choose_pattern(needs_routing=False, fixed_order=True,
                      independent_subtasks=False, mid_task_transfer=False,
                      shared_state=False))

handoff
blackboard
pipeline

Ejercicio 3: Encuentra el límite de choose_pattern (Difícil)

Diseña un escenario de Reservo donde dos de las cinco señales sean ciertas a la vez —por ejemplo, independent_subtasks=True y shared_state=True— y explica, en prosa: (a) qué patrón devuelve la función tal como está escrita, (b) si ese resultado te parece el diseño correcto para tu escenario, y (c) qué cambiarías en choose_pattern (sin reescribirla del todo) para que reconociera que a veces hace falta combinar dos patrones, no elegir uno.

Resumen y siguiente paso

• Los cinco patrones que construyen los Módulos 2 a 6 responden, cada uno, una pregunta de coordinación distinta: supervisor (¿quién trabaja, decidido leyendo la petición?), pipeline (¿el orden es siempre el mismo?), fan-out (¿las sub-tareas son independientes?), handoff (¿un agente en curso cede el control?), blackboard (¿hace falta un estado compartido, sin mensajes punto a punto?).
• Ya usaste, sin nombrarlas, las semillas de dos de los cinco: el AgentMessage de la lección 05 es la forma mínima de supervisor; el dispatch_parallel de la lección 06 es la forma mínima de fan-out.
• La frontera con building-ai-agents-guide M08 se hizo precisa, patrón por patrón: esa guía cubre cuatro de los cinco, comprimidos con LangGraph en un módulo de un proyecto más grande; pipeline secuencial ni siquiera existe ahí como patrón nombrado.
• choose_pattern es un mapa, no una autoridad — un sistema real, como el del Módulo 7, combina varios patrones a la vez sobre la misma corrida.

Siguiente lección: 08 — Mini-proyecto: decide single o multi. Cierras el módulo aplicando el criterio completo —costo medido, señales que lo justifican, y ahora el mapa de patrones— a varios escenarios nuevos, con una función de decisión que ejecutas y después cuestionas tú mismo.

Recursos adicionales

1. Anthropic — Building effective agents — Los patrones de "workflow" (prompt chaining, routing, parallelization) que corresponden, con otro vocabulario, a pipeline, supervisor y fan-out de esta guía.
2. Anthropic — Multi-agent research system — Un sistema real que combina varios de estos patrones sobre la misma corrida, la forma que persigue el Módulo 7 de esta guía.
3. LangGraph — Multi-agent systems — La documentación de los mismos patrones implementados con un framework, la referencia directa de building-ai-agents-guide M08.
4. Python — Diccionarios y funciones de orden superior — La estructura detrás de PATTERNS y la lógica condicional de choose_pattern.