7. Costo y latencia de un sistema multi-agente

Descripción

Al terminar esta lección vas a poder calcular, con datos que ya están en el panel de ejecuciones de n8n, cuánto cuesta y cuánto tarda una conversación en tu sistema multi-agente comparada con lo que costaría y tardaría en un solo agente; vas a poder aplicar seis palancas concretas para bajar ese número sin perder precisión; y vas a poder decidir, con un criterio explícito, cuándo un especialista no vale lo que cuesta y hay que colapsarlo de vuelta.

Esto importa porque hasta aquí este módulo te vendió una idea —separar responsabilidades mejora la precisión— sin cobrarte el precio. El precio existe y no es pequeño: en la traza de la lección 3 viste siete llamadas al modelo para responder un mensaje que un agente monolítico habría respondido con tres. Eso es más del doble en costo y, lo que suele doler más, más del doble en tiempo de espera del cliente. En un demo no se nota. En un sistema que atiende dos mil conversaciones al mes sí, y la conversación con quien paga la factura llega tarde o temprano. Poder decir "cada conversación cuesta X y tarda Y, y sin delegación costaría 0.4X pero fallaría en el 15% de los casos" es lo que convierte una decisión técnica en una decisión defendible. Es también, muy concretamente, lo que separa a alguien que armó un sistema de alguien que lo puso en producción.

Conexión con el módulo: la lección 6 acotó el número de vueltas que tu sistema puede dar. Esta lección traduce esas vueltas a dinero y a segundos, y te da las palancas para ajustarlas. Es el contrapeso honesto de todo el módulo: aquí es donde se justifica cada agente que creaste en la lección 2, o donde se descubre que uno de ellos no se justifica. La lección 8 aplica todo esto al mini-proyecto, con una medición real como criterio de entrega.

La reunión que costó más que la decisión

Piensa en una reunión de trabajo donde hay que decidir algo pequeño: qué proveedor de café contratar. Están seis personas, cada una gana un salario, la reunión dura una hora. El ahorro anual entre el proveedor A y el proveedor B es modesto. Alguien hace la cuenta en voz baja y descubre que la reunión costó más que la diferencia entre los dos proveedores.

Nadie hizo nada mal. Cada persona aportó algo válido. El problema es que el mecanismo de decisión —seis personas, una hora— era desproporcionado para la decisión que había que tomar.

Un sistema multi-agente tiene exactamente este riesgo, y con la misma cara amable: cada delegación aporta algo válido, cada especialista mejora la precisión de su parte, y aun así el conjunto puede terminar costando más de lo que vale. La diferencia con la reunión es que aquí sí puedes hacer la cuenta con precisión, y deberías.

Y hay una asimetría que conviene entender desde ahora: el costo de delegar se paga siempre, la precisión que compra se cobra solo a veces. Cada conversación paga las llamadas al modelo del especialista, incluyendo las conversaciones simples donde el monolito habría acertado igual. La ganancia de precisión aparece solo en los casos difíciles. Si tu tráfico es 90% casos simples y 10% difíciles, estás pagando el mecanismo caro el 100% del tiempo para ganar en el 10%. Eso puede seguir valiendo la pena —depende de cuánto cuesta un error en ese 10%— pero es una cuenta que hay que hacer, no una intuición.

De dónde sale el costo

Para poder bajar un número hay que entender de qué está hecho. El costo de una conversación en un sistema con LLM se compone de tokens de entrada y tokens de salida, y en un sistema multi-agente hay cuatro fuentes que no existen en un agente suelto.

Fuente 1 — Cada iteración reenvía todo el contexto

Esta es la más importante y la menos intuitiva. Un modelo de lenguaje no tiene memoria entre llamadas: cada iteración del bucle agéntico manda de nuevo el system prompt completo, las descripciones de todas las tools, y todo lo acumulado hasta ese momento.

Entonces, cuando el billing_specialist da cuatro iteraciones, no pagas su system prompt una vez: lo pagas cuatro veces. Y con él, las descripciones de sus tres tools, cuatro veces. Y el encargo, cuatro veces. Más los resultados de las tools que se van acumulando.

Iteración 1: [system prompt] + [3 descripciones de tools] + [encargo]
Iteración 2: [system prompt] + [3 descripciones] + [encargo] + [resultado tool 1]
Iteración 3: [system prompt] + [3 descripciones] + [encargo] + [res. 1] + [res. 2]
Iteración 4: [system prompt] + [3 descripciones] + [encargo] + [res. 1] + [res. 2] + [res. 3]

El contexto crece en cada vuelta y todo lo anterior se vuelve a pagar. Por eso Max Iterations no es solo una condición de parada: es una palanca de costo de primer orden, y por eso un especialista que se atasca es tan caro.

Fuente 2 — El orquestador también itera, y su contexto incluye lo que devuelven los especialistas

El orquestador hace lo mismo, con el agravante de que su contexto incluye la conversación completa (tiene la memoria conectada) más el resultado de cada delegación. Después de dos delegaciones, la tercera llamada al modelo del orquestador lleva encima el historial de la conversación, las descripciones de sus tres especialistas, y los dos summary que ya recibió.

Fuente 3 — El encargo autocontenido

Aquí pagas por una decisión de diseño que tomaste en la lección 3. Como el especialista no tiene memoria, el orquestador tiene que meterle en el encargo todos los datos relevantes de la conversación. Ese encargo puede ser considerablemente más largo que el mensaje original del cliente, y viaja en cada iteración del especialista.

Es un costo real y es un buen negocio: la alternativa —darle memoria al especialista— duplicaría el historial completo en vez de un resumen, con los problemas de sincronización de la lección 3 encima. Pero hay que conocerlo, porque es donde se esconde una palanca: un encargo de tres frases bien escritas cuesta mucho menos que uno de tres párrafos, y suele funcionar igual o mejor.

Fuente 4 — Los tokens de salida del especialista que nadie lee

El especialista produce un summary. El orquestador lo lee y escribe su propia respuesta al cliente. Es decir: pagas por generar un texto intermedio que el cliente nunca ve. Eso es inevitable en el patrón, y es otra razón para que el contrato de salida de la lección 5 pida un summary de dos o tres frases y no un relato completo.

La fórmula aproximada

No hay una fórmula exacta —depende de tus prompts, tus tools y tu caso— pero esta aproximación sirve para razonar:

Costo de una conversación ≈
    (iteraciones del orquestador × contexto promedio del orquestador)
  + Σ para cada delegación:
      (iteraciones de ese especialista × contexto promedio de ese especialista)

Lo importante de esa expresión no es calcularla con precisión: es notar que las iteraciones multiplican, no suman. Bajar el Max Iterations de un especialista de 8 a 4 no baja su costo un 50% de forma lineal — lo baja más, porque las iteraciones que se eliminan son las de contexto más grande, las del final.

Latencia: por qué se suma y no se reparte

El costo se puede discutir. La latencia la siente el cliente.

La propiedad estructural que hay que entender es esta: una delegación es una llamada a una tool, y una llamada a una tool bloquea al agente que la hizo. El orquestador manda el encargo al billing_specialist y se queda esperando. Mientras el especialista razona, llama tres tools y vuelve a razonar, el orquestador no está haciendo nada. Cuando el especialista devuelve, el orquestador retoma.

tiempo →

orquestador  ██                    ██                    ██
                 └─ billing ─────┘     └─ order ──────┘
                    ████████████         ████████

El tiempo total es la suma de todo, no el máximo. Y dentro del tiempo de cada especialista está, a su vez, la suma de sus propias llamadas al modelo y a sus tools.

Una traza como la de la lección 3 —tres llamadas al modelo del orquestador, dos del especialista de facturación más tres llamadas a tools, dos del de pedidos más una a tool— acumula siete llamadas al modelo y cuatro a sistemas externos, todas en serie. Si cada llamada al modelo tarda un par de segundos y cada tool otro tanto, ya estás en un rango donde el cliente nota la espera.

¿Se puede paralelizar? Con matices, y conviene ser honesto. Un modelo puede, en un mismo turno, solicitar más de una llamada a tool; cuando eso ocurre, esas llamadas no dependen unas de otras y no tienen por qué ejecutarse una después de la otra. Pero no es algo que tú controles con un parámetro: depende de que el modelo decida pedirlas juntas, lo cual depende del modelo, del prompt y del caso. No diseñes contando con eso. Diseña asumiendo que las delegaciones son secuenciales, y si a veces se solapan, mejor.

Lo que sí controlas es cuántas delegaciones hay. Un mensaje que dispara dos delegaciones tarda aproximadamente el doble que uno que dispara una. Esa es la palanca real de latencia, y es la misma que la de costo: menos vueltas.

Ejemplo trabajado: la hoja de costo de una conversación

Vamos a hacer la cuenta para TuTienda. Aviso importante antes de empezar: los números que siguen son hipotéticos, puestos para que veas la forma del cálculo. Los precios por token de cada proveedor cambian con frecuencia y varían mucho entre familias de modelos, así que el número que a ti te importa tienes que sacarlo de la ejecución real y del precio vigente de tu proveedor el día que lo midas. Lo que no cambia es el método.

El caso: el mensaje de las lecciones anteriores —cargo no reconocido más consulta de pedido—, que dispara dos delegaciones.

Para poder comparar, ponemos una unidad hipotética: digamos que una llamada al modelo del orquestador (con memoria conectada, contexto grande) equivale a 3 unidades de costo, y una llamada al modelo de un especialista (contexto más pequeño, prompt corto) equivale a 1 unidad. Los números son inventados; las proporciones son plausibles porque el contexto del orquestador incluye el historial y el del especialista no.

Escenario A — Agente monolítico

Llamada	Unidades
Modelo (decide, llama lookup_charge)	3
Modelo (evalúa, llama get_customer_profile)	3
Modelo (evalúa, llama open_dispute)	3
Modelo (llama lookup_order)	3
Modelo (compone respuesta)	3
Total	15 unidades

Escenario B — Equipo con delegación

Llamada	Unidades
Orquestador: decide delegar	3
billing_specialist: razona	1
billing_specialist: tras lookup_charge	1
billing_specialist: tras get_customer_profile	1
billing_specialist: tras open_dispute, produce resultado	1
Orquestador: evalúa, decide delegar el segundo tema	3
order_specialist: razona	1
order_specialist: tras lookup_order, produce resultado	1
Orquestador: compone respuesta final	3
Total	15 unidades

Ese resultado sorprende y vale la pena mirarlo con cuidado, porque desarma dos ideas simplistas.

El equipo hizo nueve llamadas al modelo contra cinco del monolito —casi el doble— y aun así el costo salió parecido. La razón es la fuente 1: el monolito paga su contexto gigante (nueve descripciones de tools, un system prompt de 900 palabras, la memoria completa) en cada una de sus cinco iteraciones. El equipo paga contexto grande solo en las tres llamadas del orquestador; las seis del especialista son baratas porque su contexto es pequeño.

Eso no significa que delegar sea gratis. Significa dos cosas más precisas:

1. En costo, la diferencia suele ser menor de lo que sugiere el conteo de llamadas, y depende sobre todo de cuánto contexto arrastra cada nivel. Un monolito con prompt enorme puede ser más caro que un equipo bien repartido.
2. En latencia, la diferencia sí es la del conteo de llamadas. Nueve llamadas en serie tardan claramente más que cinco, independientemente de lo que cueste cada una. Aquí no hay compensación posible: el equipo es más lento, punto.

Ahora hagamos la cuenta que de verdad decide. Supón —hipótesis, otra vez— que en pruebas con cien casos el monolito responde correctamente el 82% y el equipo el 94%. Con dos mil conversaciones al mes:

Monolito: 18% de 2,000 = 360 conversaciones con algún defecto
Equipo:    6% de 2,000 = 120 conversaciones con algún defecto

Diferencia: 240 conversaciones al mes que se resuelven bien
            en vez de terminar en un cliente molesto o en un
            ticket que alguien del equipo tiene que atender a mano.

Si atender a mano una de esas conversaciones cuesta más que la diferencia de costo entre los dos escenarios —y en atención al cliente casi siempre cuesta más, porque involucra tiempo de una persona— la delegación se paga sola. Ese es el argumento completo, y fíjate que no es "multi-agente es mejor": es una comparación de dos costos con un dato de precisión en el medio.

Cómo medir de verdad

Todo lo anterior es razonamiento. Esto es lo que haces en tu instancia.

1. Activa la traza en todos los niveles. Return Intermediate Steps en el orquestador y en cada especialista. Sin esto no puedes contar nada.

2. Cuenta las llamadas al modelo por nivel. En la traza, cada "llamada al modelo" es una iteración. Anota cuántas hizo el orquestador y cuántas cada especialista. Ese conteo es tu métrica de latencia, porque las llamadas son secuenciales.

3. Lee el uso de tokens. Los nodos de modelo de chat de n8n reportan el uso de tokens de cada llamada en los datos de salida de la ejecución. Ábrelos en el panel de ejecución y anota tokens de entrada y de salida. Ahí es donde vas a ver, con tus propios ojos, la fuente 1: el contexto creciendo en cada iteración.

4. Lee el tiempo. El panel de ejecuciones muestra la duración de la ejecución completa y de cada nodo. Compara la duración total contra la suma de las duraciones de los agentes para ver dónde se va el tiempo.

5. Arma la hoja. Con veinte o treinta ejecuciones representativas construyes algo así:

# Hoja de costo por conversación — TuTienda, medición de N ejecuciones

                          típico    p90     peor observado
  Llamadas al modelo         7       12          19
  Delegaciones               1        2           3
  Tokens de entrada       …        …           …
  Tokens de salida        …        …           …
  Duración (segundos)       …        …           …
  Costo estimado          …        …           …

La columna que más se usa en la práctica no es la del caso típico: es la p90, el valor por debajo del cual queda el 90% de las conversaciones. El típico te dice cómo se siente el sistema; la p90 te dice cuánto vas a pagar de verdad al final del mes, porque los casos caros pesan más de lo que su frecuencia sugiere.

Y una recomendación de método: mide antes de optimizar. La intuición sobre dónde se va el costo en un sistema multi-agente es notoriamente mala — mucha gente jura que el problema son las delegaciones y al medir descubre que el 60% del gasto está en el system prompt de 900 palabras que nadie recortó.

Las seis palancas

En orden aproximado de rendimiento sobre esfuerzo.

Palanca 1 — Escalonar modelos por nivel

La de mejor relación esfuerzo-beneficio, y la más ignorada. El orquestador toma una decisión pequeña: elegir entre tres opciones bien descritas y componer un texto. No necesita el modelo más capaz que exista. Los especialistas que toman decisiones costosas —abrir disputas, evaluar garantías— sí.

triage_agent        → modelo rápido y económico
billing_specialist  → modelo capaz (decisiones sobre dinero)
order_specialist    → modelo intermedio
sales_specialist    → modelo rápido y económico

Y como cada agente tiene su propio puerto Chat Model, esto se hace conectando nodos de modelo distintos. No hay ninguna complicación técnica: es una decisión que se toma o no se toma.

Al hacerlo, mide otra vez. Bajar el modelo del orquestador puede degradar la calidad del enrutamiento, y si eso pasa, el ahorro se lo come el aumento de casos mal delegados. La forma de verificarlo: corre el mismo conjunto de veinte casos con el modelo caro y con el barato, y compara a qué especialista delegó en cada uno.

Palanca 2 — Acortar el encargo

El encargo viaja en cada iteración del especialista. Un encargo de tres párrafos en un especialista que da cuatro iteraciones se paga cuatro veces.

La regla: el encargo debe traer los datos, no el relato.

# Encargo caro (y peor)
"El cliente escribió que está muy molesto porque le llegó un cobro
que no reconoce, dice que revisó su tarjeta y encontró un cargo de
$1,200 del mes pasado, mencionó que hace tiempo compró unos audífonos
pero que ese cargo no coincide con nada, y también preguntó antes por
un pedido pero eso ya lo resolvimos, así que ahora necesita que
revisemos ese cargo específicamente porque…"

# Encargo barato (y mejor)
"Cliente C-9931. Cargo de $1,200 el 18/07 no reconocido. El cliente
descarta que corresponda a su compra de audífonos. Verificar y, si no
corresponde a ninguna compra, abrir disputa."

El segundo tiene todos los datos que el especialista necesita y ninguna de la narrativa que no usa. Y hay un beneficio adicional que no es de costo: el especialista se distrae menos. El relato largo introduce información irrelevante que compite por atención — el mismo fenómeno de dilución de la lección 2, ahora en el encargo.

Esto se implementa en la description del $fromAI("task", ...): pídele explícitamente un encargo de datos, breve, sin narrativa.

Palanca 3 — Bajar Max Iterations

Ya lo trabajaste en la lección 6 como condición de parada. Aquí es una palanca de costo, y de las buenas, porque las iteraciones que eliminas son las de contexto más grande.

Calíbralo con la regla del máximo observado más dos, por nivel. Si un especialista nunca pasó de tres iteraciones en treinta ejecuciones, tenerlo en 10 no le da flexibilidad: le da margen para atascarse caro.

Palanca 4 — Reemplazar un agente por un sub-workflow determinista

La palanca más grande cuando aplica, porque no reduce el costo: lo elimina.

Pregúntate, para cada especialista: ¿este agente está tomando alguna decisión que requiera interpretar lenguaje o elegir entre caminos? Si la respuesta es no —si lo que hace es consultar algo, aplicar una regla fija y devolver un resultado— eso no es un agente. Es un sub-workflow, y ya sabes construirlo desde la lección 6 del Módulo 4.

Ejemplo concreto: un "especialista de elegibilidad de devolución" que consulta la fecha de compra, mira la categoría y aplica un plazo. Cero interpretación, cero elección. Como agente cuesta entre dos y cuatro llamadas al modelo cada vez que se usa. Como sub-workflow cuesta cero, es determinista, y se puede probar con datos fijos.

Esto no es reducir el sistema: es ponerle a cada pieza el mecanismo que le corresponde. Un sistema multi-agente maduro suele tener menos agentes de los que tenía al principio y más sub-workflows.

Palanca 5 — Colapsar un especialista que no gana lo que cuesta

La palanca incómoda. Si un especialista se llama muy poco, o si cuando se llama sus decisiones son triviales, quizá no debería existir como agente separado.

La medición: cuenta cuántas veces se llamó cada especialista en cien conversaciones, y para cada llamada, cuántas iteraciones usó. Un especialista que se llama tres veces de cada cien y siempre resuelve en una iteración con una sola tool no está aportando criterio — sus tools podrían vivir en otro especialista con un par de líneas más de prompt, y el sistema tendría un nivel menos de indirección.

Es incómodo porque significa deshacer algo que construiste. Vale la pena hacerlo igual: la lección 2 dijo que el corte se justifica con evidencia, y esa regla corta en los dos sentidos.

Palanca 6 — Enseñarle al orquestador a no delegar

Muchas conversaciones no necesitan ningún especialista. "Hola", "gracias", "¿a qué hora atienden?", "ok perfecto". Si el orquestador delega en esos casos, estás pagando una delegación completa por un saludo.

# Fragmento del System Message de triage_agent

  No delegues cuando:
  - El mensaje es un saludo, un agradecimiento o una confirmación
    ("ok", "listo", "gracias").
  - La pregunta es sobre horarios, ubicación o canales de contacto:
    responde tú directamente con la información que ya tienes.
  - Necesitas un dato del cliente antes de poder armar un encargo
    útil: pregúntaselo primero, delega después.

  Delega solo cuando el caso requiera consultar un sistema o aplicar
  una regla de negocio de un dominio específico.

Esa última línea del bloque —preguntar antes de delegar— es especialmente rentable. Delegar un encargo incompleto casi siempre termina en pending_info, o sea: pagaste una delegación completa para que te dijeran que falta un dato que el orquestador ya sabía que faltaba.

La regla de decisión

Con todo lo anterior, la pregunta "¿vale la pena delegar aquí?" se puede responder con un criterio en vez de con una preferencia:

Delegar se justifica cuando la reducción de errores, medida sobre casos reales, vale más que el aumento de costo y de latencia, medidos sobre los mismos casos.

Tres situaciones donde el criterio se inclina claramente hacia no delegar:

• El volumen es alto y los casos son homogéneos. Diez mil conversaciones al mes de un mismo tipo. Ahí cada unidad de costo se multiplica por diez mil, y la ganancia de precisión sobre casos que ya eran fáciles es pequeña.
• Hay una restricción dura de latencia. Un agente de voz al teléfono. Cada delegación agrega una ronda completa; si tu presupuesto es de un par de segundos, la delegación no cabe.
• El especialista no toma decisiones. Palanca 4: eso es un sub-workflow.

Y tres donde se inclina hacia sí delegar:

• El costo de un error es alto. Dinero, datos borrados, un compromiso legal frente a un cliente. Ahí la precisión vale mucho más que la diferencia de costo.
• Los dominios tienen reglas que se contaminan. Cuando un prompt único produce el modo 3 de la lección 2 y ninguna cantidad de instrucciones lo arregla.
• El radio de daño importa. Cuando quieres que un agente físicamente no pueda ejecutar ciertas acciones, y no solo que tenga prohibido hacerlo por escrito.

Errores comunes

Medir solo el orquestador (práctico). Qué pasa: alguien mira el uso de tokens del nodo de modelo del orquestador, ve un número razonable, y concluye que el sistema es barato. Los especialistas tienen sus propios nodos de modelo, con su propio consumo, que no aparece ahí. Por qué pasa: en el panel de ejecución el orquestador es el nodo principal y es donde uno mira primero. Cómo detectarlo: suma los tokens de todos los nodos de modelo de la ejecución, no solo del primero; si tu total no incluye una línea por cada especialista que se llamó, está incompleto. Cómo corregirlo: la unidad de medición es la conversación completa, con todos sus niveles — arma la hoja de costo sumando todos los nodos de modelo que participaron.

Optimizar por intuición sin medir primero (práctico). Qué pasa: alguien está convencido de que el costo está en las delegaciones, dedica un día a colapsar especialistas, y el costo baja un 8% — porque el 60% estaba en un system prompt largo que se reenviaba en cada iteración de todos los agentes. Por qué pasa: las delegaciones son lo más visible del sistema y lo más nuevo, así que la atención va ahí. Cómo detectarlo: antes de tocar nada, mira el uso de tokens de entrada de la primera iteración de cada agente; ese número es tu costo de arranque por llamada, y si es grande, ahí está tu problema. Cómo corregirlo: mide primero, y ataca la fuente más grande — muchas veces es acortar prompts y descripciones, que es más fácil y menos arriesgado que rediseñar la arquitectura.

Confundir "menos llamadas" con "más barato" (conceptual). Qué pasa: alguien colapsa dos especialistas en uno para reducir llamadas al modelo, y el costo sube — porque el especialista fusionado tiene ahora seis tools y un prompt del doble de largo, que se reenvía en cada una de sus iteraciones. Por qué pasa: contar llamadas es fácil y contar tokens es más trabajo, así que se usa la métrica fácil como si fuera la correcta. Cómo detectarlo: el escenario A y el B del ejemplo trabajado de esta lección — nueve llamadas costaron lo mismo que cinco. Cómo corregirlo: para costo, mide tokens; para latencia, cuenta llamadas. Son dos métricas distintas que responden a dos preguntas distintas, y optimizar una puede empeorar la otra.

Bajar el modelo de todos los agentes a la vez (práctico). Qué pasa: alguien aplica la palanca 1 cambiando los cinco modelos en la misma sesión, el costo baja bastante, y la calidad también — pero como cambiaron cinco cosas juntas, no hay forma de saber cuál fue la que rompió. Por qué pasa: es más rápido y se siente eficiente. Cómo detectarlo: si después de una tanda de cambios la calidad bajó y no puedes atribuirla a uno solo, ya te pasó. Cómo corregirlo: cambia un modelo, corre tu conjunto de casos de prueba, compara, y recién entonces cambia el siguiente — es más lento y es la única forma de saber qué funcionó.

Presentar el costo sin el dato de precisión al lado (conceptual). Qué pasa: alguien lleva a una reunión el número "el sistema multi-agente cuesta 2.3 veces más que el anterior" y la conversación termina ahí, con una decisión de volver atrás. Por qué pasa: el costo es un número duro y la precisión requiere haberla medido, así que es fácil llevar solo la mitad de la historia. Cómo detectarlo: si tu reporte tiene una cifra de costo y ninguna de tasa de acierto, está incompleto por diseño. Cómo corregirlo: mide las dos cosas sobre el mismo conjunto de casos y preséntalas juntas — "2.3 veces el costo, y 12 puntos más de acierto, que equivalen a 240 conversaciones al mes que ya no llegan a un humano" es una frase que se puede discutir; media frase no.

Ejercicios

Ejercicio 1 — Encuentra dónde se va el costo. Un equipo mide su sistema y encuentra esto (números hipotéticos, en tokens de entrada por llamada):

triage_agent:        iteración 1: 4,200   iteración 2: 5,100   iteración 3: 6,000
billing_specialist:  iteración 1: 1,100   iteración 2: 1,400
order_specialist:    iteración 1: 3,900   iteración 2: 4,100

¿Dónde está el problema más evidente y qué palanca aplicarías primero?

Ver solución

El problema evidente es el order_specialist: arranca en 3,900 tokens de entrada en su primera iteración, cuando el billing_specialist arranca en 1,100. Los dos son especialistas, ninguno tiene memoria conectada, y los dos reciben un encargo. Una diferencia de casi cuatro veces en el punto de partida solo puede venir de dos lugares: un system prompt mucho más largo, o descripciones de tools mucho más largas — o un encargo desproporcionado.

La primera acción es abrir los dos nodos y comparar. Si el system prompt del order_specialist tiene 800 palabras contra 140 del de facturación, ahí está el 100% del problema, y la corrección es recortarlo (probablemente arrastra reglas de dominios que ya no le corresponden). Si los prompts son parecidos, mira el encargo: aplica la palanca 2.

Lo que no haría primero: tocar la arquitectura. El triage_agent creciendo de 4,200 a 6,000 entre iteraciones es normal y esperable —tiene la memoria conectada y va acumulando los resultados de las delegaciones—; es la fuente 1 funcionando como debe, no un defecto.

Por qué funciona: comparar el arranque de dos piezas equivalentes es la forma más rápida de encontrar una anomalía. Cuando dos cosas que deberían parecerse no se parecen, ahí está el problema, y casi nunca hace falta calcular nada más.

Ejercicio 2 — Decide si el especialista se queda. En cien conversaciones medidas, el sales_specialist se llamó 4 veces. En las cuatro usó una sola iteración y llamó a recommend_products una vez. Su system prompt tiene 120 palabras. ¿Lo colapsas o lo dejas? ¿Qué dato adicional te haría cambiar de opinión?

Ver solución

Con esos datos, la evidencia apunta a colapsarlo. Cuatro llamadas de cien es poco tráfico; una iteración con una sola tool significa que no está tomando ninguna decisión interesante —recibe un encargo, llama la tool, devuelve—; y un prompt de 120 palabras cabe sin problema como un párrafo adicional en otro especialista, o incluso sus dos tools podrían colgar directamente del orquestador si la decisión de usarlas es trivial. Estás pagando un nivel de indirección por algo que no aporta criterio.

Dos datos que cambiarían la decisión:

El primero, de riesgo: si la recomendación de producto tiene una regla que no quieres mezclada con otro dominio —por ejemplo, la contaminación de rol de la lección 2, donde el agente termina vendiéndole a un cliente en disputa— entonces la separación no se justifica por costo sino por arquitectura, y el costo de mantenerla es bajísimo (cuatro llamadas de cien). Ahí se queda.

El segundo, de futuro: si el equipo de TuTienda va a lanzar una campaña donde el tráfico de ventas pase de 4% a 40%, colapsarlo hoy para tener que volver a separarlo en dos meses es trabajo perdido. La evidencia de uso pasado no siempre predice el uso futuro, y vale la pena preguntarlo antes de deshacer algo.

Por qué funciona: la palanca 5 se aplica con datos, pero los datos de uso no son el único criterio. Un especialista puede justificarse por lo que impide que ocurra, no solo por lo que resuelve — y ese beneficio no aparece en un conteo de llamadas.

Ejercicio 3 — Arma el argumento. Tienes que justificar ante quien paga la factura por qué el sistema nuevo cuesta más que el anterior. Tienes estos datos medidos (hipotéticos): el sistema anterior costaba 1.0 unidad por conversación con 79% de acierto; el nuevo cuesta 2.1 unidades con 93% de acierto. El volumen es de 3,000 conversaciones al mes, y cada conversación que el sistema no resuelve bien le cuesta al equipo unos 8 minutos de una persona. Escribe el argumento en tres o cuatro frases.

Ver solución

Un argumento posible:

"El sistema nuevo cuesta 2.1 veces más por conversación, así que sobre 3,000 conversaciones al mes el gasto en modelo sube en unas 3,300 unidades. A cambio, la tasa de acierto pasó de 79% a 93%: eso son 420 conversaciones al mes que antes terminaban en el equipo y ahora se resuelven solas. A 8 minutos cada una, son unas 56 horas de trabajo al mes que se liberan. Habría que revisar los dos números contra el cierre del próximo mes para confirmarlo, pero con esta medición el ahorro en tiempo del equipo supera con holgura el aumento de costo del modelo."

Tres cosas que hacen que ese argumento funcione. Primera: pone las dos cifras juntas, costo y precisión, en vez de defender una y esconder la otra. Segunda: traduce la precisión a la unidad que le importa a quien decide —horas del equipo—, no a puntos porcentuales. Tercera: se presenta como una medición que hay que confirmar, no como una verdad cerrada, que es lo honesto cuando trabajas con una muestra.

Y una cosa que evita: prometer un ahorro neto en dinero sin conocer el costo por hora del equipo. Si no tienes ese dato, la frase correcta es "56 horas al mes que se liberan", no una cifra en pesos que tendrías que inventar.

Por qué funciona: la conversación sobre costo de un sistema de IA se gana con la comparación completa, no con el número más favorable. Y llevar el dato de precisión medido, no estimado, es lo que hace que la comparación se sostenga cuando alguien pregunta de dónde salió.

Resumen y siguiente paso

Ya tienes la calculadora. El costo de un sistema multi-agente sale de cuatro fuentes: cada iteración reenvía todo el contexto, el orquestador arrastra la conversación completa, el encargo autocontenido viaja en cada vuelta del especialista, y el summary intermedio se paga aunque el cliente nunca lo lea. Las iteraciones multiplican, no suman. La latencia, en cambio, es simplemente la suma de las llamadas en serie, y ahí no hay compensación: delegar es más lento. Se mide con Return Intermediate Steps, el uso de tokens de cada nodo de modelo y los tiempos del panel de ejecuciones, y se resume en una hoja por conversación con su columna p90. Y hay seis palancas: escalonar modelos, acortar el encargo, bajar Max Iterations, reemplazar un agente por un sub-workflow determinista, colapsar un especialista que no gana lo que cuesta, y enseñarle al orquestador a no delegar cuando no hace falta.

Antes de avanzar deberías poder: explicar por qué nueve llamadas al modelo pueden costar lo mismo que cinco; armar una hoja de costo por conversación con datos de tu propio panel de ejecuciones; nombrar las seis palancas y cuál atacarías primero según lo que muestre la medición; y presentar el costo junto al dato de precisión, traducido a la unidad que le importa a quien decide.

Con esto tienes el módulo completo: el diagnóstico (lección 2), la arquitectura (3), el cableado (4), el contrato (5), los frenos (6) y la economía (7). Falta ponerlo todo junto y verificarlo funcionando. La lección 8 es el mini-proyecto: un sistema de triage con dos o tres especialistas, construido de punta a punta, con sus handoffs verificados, sus condiciones de parada probadas contra casos adversarios, y su hoja de costo medida — el entregable que puedes mostrar y defender.

Recursos

• View past executions — n8n Docs — el panel donde se leen duraciones por nodo y se abren los datos de salida de cada llamada al modelo; la fuente de todos los números de esta lección.
• AI Agent node — n8n Docs — Max Iterations y Return Intermediate Steps, la palanca 3 y el instrumento de medición.
• Cluster nodes — n8n Docs — el catálogo de sub-nodos de modelo de chat, para elegir modelos distintos por nivel (palanca 1).
• Call n8n Workflow Tool — n8n Docs — el mecanismo con el que se ejecuta la palanca 4: reemplazar un agente por un sub-workflow determinista.
• Building Effective AI Agents — Anthropic — el argumento de fondo de esta lección: la complejidad agéntica solo se justifica cuando mejora un resultado medible, y conviene empezar por la solución más simple.