El coste oculto de los agentes de IA: Por qué la arquitectura importa más que el modelo

Llevamos ya mas de un año hablando de cómo construir agentes. LangGraph, CrewAI, Google ADK, Strands, RAG, memory, tools, MCP. Apenas hablamos de cuánto cuestan. Y es el siguiente paso del que casi nadie te avisa al llevar estos sistemas a producción.

En PoC, la pregunta es: ¿funciona? En producción, la pregunta es otra: ¿funciona a un coste sostenible? Y la respuesta no es cambiar de modelo (que también es una solución, un parche). Está en la arquitectura.

Después de ver bastantes facturas reales, la diferencia entre un agente bien optimizado y uno que no lo está puede ser de 5x a 10x. Ratios de ahorro del 50-90%, sin tocar el modelo.

Voy con las dos palancas que más impacto tienen.

La primera es el prompt caching. Casi cualquier agente serio arranca con un system prompt grande. Reglas de negocio, few-shots, definiciones de tools, contexto fijo. Fácilmente 10k-30k tokens estables. Por defecto, eso se reprocesa entero en cada llamada del loop.

Aquí entra el K/V cache. Si la primera parte del prompt no cambia entre llamadas, los tensores se reutilizan. No se recalculan. Anthropic cobra los tokens cacheados al 10% del precio base. Un 90% de descuento. OpenAI da un 50% automático en prefijos cacheados a partir de 1.024 tokens.

La regla es simple: estable arriba, dinámico abajo. System prompt → few-shots → tools → documentos → mensaje del usuario.

El detalle que se nos pasa: el match es exacto. Un timestamp donde no toca, un reordenamiento de tools, un espacio de más, y el caché se rompe entero. Es mecánico. Y es la palanca individual más rentable que vas a aplicar.

La segunda es la higiene de contexto. Un agente acumula basura. Outputs de tools, logs, ficheros enteros, reintentos, estado duplicado. Y se queda dentro del contexto, turno tras turno, pagándolo cada vez. He visto agentes que arrancan en 3k tokens y a los 15 turnos están en 80k.

La solución no es «compactar al final»(que también es útil). Es construir un pipeline de estado desde el principio. Lo que se queda: decisiones de arquitectura, bugs no resueltos, ficheros en scope. Lo que se va: outputs crudos, logs de tests, dumps duplicados, intentos fallidos.

Hay benchmarks recientes donde una compresión x6 del contexto da un 51-71% de ahorro de tokens y un 5-9% más de resolución en SWE-bench. Lo que más me gusta de esta palanca: a diferencia del caching o el routing, no hay tradeoff de calidad. Limpiar contexto te ahorra dinero y mejora el agente.

Hay otras palancas, por mencionarlas: Semantic caching para patrones tipo FAQ. Routing y cascading: clasificar antes, o empezar barato y escalar. Subagentes con modelos pequeños para tareas acotadas.

Cuando llevas un agente a producción, la elección del modelo no es la decisión más cara que tomas. La decisión más cara es cómo le mandas el prompt, qué le metes en contexto, y cuándo realmente necesitas la inferencia.

Y eso ya no es una conversación de modelo. Es una conversación de arquitectura.