Parte 1 de “Sistemas Multi-Agente en Producción: Lo Que No Te Cuentan” — una serie de cuatro partes que sigue la saga de Horcrux Hunt, un juego multi-agente de Harry Potter que le enseñó al autor todo sobre IA en producción de la forma más cara.
El Fin de Semana en que Mi Juego Costó Más que Mi Renta
El autor construyó Horcrux Hunt, un juego interactivo temático de Harry Potter donde dos agentes de IA batallan en vivo frente a una audiencia. Harry (el protagonista, impulsado por Claude en Amazon Bedrock via Strands SDK) caza Horrocruxes escondidos en 15 ubicaciones. Voldemort (el adversario) los reubica, planta señuelos y corrompe las creencias de Harry.
Imagínalo como un juego de escondite adversarial entre dos LLMs, con una audiencia en vivo votando y viendo la búsqueda de Harry en tiempo real en un dashboard de Streamlit.
Lo que iba a ser un demo divertido de fin de semana terminó en una pesadilla de costos.
La factura: $1,847 por un fin de semana.
Más que su renta.
Y el rendimiento era terrible:
- 12 segundos de latencia por turno (la audiencia esperaba literalmente)
- 23% de tasa de victoria para Harry (casi nunca ganaba)
- 18% de timeout (funciones Lambda muriendo a medio pensar)
- 67% de los costos solo en llamadas LLM de Bedrock
Los comentarios de la audiencia decían cosas como “el juego es lento” y “Harry casi nunca gana”. No sabían que además los estaba llevando a la bancarrota.
Por Qué los Sistemas Multi-Agente Cuestan Más de lo Que Piensas
Construimos sistemas multi-agente. Seguimos agregando agentes para cada tarea. Pero nunca preguntamos: “¿Cuántos agentes son demasiados?” Aquí está la fórmula que nadie muestra cuando promocionan arquitecturas multi-agente:
Costo = tokens × agentes × turnos × reintentos × reproducción_de_contextoCada término multiplica a los otros. No es aditivo, es multiplicativo.
Las Ventanas de Contexto se Combinan Exponencialmente
Cada turno de Horcrux Hunt, el juego le alimenta a Harry el historial completo de la conversación. Para el turno 50, eso es MUCHO. Cada turno, el LLM relee el historial completo. Es como si Harry leyera su diario de misión completo desde la página uno cada vez que toma una decisión. Para el turno 50, estás pagando 7.5× lo que costó el turno 1, y eso es solo un agente.
Con dos agentes (Harry Y Voldemort), tienes 2× la curva de tokens. Cada agente manteniendo su propio contexto inflado.
Los Tokens de Salida son el Asesino Oculto
La mayoría se enfoca en los tokens de entrada. Pero los tokens de salida cuestan 5× más que los de entrada en la mayoría de los modelos (Claude 3 Sonnet: $0.003/1K input vs $0.015/1K output). Y son secuenciales: cuestan 12ms por token y no se pueden paralelizar.
Las respuestas de Harry promediaban 150-200 tokens de salida por turno. Las de Voldemort promediaban 100-150. En 50 turnos × 2 agentes, los tokens de salida representaron el 39% del tiempo total. La audiencia esperaba por generación de tokens, no por pensamiento.
Un Turno es en Realidad 12 Operaciones
Lo que el autor imaginaba que era un turno:
- Harry piensa → 2. Harry actúa → 3. Voldemort responde
Lo que un turno realmente requería:
- Cargar estado del juego desde DynamoDB
- Calcular acciones válidas
- Construir contexto de Harry (comprimir historial)
- Llamar a Bedrock para decisión de Harry
- Validar respuesta de Harry
- Ejecutar acción de Harry
- Calcular contexto de Voldemort
- Llamar a Bedrock para decisión de Voldemort
- Validar respuesta de Voldemort
- Ejecutar acción de Voldemort
- Actualizar estado compartido del juego
- Persistir en DynamoDB + emitir métricas CloudWatch
50 turnos × 12 operaciones = 600 operaciones por juego. La naturaleza secuencial es el verdadero cuello de botella.
Fallar Lento, Fallar Caro
El 15% de las respuestas LLM fallaban la validación. Harry producía un formato de acción inválido, o intentaba buscar una ubicación en enfriamiento. Cada fallo: 3 segundos de razonamiento → rechazado → contexto completo reproducido → intentar de nuevo. Cada reintento costaba el precio completo de tokens.
“Fallar rápido, fallar gratis” — el principio que cambió todo.
Las Matemáticas de Costo que Dieron Miedo
- Por juego: ~$1.95 (enfoque inicial)
- 1,000 juegos/día: $1,950/día
- Mensual: ~$49,000
- Anual: ~$588,000
Para un juego. Un juego de dos agentes donde Harry caza Horrocruxes.
El desglose de costos:
- Bedrock (llamadas LLM): 67% — $1.31/juego
- Lambda (cómputo): 26% — $0.51/juego
- DynamoDB (estado): 7% — $0.13/juego
Los Cuatro Fixes: Una Escalera de Optimización
No necesitaba menos agentes. Necesitaba menos decisiones costosas.
Fix 1: Acotar el Problema (Poda de Restricciones)
Antes: Harry veía 90 acciones posibles por turno (15 ubicaciones × 6 tipos de acción) y el LLM tenía que razonar cuáles eran válidas.
Después: Un solucionador de restricciones poda las acciones inválidas antes de que el LLM de Harry las vea:
def get_valid_actions(game_state, agent="harry"):
actions = []
for loc in game_state.locations:
if game_state.cooldown[loc] == 0:
if game_state.usage_count[loc] < game_state.max_uses[loc]:
if game_state.action_budget[loc] > 0:
actions.append(loc)
return actions # típicamente 2-4 opciones, no 90Resultado: 90 opciones → 2-4 opciones válidas. 80% de reducción en tokens de razonamiento inválidos.
“Fail Fast, Fail Free” — captura errores antes de que toquen el LLM.
Fix 2: Reemplazar Tokens con Matemáticas (Inferencia Bayesiana)
Antes: Harry releía 50 turnos de historia narrativa (5,000 tokens) para descubrir “¿dónde está el Horrocrux probablemente?”
Después: Un mapa de creencias bayesiano calcula probabilidades fuera del LLM:
class HorcruxBeliefMap:
def __init__(self, locations):
n = len(locations)
self.beliefs = {loc: 1.0/n for loc in locations}
def update_on_signal(self, loc, signal):
if signal == "positive":
self.beliefs[loc] *= 3.0
elif signal == "negative":
self.beliefs[loc] *= 0.1
self.normalize()Lo que el LLM de Harry ve: "top_target: Hogwarts (p=0.34), Azkaban (p=0.22)" = 15 tokens, no 5,000.
Resultado: 97% de reducción de contexto. Costo de $0.015 a prácticamente $0.
Fix 3: Saltar la Llamada al LLM (Árboles de Decisión Heurísticos)
No cada decisión de Voldemort necesita un modelo de $200 mil millones:
def voldemort_decide(game_state):
if game_state.harry_adjacent_to_horcrux():
return RelocateAction(game_state.threatened_horcrux)
if game_state.decoy_budget > 0 and harry_entropy(game_state) < 3.0:
return PlantDecoyAction()
if game_state.harry_confidence() < 0.3:
return WaitAction()
return call_llm_for_strategy(game_state)Resultado: 60% de las decisiones de Voldemort manejadas sin costo LLM.
Fix 4: Aislar la Capa Costosa (Arquitectura)
El cambio más impactante fue estructural. Solo 2 de 8 módulos tocan el LLM:
Módulos GRATIS (6):
- Motor de Juego (reglas, gestión de turnos)
- Solucionador de Restricciones (cómputo de acciones válidas)
- Gestor de Creencias (actualizaciones bayesianas)
- Persistencia de Estado (DynamoDB)
- Capa de Validación (verificación de formato)
- Métricas y Logging (CloudWatch)
Módulos COSTOSOS (2):
- Capa Estratégica de Harry (decisiones genuinamente inciertas)
- Capa Estratégica de Voldemort (solo cuando las heurísticas no deciden)
Los Resultados
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Costo por juego | $1.95 | $0.35 | -82% |
| Latencia por turno | 12s | 3s | -75% |
| Tasa de victoria de Harry | 23% | 52% | +29pp |
| Tasa de timeout | 18% | <3% | -83% |
| Tasa de reintentos | 15% | <3% | -80% |
| Costo anual a escala | $588K | $102K | -$486K |
Harry gana más, no porque el modelo sea más inteligente, sino porque razona sobre información enfocada y relevante en lugar de ahogarse en 6,000 tokens de ruido. La audiencia ve turnos de 3 segundos en lugar de esperas de 12 segundos.
La Lección
La respuesta a “¿Cuántos agentes son demasiados?” no es un número. Es una pregunta:
“¿Vale esta decisión una llamada al LLM?”
La escalera de optimización:
- ¿Puede una regla manejarlo? (Gratis — restricciones, enfriamientos, presupuestos)
- ¿Puede una heurística manejarlo? (Casi gratis — lógica if/then)
- ¿Pueden las matemáticas manejarlo? (Barato — actualizaciones bayesianas, entropía)
- ¿Realmente necesita un LLM? (Caro — pero justificado para incertidumbre genuina)
Empuja cada decisión lo más ABAJO posible en esa escalera. Falla rápido, falla gratis en cada capa.
“Sigue explorando estos temas en el blog de DojoFullStack — tenemos artículos sobre optimización de sistemas multi-agente, arquitecturas de IA y mejores prácticas para llevar tus agentes a producción sin arruinarte en el intento.”