Qué es un sistema multi-agente

Descripción

agent-fundamentals te dejó con un agente: un modelo, un registro de tools, y un while que pide, despacha, alimenta y repite hasta que el modelo decide que terminó. Ese agente puede tener una tool o puede tener cuatro —lo viste en M5 de esa guía—, pero sigue siendo un modelo, con un historial de conversación, tomando una decisión por turno. Esta lección define, con precisión, qué cambia cuando en vez de un agente con más tools tienes varios agentes, cada uno con su propio loop, su propio registro de tools y su propia decisión — y por qué esa distinción no es cosmética.

Vas a ver dos registros ejecutados lado a lado: el registro único de cuatro tools que ya conoces, y un sistema de tres especialistas de Reservo, cada uno con su propio subconjunto. La diferencia no está en cuántas tools hay en total —en este ejemplo, casi las mismas— sino en cómo se agrupan y quién decide con cuáles.

Conexión con el módulo

La lección 01 te dio el criterio general y la analogía del equipo de personas. Esta lección lo hace preciso: define la unidad mínima de "un agente" (préstamo directo de agent-fundamentals) y la unidad "sistema multi-agente" como una composición de varios. Las lecciones 03 a 06 miden el costo y el beneficio de esa composición; esta lección solo establece qué es, para que no haya ambigüedad en lo que sigue.

Analogía: un empleado con un llavero grande vs. un edificio con varios puestos

agent-fundamentals M5 usó la analogía del llavero: un asistente con un llavero de cuatro llaves, cada una rotulada, y él decide cuál usar según la tarea. Esa sigue siendo la imagen correcta para un agente con varias tools — sigue siendo una sola persona, con un solo llavero, tomando una decisión a la vez.

Un sistema multi-agente es un edificio distinto: en vez de un empleado con un llavero grande, hay varios puestos de atención, cada uno con su propio llavero más chico y su propia especialidad — uno atiende reservas, otro atiende consultas de política, otro compara precios entre salas. Un visitante que llega con una pregunta compuesta ("resérvame una sala y dime la política de cancelación") puede necesitar pasar por más de un puesto — y ese paso de un puesto a otro, con su propio tiempo y su propio riesgo de malentendido, es exactamente lo que las lecciones siguientes van a medir.

Ejemplo trabajado: un registro vs. tres registros

Partimos de las cuatro tools canónicas de Reservo, las mismas de siempre, y las organizamos de dos formas: como un único registro (un agente, más tools) y como tres registros más angostos (tres agentes, cada uno con su especialidad).

import reservo_tools as rt


def search_docs_stub(query):
    """Placeholder mínimo para esta lección -- el stub completo, con sus
    2-3 entradas por palabra clave, se construye en la lección 06."""
    return "policy stub"


# UN agente: un solo registro con las cuatro tools canónicas.
SINGLE_AGENT_TOOLS = {
    "list_rooms": rt.list_rooms,
    "get_quote": rt.get_quote,
    "book_room": rt.book_room,
    "cancel_booking": rt.cancel_booking,
}

# UN SISTEMA MULTI-AGENTE: tres registros más angostos, cada uno con su
# propia expertise -- no una tool nueva por cada uno necesariamente.
SPECIALISTS = {
    "booking_agent": {
        "tools": {
            "list_rooms": rt.list_rooms, "get_quote": rt.get_quote,
            "book_room": rt.book_room, "cancel_booking": rt.cancel_booking,
        },
        "expertise": "cotizar, reservar y cancelar salas",
    },
    "policy_agent": {
        "tools": {"search_docs": search_docs_stub},
        "expertise": "responder preguntas de política (cancelación, no-presentación)",
    },
    "pricing_agent": {
        "tools": {"get_quote": rt.get_quote},  # compone get_quote, no crea una tool nueva
        "expertise": "comparar el costo de varias salas/tiers en una sola respuesta",
    },
}

print("--- un agente, un registro de 4 tools ---")
print(f"SINGLE_AGENT_TOOLS: {len(SINGLE_AGENT_TOOLS)} tools -> {list(SINGLE_AGENT_TOOLS)}")

print()
print("--- un sistema multi-agente, 3 registros más angostos ---")
for name, spec in SPECIALISTS.items():
    tools = list(spec["tools"])
    print(f"{name:15} {len(tools)} tool(s) {str(tools):35} expertise: {spec['expertise']}")

Qué esperar:

--- un agente, un registro de 4 tools ---
SINGLE_AGENT_TOOLS: 4 tools -> ['list_rooms', 'get_quote', 'book_room', 'cancel_booking']

--- un sistema multi-agente, 3 registros más angostos ---
booking_agent   4 tool(s) ['list_rooms', 'get_quote', 'book_room', 'cancel_booking'] expertise: cotizar, reservar y cancelar salas
policy_agent    1 tool(s) ['search_docs']                     expertise: responder preguntas de política (cancelación, no-presentación)
pricing_agent   1 tool(s) ['get_quote']                       expertise: comparar el costo de varias salas/tiers en una sola respuesta

Fíjate en algo que a simple vista podría pasar desapercibido: pricing_agent no tiene ninguna tool que booking_agent no tenga — get_quote aparece en los dos registros. Y sin embargo son dos agentes legítimamente distintos, porque lo que los separa no es el inventario de funciones Python que pueden llamar, sino la decisión que cada uno tiene la responsabilidad de tomar: booking_agent decide si cotizar, reservar o cancelar, con el objetivo de completar una transacción; pricing_agent decide cómo componer varias llamadas a get_quote para producir una comparación, con el objetivo de informar, nunca de reservar nada. Volvemos sobre esto en la lección 06 — por ahora, quédate con la idea de que "agente distinto" no siempre significa "función Python distinta".

La definición formal

Con el ejemplo ejecutado enfrente, la definición se vuelve concreta en vez de abstracta:

UN AGENTE (agent-fundamentals):
  - UN modelo, tomando UNA decisión por turno
  - UN registro de tools (TOOLS = {...})
  - UN historial de conversación (messages)
  - UN loop (el while que pide -> despacha -> alimenta -> repite)

UN SISTEMA MULTI-AGENTE (esta guía):
  - VARIOS agentes, cada uno con su PROPIO modelo/decisión, tools, historial y loop
  - Un MECANISMO que decide qué agente(s) trabaja(n) en cada momento
  - Una forma de PASAR información entre ellos (mensaje directo o estado compartido)
  - Una forma de AGREGAR sus resultados en una sola respuesta final

Las cuatro últimas líneas son exactamente lo que los Módulos 2 a 6 de esta guía construyen, un patrón a la vez: el mecanismo de decisión (supervisor/router, M2), el orden fijo (pipeline, M3), el trabajo simultáneo (fan-out, M4), la transferencia de control a mitad de tarea (handoff, M5), y el estado compartido (blackboard, M6). Este módulo no construye ninguno de los cuatro todavía — establece que existen y por qué hacen falta.

Una precisión que vale la pena remarcar: cada agente de un sistema multi-agente sigue siendo, por dentro, exactamente el mismo tipo de agente de agent-fundamentals. booking_agent no es una arquitectura nueva — es el mismo run_agent_parallel corriendo sobre un registro de cuatro tools, tal como ya lo ejecutaste en M5 de esa guía. Lo nuevo de esta guía no vive dentro de cada agente — vive entre ellos.

Un agente con varias tools no es un sistema multi-agente

Esta es la confusión más común al empezar esta guía, y vale la pena nombrarla directamente. Si tienes un agente con diez tools, elige entre ellas turno a turno — pero sigue siendo una sola decisión, de un solo modelo, sobre un solo historial. Eso es exactamente lo que agent-fundamentals M5 construyó, y lo que la lección 04 de este módulo retoma. No hay "colaboración" entre tools: una tool no le pasa un mensaje a otra, ni negocia con ella, ni tiene su propio objetivo independiente. list_rooms no decide nada — solo devuelve datos cuando el agente la llama.

Un sistema multi-agente, en cambio, tiene varios puntos de decisión independientes —tres modelos (concepto) potencialmente decidiendo cosas distintas, no uno solo eligiendo entre diez opciones—. Esa es la línea: ¿hay una sola decisión eligiendo entre alternativas, o hay varias decisiones, cada una tomada por un agente distinto, que después hay que coordinar? La primera es selección de tools (M5 de agent-fundamentals); la segunda es orquestación (esta guía).

Errores comunes

1. Llamar "multi-agente" a un agente con muchas tools. Cuatro, ocho o veinte tools en un solo registro siguen siendo un agente — la selección entre ellas es un problema de descriptions claras (agent-fundamentals M5), no de coordinación entre agentes.

2. Asumir que cada agente necesita una tool exclusiva para ser "real". pricing_agent de este ejemplo comparte get_quote con booking_agent y sigue siendo un agente legítimo —lo que lo distingue es el objetivo y la forma en que compone sus llamadas, no una función Python que nadie más tenga.

3. Confundir "varios agentes" con "varios procesos o hilos del sistema operativo". En esta guía, "agente" es una unidad lógica (un loop + un registro de tools + una decisión), no una unidad de sistema operativo — todos corren en el mismo proceso Python, tal como el fan-out con hilos de agent-fundamentals M5 ya corría en paralelo dentro de un solo proceso.

4. Pensar que un sistema multi-agente necesita, como mínimo, tres agentes. No hay un piso —el caso más chico posible, y el que vas a ejecutar en la lección 05, tiene exactamente dos: un supervisor y un especialista.

5. Olvidar que cada agente, por dentro, sigue el mismo protocolo. El bloque tool_use/ tool_result, el stop_reason, el runner que los despacha: nada de eso cambia dentro de cada agente individual. Lo nuevo de esta guía es exclusivamente el mecanismo entre agentes.

Ejercicios

Ejercicio 1: Clasifica cuatro sistemas (Fácil)

Para cada uno de estos cuatro casos, decide si es "un agente con varias tools" o "un sistema multi-agente", y justifica en una frase: (a) un agente con get_quote, book_room y send_email; (b) un booking_agent y un policy_agent, cada uno con su propio registro de tools y su propia decisión; (c) un agente con quince tools distintas, todas de Reservo; (d) dos copias idénticas del mismo agente, corriendo en paralelo sobre la misma pregunta, para comparar sus respuestas.

Ejercicio 2: Diseña un cuarto especialista (Medio)

Reservo quiere agregar un feedback_agent que recopile la satisfacción de un socio después de su reserva. Define, siguiendo el patrón del ejemplo trabajado: (a) su diccionario tools (puede tener cero, una o más tools — usa una función placeholder si inventas alguna nueva), (b) una frase de expertise que lo distinga claramente de los otros tres, y (c) ejecuta el mismo bucle de impresión del ejemplo trabajado, agregando tu especialista al diccionario SPECIALISTS.

def record_feedback_stub(booking_id, stars, comment):
    """Placeholder -- Reservo no construyó esta tool en la guía; alcanza
    con declarar la forma para el propósito de este ejercicio."""
    return {"recorded": True}


SPECIALISTS["feedback_agent"] = {
    "tools": {"record_feedback": record_feedback_stub},
    "expertise": "recopilar la satisfacción de un socio después de su reserva",
}

for name, spec in SPECIALISTS.items():
    tools = list(spec["tools"])
    print(f"{name:15} {len(tools)} tool(s) {str(tools):35} expertise: {spec['expertise']}")

booking_agent   4 tool(s) ['list_rooms', 'get_quote', 'book_room', 'cancel_booking'] expertise: cotizar, reservar y cancelar salas
policy_agent    1 tool(s) ['search_docs']                     expertise: responder preguntas de política (cancelación, no-presentación)
pricing_agent   1 tool(s) ['get_quote']                       expertise: comparar el costo de varias salas/tiers en una sola respuesta
feedback_agent  1 tool(s) ['record_feedback']                 expertise: recopilar la satisfacción de un socio después de su reserva

Ejercicio 3: El caso límite de dos agentes idénticos (Difícil)

Imagina un sistema con dos agentes, booking_agent_a y booking_agent_b, ambos con el registro completo de las cuatro tools canónicas de Reservo, sin ninguna diferencia entre ellos. (a) ¿Este sistema cumple la definición formal de "sistema multi-agente" de esta lección? (b) Si alguien te dice que este diseño le da al sistema "más capacidad de razonamiento" al tener dos agentes pensando la misma tarea, ¿qué evidencia le pedirías, siguiendo el espíritu de esta guía, antes de aceptar esa afirmación? (c) ¿Bajo qué condición SÍ tendría sentido tener dos agentes con el mismo registro de tools?

Resumen y siguiente paso

• Un agente (agent-fundamentals) es un modelo, un registro de tools, un historial y un loop — una sola decisión por turno, sin importar cuántas tools tenga disponibles.
• Un sistema multi-agente (esta guía) son varios agentes, cada uno con su propio loop y registro, más un mecanismo para decidir quién trabaja, pasar información entre ellos y agregar sus resultados.
• Ejecutamos el contraste: un registro único de 4 tools vs. tres registros más angostos (booking_agent, policy_agent, pricing_agent) — y confirmamos que "agente distinto" no siempre significa "tool distinta": pricing_agent comparte get_quote con booking_agent y sigue siendo un especialista legítimo, porque lo que lo distingue es su objetivo, no su inventario de funciones.
• El error más común al empezar esta guía es llamar "multi-agente" a un agente con muchas tools — la línea real es cuántos puntos de decisión independientes hay, no cuántas tools hay en total.

Siguiente lección: 03 — El costo de la coordinación. Con la definición ya precisa, medimos qué cuesta, en llamadas al modelo y en mensajes, cada punto de decisión adicional que suma un sistema multi-agente.

Recursos adicionales

1. Anthropic — Building effective agents — La distinción entre "workflows" (orquestación predecible) y "agents" (el modelo dirige su propio proceso), base de la distinción entre un agente con tools y un sistema de varios agentes.
2. Anthropic — Multi-agent research system — Un sistema multi-agente real de Anthropic, con agentes independientes coordinados por un orquestador — la forma general que esta guía construye a mano.
3. Anthropic — Tool use (function calling) overview — El protocolo que cada agente de este sistema sigue usando, sin cambios, dentro de su propio loop.
4. Python — Diccionarios — La estructura detrás de cada registro tools de este ejemplo, la misma base de agent-fundamentals.