Cómo elige MONO qué hacer: anatomía del router

Por qué el router existe

La arquitectura ingenua — y la que veías en 2023 — era: meter las descripciones de todas las herramientas disponibles en el system prompt de GPT-4 o Claude, y esperar que el modelo elija bien. Esto funciona si tienes 5 herramientas. Se rompe con 30.

El problema es doble: tokens y distracción. Cada skill en MONO tiene un manifiesto con descripción, ejemplos y parámetros — ~800 tokens mínimo. Multiplica por 47 skills: ~38,000 tokens antes de incluir el mensaje del usuario. Claude Sonnet tiene ventana larga pero cobra por token y se confunde cuando la opción correcta está enterrada entre 46 irrelevantes.

Así que MONO inserta un paso antes: un router basado en Claude Haiku (el modelo más chico y barato de Anthropic) que lee el mensaje y devuelve un JSON compacto con las 1-3 skills relevantes y el "modo" de ejecución.

Qué ve el router

El router recibe tres cosas:

1. El mensaje del usuario (el texto plano, tal cual llegó por WhatsApp).
2. Un catálogo comprimido de todas las skills: nombre, 1 línea de descripción, y 2-3 ejemplos reales de input que deberían activarla.
3. Memoria de trabajo: datos y entidades que se mencionaron en los últimos turnos (si dijiste "María" hace 2 mensajes, el router sabe que un "manda mensaje a María" no necesita pedir apellido).

Y devuelve, en ~200ms:

{
  "skills": ["calendar", "reminders"],
  "mode": "agent",
  "confidence": 0.92
}

Los tres modos: tool, think, agent

Una de las decisiones de diseño más útiles fue distinguir cómo se ejecuta una skill:

• Tool mode: una función Go que corre sin LLM. "Agéndame reunión con Juan a las 4" ejecuta calendar.create_event con los parámetros extraídos. Rápido, determinista, barato.
• Think mode: el LLM grande razona sobre el input pero no llama más herramientas. "Resúmeme mi semana" pasa por calendar.list_events + expenses.summary y Claude compone la narrativa.
• Agent mode: el LLM hace múltiples llamadas, posiblemente con razonamiento intermedio. "Analiza mi pipeline y sugiere qué deal cerrar primero" itera: lista deals → evalúa probabilidad → busca memorias relevantes → escribe recomendación.

El router decide el modo. La mayoría de mensajes (~65%) caen en tool mode — baratísimo. ~25% son think. Solo ~10% son agent, que es donde se gasta el cómputo.

Qué pasa cuando el router se equivoca

Pasa. Cuando el usuario escribe algo ambiguo o una skill es muy parecida a otra, el router puede elegir la equivocada. Hay tres mitigaciones:

1. Logging completo. Cada decisión del router se guarda en SurrealDB con mensaje, skills elegidas, tiempo, y resultado final.
2. Analizador automático. Cada 6h, un job revisa el log y detecta casos donde la skill elegida no produjo resultado útil (ej. el usuario re-preguntó). Estos casos se marcan y se usan para mejorar los ejemplos en los manifiestos.
3. Feedback thumbs-up/down. Si marcas un resultado como malo, el mensaje original se añade al dataset de mejora.

Esto crea un loop de auto-mejora: el router se entrena sobre los errores del router. No es magia — es disciplina de logging y analítica.

La lección arquitectónica

La intuición tentadora al construir agentes es meter todo en un modelo grande y esperar lo mejor. Funciona para demos. No funciona en producción.

Los sistemas que escalan tienen capas de especialización: modelo chico + rápido para decisiones de control, modelo grande + lento para razonamiento, código determinista para todo lo que se puede hacer sin LLM. Cada capa optimiza su trade-off: el router optimiza latencia, el executor optimiza calidad, las tools optimizan costo.

Es el mismo patrón que vimos en procesadores (branch predictor → pipeline → execution units) y en web (CDN → app server → database). Los agentes IA están descubriendo que los principios de arquitectura de sistemas no dejaron de aplicar solo porque ahora el "procesador" es un LLM.