El patrón Router en agentes IA: escala sin refactorizar

AI Integration

•8 de agosto de 2026•6 min read•Por Daily Miranda Pardo

Montar el primer agente IA es fácil. Montar el quinto es donde todo explota.

Cuando un equipo tiene un solo agente, la arquitectura no importa demasiado: entra un prompt, sale una respuesta, listo. Pero en cuanto aparecen casos de uso distintos — soporte, ventas, facturación, onboarding — alguien tiene que decidir qué agente atiende qué petición. Y si esa decisión no tiene una arquitectura detrás, el proyecto se convierte en deuda técnica desde el primer día.

Esto es el problema de routing. Y es el motivo por el que muchos proyectos multi-agente funcionan en demo y fallan en producción.

Por qué el routing ingenuo se rompe pronto

Cuando los equipos escalan sin planificar el routing, suelen caer en uno de estos dos errores:

El agente todoterreno

La solución más rápida: un único agente con acceso a todas las herramientas. Le pasas el contexto completo, le das veinte tools, y esperas que el modelo decida solo.

El resultado en producción:

Costes desbocados: estás enviando el contexto completo en cada llamada aunque el usuario solo quiera saber el horario de atención.
Alucinaciones de tool selection: el modelo elige la herramienta equivocada con más frecuencia cuanto mayor es el catálogo disponible (esto ya lo cubrimos en el artículo sobre tool calling en producción).
Imposible de testear: no puedes escribir un test determinista para un agente que puede hacer cualquier cosa.

El if/else infinito

La segunda trampa: un bloque de condiciones en el entrypoint que despacha al agente correcto según palabras clave o reglas hardcodeadas.

// El antipatrón que parece razonable al principio
if (message.includes("factura") || message.includes("pago")) {
  return billingAgent.run(message);
} else if (message.includes("ayuda") || message.includes("problema")) {
  return supportAgent.run(message);
} else {
  return genericAgent.run(message);
}

Funciona para los tres casos del MVP. En cuanto tienes veinte casos de uso y varios idiomas, es inmantenible. Además no hay fallback, no hay score de confianza, y cualquier variación lingüística rompe el routing silenciosamente.

El patrón Router: arquitectura que escala

El Router es un componente explícito cuya única responsabilidad es clasificar la intención de entrada y despachar al agente especializado correcto. No ejecuta lógica de negocio, no llama a APIs externas, solo clasifica y delega.

Request → Router → [ BillingAgent | SupportAgent | SalesAgent | FallbackAgent ]

La clave es que el Router es stateless, testeable y con una responsabilidad única. Cada agente especializado tiene su propio conjunto reducido de herramientas, su propio system prompt optimizado para ese dominio, y su propia lógica de escalado.

Implementación mínima en TypeScript

// types.ts
type Intent = "billing" | "support" | "sales" | "unknown";

interface RouterResult {
  intent: Intent;
  confidence: number; // 0-1
  reasoning: string;
}

interface AgentRegistry {
  [key: string]: (input: string, context: Context) => Promise<AgentResponse>;
}

// router.ts
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function classifyIntent(input: string): Promise<RouterResult> {
  const response = await client.messages.create({
    model: "claude-haiku-4-5-20251001", // modelo rápido y barato para clasificación
    max_tokens: 256,
    system: `Clasifica la intención del usuario en una de estas categorías:
- billing: preguntas sobre facturas, pagos, suscripciones, precios
- support: problemas técnicos, errores, configuración, ayuda de uso
- sales: interés en productos, demostraciones, preguntas preventa
- unknown: cualquier otra cosa o ambigua

Responde SOLO con JSON: {"intent": "...", "confidence": 0.95, "reasoning": "..."}`,
    messages: [{ role: "user", content: input }],
  });

  const text = response.content[0].type === "text" ? response.content[0].text : "{}";
  return JSON.parse(text) as RouterResult;
}

const agentRegistry: AgentRegistry = {
  billing: billingAgent,
  support: supportAgent,
  sales: salesAgent,
  unknown: fallbackAgent,
};

export async function routeRequest(
  input: string,
  context: Context
): Promise<AgentResponse> {
  const { intent, confidence } = await classifyIntent(input);

  // Si la confianza es baja, ir a fallback directamente
  if (confidence < 0.7) {
    return agentRegistry.unknown(input, context);
  }

  const agent = agentRegistry[intent] ?? agentRegistry.unknown;
  return agent(input, context);
}

Este patrón tiene tres ventajas inmediatas: el clasificador es testeable de forma aislada, el threshold de confianza es configurable sin tocar los agentes, y añadir un nuevo agente es agregar una entrada al registro sin modificar el routing.

Router determinista vs. LLM-based: cuándo usar cada uno

No siempre necesitas un LLM para clasificar. La regla es simple:

Router determinista (regex, scoring de keywords, vector similarity):

El catálogo de intenciones es fijo y conocido
La latencia de clasificación importa (< 20ms)
Quieres zero tokens adicionales en clasificación
Los casos de uso son predecibles y bien delimitados

Router LLM-based (el ejemplo anterior con Claude Haiku):

Las intenciones son ambiguas o expresadas en lenguaje natural libre
Los usuarios escriben en varios idiomas
El catálogo de intenciones cambia con frecuencia
Necesitas el campo reasoning para debugging o logging

En proyectos reales, lo habitual es un router híbrido: primero pasa por un clasificador determinista rápido (regex sobre patterns obvios), y si no hay match con suficiente confianza, escala al clasificador LLM. Esto reduce el coste del routing entre un 60-80% en producción.

Los errores más comunes al implementar el router

No tener fallback definido. Si el router no sabe dónde enviar una petición, lo que hace por defecto es lanzar un error o usar el agente genérico sin avisar. Define siempre un fallbackAgent explícito que pueda escalar a humano si es necesario. En la sección de agentes con Human-in-the-Loop explicamos cuándo y cómo hacer esa escalación.

Timeout sin configurar. La clasificación LLM puede tardarse. Si el router no tiene un timeout propio, un fallo del clasificador bloquea toda la cadena. Pon siempre un AbortSignal con timeout:

const controller = new AbortController();
setTimeout(() => controller.abort(), 3000); // 3s máximo para clasificar

const response = await client.messages.create(
  { /* ... */ },
  { signal: controller.signal }
);

Router que acumula lógica de negocio. El Router solo clasifica y delega. En cuanto empieza a tomar decisiones del tipo "si es usuario premium, enviar al agente X aunque la intención sea Y", has creado un componente que nadie podrá mantener en seis meses. Esa lógica va dentro del agente, no en el router.

Sin métricas de routing. Si no sabes qué porcentaje de peticiones van a unknown, no sabes si tu clasificador está funcionando. Loguea siempre intent, confidence y el agente que finalmente atendió cada petición.

Por qué importa esto en tu arquitectura

El Router no es un componente de optimización que añades cuando tienes tiempo. Es la pieza que determina si tu sistema multi-agente puede crecer de tres a diez agentes sin un refactor completo.

Los equipos que no lo plantean desde el principio se encuentran a los tres meses con un entrypoint de 400 líneas que nadie quiere tocar, agentes duplicados que hacen cosas parecidas, y un sistema donde cada cambio de negocio requiere modificar el routing manualmente.

En DAILYMP diseñamos sistemas multi-agente con este patrón desde el primer sprint: router explícito, agentes especializados con responsabilidades acotadas, fallback definido y métricas desde el primer día. El resultado es un sistema que el equipo puede mantener y extender sin necesitar al arquitecto original cada vez que aparece un nuevo caso de uso.

¿Tienes más de un agente en producción y el routing es un if/else que nadie quiere tocar? Hablamos y lo revisamos juntos.