Nueve agentes encadenados: 73% menos tokens y ciclos de evaluación un 70% más rápidos

Monogram, una agencia de producto, ha publicado el caso de su generador para una plataforma de desarrolladores: nueve agentes encadenados que convierten un caso de uso escrito en lenguaje natural en código funcional, una vista previa interactiva y una guía de implementación en menos de cuatro minutos. El sistema atiende entre 800 y 1.000 usuarios al día. La primera versión en producción consumía unos 30.000 tokens y hacía entre 15 y 20 llamadas a modelos de gama Pro por cada petición.

La lección que sacan no es que nueve agentes resuelvan más que uno. Es que la fiabilidad sale de decidir qué trabajo se queda el modelo, qué contexto es obligatorio y dónde conviene un contrato estricto en lugar de generación libre.

Dos etapas sin modelo

El pipeline tiene un agente raíz que gestiona el estado de sesión, el enrutado y la composición de instrucciones en tiempo de ejecución, y agentes especializados para análisis, estilos, generación de código, evaluación, refinamiento y documentación. Dos de las nueve etapas no llaman a ningún LLM: el Schema Validator comprueba de forma determinista la configuración generada, y el Documentation Builder localiza las APIs del código final y las mapea a URLs de un registro canónico. Reglas que se pueden expresar directamente se implementan como software normal, con lo que esas etapas dejan de consumir tokens y desaparecen dos fuentes de alucinación.

También separan al evaluador del refinador: pedirle a un agente que genere código y apruebe su propia salida deja un bucle de retroalimentación flojo. El evaluador aplica reglas estrictas y escaneo de seguridad; el refinador recibe hallazgos concretos y corrige solo eso. Todo agente que produzca código o configuración firma un esquema de salida estructurado, para que no se cuele comentario libre en algo que va a parsear otro agente.

Contexto obligatorio frente a recuperación opcional

Los agentes de análisis, generación y evaluación tiran del Model Context Protocol para consultar documentación de APIs viva en una base de conocimiento indexada, con los resultados acotados y el servidor MCP como servicio aislado para no competir por cuota con las llamadas a modelos. El problema es que la consulta la decide el agente: un modelo seguro de sí mismo puede saltársela y escribir código plausible pero inválido. La solución fue la inyección dinámica de instrucciones. El análisis detecta qué APIs hacen falta y los ejemplos canónicos de esas APIs se insertan directamente en las instrucciones posteriores; la recuperación abierta se reserva para lo exploratorio. Con ese cambio, el consumo de tokens por petición bajó un 73%.

El primer despliegue usaba Gemini 2.5 Pro para generar, evaluar y refinar. Funcionaba, pero a ese volumen el coste y la latencia no se sostenían. El sistema pasó por cinco fases de ingeniería: inyección dinámica, escalonado de modelos por tarea (los ciclos de evaluación quedaron un 70% más rápidos, sin pérdida de calidad medida), caché y controles de presupuesto, y telemetría en BigQuery con observabilidad estructurada. Los entornos van con Terraform en desarrollo, staging y producción, con puertas de CI/CD y servicios de Google Cloud: Vertex AI Agent Engine, Cloud Run, Secret Manager y Cloud Logging. Hay además bucles de autocorrección de seguridad, vuelta a la última salida válida cuando algo falla y reintentos en tres capas.

Las cifras son suyas: no hay benchmark independiente detrás de ese 73% ni de ese 70%, y el caso lo cuenta quien lo construyó. Lo reutilizable es el criterio. Buscar los modos de fallo que se pueden probar por separado, dejar en software determinista lo que no necesita interpretación, inyectar el contexto cuando la corrección depende de que el modelo lo vea y no dejar que quien escribe el código sea quien lo aprueba.