El problema de la orquestación está mayormente resuelto. El problema del enrutamiento no.
Los 4B tokens por día de Okara a través de múltiples proveedores de LLM en Vercel deberían ser una canaria en tu mina de carbón. No están lidiando con la orquestación—LangGraph e Inngest han convertido eso en una mercancía. Están luchando contra el enrutamiento de tokens, el fallback de proveedores y el control de costos a volumen. Esa es la verdadera restricción.
La mayoría de equipos de agentes aún diseñan como si hubiera un modelo detrás de la cortina. Una única llamada a openai.ChatCompletion.create() con gpt-4o, en todas partes. Eso funciona hasta que cruzas ~100M tokens/día. Luego llega la factura y la arquitectura tiene que cambiar: múltiples proveedores, selección de modelo por sub-agente, presupuestos de latencia que realmente importan, cadenas de fallback que sobreviven 429s y 5xxs. Para entonces estás refactorizando a escala en lugar de planificarlo desde el primer día.
La diferencia de costo entre stacks conscientes del enrutamiento e ingenuos es a menudo de 3–5x. No puedes resolver eso solo en la capa del modelo.
Ocho sub-agentes especializados, ocho backends de inferencia diferentes
Un sistema de agentes real no llama a un modelo. Llama a muchos. Un clasificador/enrutador en Claude Haiku o gpt-4o-mini (<300ms p95). Síntesis de recuperación de contexto largo en Gemini 2.0 o Claude con una ventana de 200k tokens. Generación de código en Claude Sonnet o GPT-4.1. Extracción estructurada en un modelo abierto ajustado a través de Fireworks o Together. Un paso de guardrail como su propia llamada económica. Actualización de embedding como una línea de costo separada. Sub-agentes de nivel de voz que necesitan Groq o Cerebras para tiempo-al-primer-token sub-100ms.
Cada uno de estos tiene diferentes expectativas de latencia, necesidades de contexto y puntos de precio. Tratarlos a todos igual—enrutándolos todos a tu modelo "principal"—desperdicia tokens y quema presupuesto. Dimensionar correctamente el bucle de razonamiento de tu agente significa elegir el modelo más económico que pueda hacer el trabajo para cada sub-agente, luego construir el enrutador que lo enforce.
Los SLAs de latencia por sub-agente son el contrato que tu enrutador enforce
Decir "mi agente se ejecuta en 3 segundos" es sin sentido. Necesitas 2.5 segundos totales: 200ms ruta + 400ms recupera + 1.5s genera + 400ms herramienta. Cada salto tiene su propio presupuesto y el enrutador es lo que lo enforce.
Rastrea p50/p95/p99 por sub-agente, no por agente. Tiempo-al-primer-token y finalización total son SLOs separados. Cuando un proveedor golpea la cola de latencia (respuestas ocasionales de 8 segundos de Anthropic, cascadas de límite de velocidad de OpenAI), el enrutador necesita cancelar esa llamada y hacer fallback a un proveedor secundario dentro del presupuesto restante. Esa es la semántica de AbortController en el SDK de Vercel AI, o timeout + cancellation equivalente en cualquier gateway que construyas.
Las escaleras de fallback funcionan así: proveedor primario → proveedor secundario → modelo degradado (más económico, más rápido) → respuesta en caché. También necesitas circuit breakers—si un proveedor comienza a devolver 429s o 5xxs, apágalo durante 5–10 minutos y desvía esas solicitudes a backups. Almacena ese estado en Redis, no en memoria, para que todas tus instancias de gateway estén de acuerdo.
El fallback de proveedor es una decisión de producto, no un detalle de SRE
Los apagones de Anthropic se disparan el día que anuncian un nuevo modelo. Los límites de velocidad de OpenAI son dependientes de región y nivel de usuario. Los patrones de agotamiento de cuota de Google son diferentes nuevamente. Tus reglas de fallback no pueden ser genéricas; tienen que ajustarse a los modos de fallo reales del proveedor.
¿Qué cuenta como "la misma respuesta" entre proveedores? Si tu sub-agente está generando esquema JSON (salida estructurada), el fallback es seguro—Claude y GPT-4 estarán de acuerdo en la forma. Si es generación creativa o texto sensible al tono, no lo harán. Construye diferentes reglas de fallback para sub-agentes determinísticos vs. creativos.
Usa claves de idempotencia + colas de letra muerta para manejar generaciones reintentadas. Empareja eso con observabilidad: Helicone, Langfuse, o spans de OpenTelemetry caseros por llamada de proveedor. Necesitas ver qué proveedores son lentos, cuáles están fallando y qué estás pagando por sub-agente. La abstracción de proveedor del SDK de Vercel AI es un punto de partida, no la línea de meta—agregarás una capa de gateway delgada (la tuya, LiteLLM, Portkey, u OpenRouter) encima.
Enrutamiento de costos: la regla 70/20/10
Hemos comenzado a enviar con una heurística simple: 70% del tráfico a modelos económicos/rápidos a ~$0.25–1/M tokens (Claude Haiku, gpt-4o-mini, Llama 3.3 70B en Groq). 20% a nivel medio a ~$3–15/M tokens (Sonnet, GPT-4.1). 10% a frontera a ~$15–75/M tokens (Opus, o1). Un clasificador de dificultad—en sí mismo una llamada de sub-agente—determina a qué bucket pertenece una solicitud. Se paga a sí mismo dentro de ~50k solicitudes.
El almacenamiento en caché de prompts reduce el costo de entrada 50–90% en prompts de sistema repetidos. Las ventanas de 5 minutos/1 hora de Anthropic y el almacenamiento en caché automático de OpenAI ambos funcionan. Capa en almacenamiento en caché semántico (Redis o pgvector) para prompts de usuario de alta recurrencia. Cálculo de dorso de sobre: 4B tokens/día enrutados ingenuamente a frontera = ~$60M/año. Enrutados inteligentemente = ~$8–12M/año.
Qué construir el primer día para no reconstruir el día 400
No disperses llamadas de SDK en tu base de código. Construye una capa de gateway delgada—la tuya o a través de LiteLLM/Portkey—y enruta todo a través de ella. Registra cada llamada: ID de sub-agente, modelo, proveedor, tokens dentro/fuera, costo, latencia, conteo de reintentos. Envía eso a un almacén (BigQuery, Snowflake) para que tus equipos de finanzas e ingeniería vean los mismos números.
Marca con bandera los intercambios de modelo para que los cambios de enrutamiento no requieran deploys. Construye un conjunto de eval sintético por sub-agente para que puedas hacer pruebas A/B de proveedores sin enviar regresiones. Agrega un interruptor de parada por proveedor para cuando (no si) uno se cae durante 4 horas.
Si estás pasado 50M tokens/día y aún llamando SDKs directamente, ese es el momento para agregar un gateway. Hemos hecho esta migración dos veces este año—comunícate si quieres un segundo par de ojos antes de que llegue la factura.