Mini-proyecto: decide single o multi

SCENARIOS = {
    "A: cotiza y reserva Focus pro 3h": {
        "separable_subtasks": False,   # book_room depende del precio que trajo get_quote
        "distinct_expertise": False,   # las dos tools ya viven en el mismo booking_agent
        "needs_isolation": False,      # nada que aislar -- un solo dominio, numérico
    },
    "B: cotiza Focus pro 3h y dime la política de cancelación": {
        "separable_subtasks": True,    # ninguna sub-pregunta depende del resultado de la otra
        "distinct_expertise": True,    # números de reserva vs. texto de políticas
        "needs_isolation": False,      # el stub de search_docs es chico -- no hay corpus real que aislar aquí
    },
    "C: resume este párrafo con un 'CEO', un 'investigador' y un 'crítico'": {
        "separable_subtasks": False,   # es UNA tarea de resumen, no varias tareas reales
        "distinct_expertise": False,   # ninguno de los tres tiene una tool que el otro no tenga
        "needs_isolation": False,      # no hay ningún dominio de datos que aislar entre "roles"
    },
    "D: onboarding (política de HR interna + reserva de la primera sala)": {
        "separable_subtasks": True,    # la política de HR no depende de qué sala se reserva, ni viceversa
        "distinct_expertise": True,    # documentos de HR vs. números de reserva -- dominios distintos
        "needs_isolation": True,       # un documento de HR largo, específico de cada empresa, no debe colar en booking_agent
    },
    "E: compara el precio de Focus, Studio y Boardroom, todos pro, 3h": {
        "separable_subtasks": True,    # las tres cotizaciones son independientes entre sí
        "distinct_expertise": False,   # las tres llaman la MISMA tool, get_quote -- ningún dominio nuevo
        "needs_isolation": False,      # nada que aislar -- todo vive en el mismo dominio numérico
    },
}

for name, scenario in SCENARIOS.items():
    verdict, score = should_go_multi_agent(scenario)
    print(f"{name}\n  señales presentes: {score}/3  ->  {verdict}\n")

Qué esperar:

A: cotiza y reserva Focus pro 3h
  señales presentes: 0/3  ->  un agente

B: cotiza Focus pro 3h y dime la política de cancelación
  señales presentes: 2/3  ->  multi-agente (a evaluar el costo)

C: resume este párrafo con un 'CEO', un 'investigador' y un 'crítico'
  señales presentes: 0/3  ->  un agente

D: onboarding (política de HR interna + reserva de la primera sala)
  señales presentes: 3/3  ->  multi-agente (a evaluar el costo)

E: compara el precio de Focus, Studio y Boardroom, todos pro, 3h
  señales presentes: 1/3  ->  un agente

El razonamiento por escenario:

Escenario A — un agente. Es exactamente la lección 05, medida. book_room necesita el price_cents que get_quote devuelve — no son independientes, así que la primera señal ya cae. El sistema de dos agentes de la lección 05 costó 2 llamadas y 2 hops de más, sin ganar nada.

Escenario B — multi-agente, y el costo SÍ se justifica. Las tres señales que la lección 06 midió en detalle: get_quote y search_docs corren en paralelo (lo ejecutaste con dispatch_parallel), viven en dominios que nunca colisionan (0 pares, aun fusionados), y en un sistema de producción real —con el corpus completo, no el stub— el aislamiento de contexto evitaría que booking_agent cargara con texto de políticas en cada request.

Escenario C — un agente, y es el caso de "roles decorativos" de la lección 01. Ninguna señal se cumple: es una sola tarea de resumen, sin sub-tareas reales que separar, y ninguno de los tres "roles" tiene una tool o un dominio de datos que lo distinga de los otros dos. Montarle tres agentes encima —CEO, investigador, crítico— no cambia el hecho de que la tarea sigue siendo: resumir un párrafo. Es el ejemplo textual de la trampa 2 de la lección 01: "roles sin una tool o expertise real detrás son decoración, no arquitectura".

Escenario D — multi-agente, el caso más fuerte del lote (3/3). Es el mismo escenario que diseñaste en el Ejercicio 3 de la lección 06: billing_agent/HR-policy-agent y booking_agent resuelven sub-preguntas independientes, en dominios que nunca colisionan, y un documento de HR específico de cada empresa contaminaría el contexto de booking_agent si viviera en el mismo agente.

Escenario E — un agente, y es la nota que ya adelantó la lección 02. Las tres cotizaciones sí son independientes entre sí (separable_subtasks=True) — podrían despacharse en paralelo con dispatch_parallel, igual que en la lección 06 — pero las tres llaman exactamente la misma tool, get_quote, sin ningún dominio de datos nuevo (distinct_expertise=False) y sin nada que aislar (needs_isolation=False). Con 1 de 3 señales, el veredicto de la heurística es "un agente" — y esto es coherente con algo que la lección 02 ya señaló sobre pricing_agent: su "expertise" no es una tool nueva, es una forma distinta de componer una tool que ya existe. pricing_agent sigue siendo parte del elenco de esta guía —los Módulos 2 a 8 lo usan como ejemplo de fan-out DENTRO de un agente—, pero el criterio estricto del Módulo 1, aplicado a este escenario puntual y aislado, no exige un agente separado para resolverlo: un solo agente, despachando tres get_quote en paralelo con dispatch_parallel —el mismo mecanismo de la lección 06, sin necesidad de un segundo agente—, ya lo resuelve completo.

No hay una única "solución de código" para la primera parte — es una verificación: si tu salida coincide con la de la solución completa, aplicaste las tres señales correctamente a los cinco escenarios.

Sobre el Escenario D: las tres señales refuerzan la misma conclusión desde ángulos distintos — separabilidad dice que no hace falta esperar a que una termine para empezar la otra; expertise distinto dice que nunca habrá confusión de tools entre las dos; aislamiento dice que mezclarlas activamente perjudicaría a una de las dos partes. Cuando las tres apuntan en la misma dirección, el caso para multi-agente deja de depender de una sola métrica — es el patrón que hace que valga la pena pagar el costo medido en la lección 03, a diferencia del Escenario B, que tiene 2/3 pero no la señal de aislamiento (el stub de search_docs es chico, sin un corpus real que proteger todavía).

SCENARIOS["F: agrega una nota interna sobre un socio difícil, visible solo para el equipo de Reservo"] = {
    "separable_subtasks": False,   # es una sola acción: agregar la nota, no hay nada que paralelizar
    "distinct_expertise": False,   # sigue viviendo en el dominio de booking, no hay tool de otro dominio
    "needs_isolation": True,       # la nota interna no debería aparecer en la respuesta que ve el socio -- hay que aislar QUIÉN la lee, no un dominio de tools distinto
}

verdict, score = should_go_multi_agent(SCENARIOS["F: agrega una nota interna sobre un socio difícil, visible solo para el equipo de Reservo"])
print(f"señales presentes: {score}/3  ->  {verdict}")

Salida esperada:

señales presentes: 1/3  ->  un agente

Explicación: con solo needs_isolation=True, el veredicto sigue siendo "un agente" — la misma conclusión que el Escenario E, pero por una razón distinta. Aquí el aislamiento que hace falta no es "un dominio de datos que contamina a otro" (el sentido que le dio la lección 06) sino quién puede ver qué —una nota interna no debería filtrarse en una respuesta al socio—. Eso es un problema real, pero de un tipo distinto: control de acceso sobre lo que un agente muestra, no una razón para dividir su trabajo en dos agentes. Ese tipo de control —qué información expone un agente y a quién— es terreno de agent-security-and-sandboxing-guide, nombrada aquí sin construirse, no una señal que por sí sola justifique un segundo especialista.

def should_go_multi_agent_with_cost(scenario, estimated_extra_calls, estimated_frequency,
                                     daily_threshold=500):
    signals = [scenario["separable_subtasks"], scenario["distinct_expertise"],
               scenario["needs_isolation"]]
    score = sum(signals)
    daily_extra_calls = estimated_extra_calls * estimated_frequency

    if score < 2:
        return "un agente", score, daily_extra_calls
    if daily_extra_calls > daily_threshold:
        return (f"multi-agente JUSTIFICADO por señales, pero el costo diario "
                f"({daily_extra_calls} llamadas de más) supera el umbral -- "
                f"revisar si un pipeline (M3) cuesta menos que un supervisor (M2) "
                f"antes de construir"), score, daily_extra_calls
    return "multi-agente (costo diario aceptable)", score, daily_extra_calls


scenario_b = SCENARIOS["B: cotiza Focus pro 3h y dime la política de cancelación"]

# Con supervised_cost(n_specialists=2) de la lección 03: 2 llamadas de más.
for frequency in (10, 1000):
    verdict, score, daily = should_go_multi_agent_with_cost(
        scenario_b, estimated_extra_calls=2, estimated_frequency=frequency,
    )
    print(f"frecuencia={frequency}/día -> señales={score}/3, costo diario={daily}, veredicto: {verdict}")

Salida esperada:

frecuencia=10/día -> señales=2/3, costo diario=20, veredicto: multi-agente (costo diario aceptable)
frecuencia=1000/día -> señales=2/3, costo diario=2000, veredicto: multi-agente JUSTIFICADO por señales, pero el costo diario (2000 llamadas de más) supera el umbral -- revisar si un pipeline (M3) cuesta menos que un supervisor (M2) antes de construir

Explicación: las señales de la lección 06 no cambian con la frecuencia —el Escenario B sigue teniendo 2/3 en los dos casos—, pero el costo acumulado sí depende de cuántas veces al día se ejecuta la tarea. A 10 veces al día, 20 llamadas de más es un costo trivial; a 1000 veces al día, 2000 llamadas de más empieza a justificar buscar un patrón de coordinación más barato —el pipeline de la lección 03 (Ejercicio 3), con menos hops que un supervisor para el mismo número de etapas—. Este ejercicio es exactamente el punto de la trampa 1 de los Errores comunes de esta lección: un score alto es una señal para investigar, no una autorización automática para construir el patrón más caro sin comparar alternativas.