Orquestar sin quemar: multi-agente para RFPs y la economía de los tokens
"Hemos migrado todas nuestras soluciones a sistemas basados en orquestación de agentes... pero la factura se ha disparado, ¿por qué?"
Eso me lo preguntaba un cliente en petit comité, después de migrar todas sus iniciativas a entornos multi-agénticos, mejorar los resultados con claridad y, en paralelo, multiplicar costes muy por encima de lo previsto. Es la misma encrucijada que aparece en cualquier sistema multi-agente cuando pasa de la fase qué chulo a la fase qué presupuesto le asigno. El multi-agente funciona; el problema es que funciona caro.
En los últimos meses he construido (y reconstruido) tres versiones distintas de un sistema multi-agente para responder RFPs: una aplicación web con IA paso a paso, una segunda iteración basada en flujos n8n, y la versión actual — un orquestador con subagentes especializados que generan .docx, .pptx y un Excel económico real. Cada una me enseñó algo distinto sobre cuándo el multi-agente compensa, cuándo no, y, sobre todo, qué palancas existen para mitigar su coste sin renunciar a su valor. Hay una que casi nadie menciona y que se ha convertido en la diferencia entre tener un sistema operable y tener un experimento caro: agentes que no consumen el RAG, sino que lo construyen.
Por qué multi-agente para una RFP
Una RFP medianamente seria — pliego administrativo, técnico, anexos, plantillas obligatorias, requisitos de cumplimiento, criterios de adjudicación, precios objetivo — es exactamente el tipo de tarea para la que el multi-agente está pensado: complejidad alta, subtareas heterogéneas, valor del entregable elevado. El presales que la responde a mano dedica entre dos y cinco días-persona por propuesta, y la mayor parte de ese tiempo no es escribir — es leer, clasificar, buscar referencias internas, calcular precios y revisar coherencia.
Las cuatro subtareas que aparecen siempre son:
- Extracción y clasificación de requisitos — leer el pliego, separar técnico, legal, comercial y plazos; identificar criterios de exclusión, mapear lo obligatorio frente a lo deseable.
- Búsqueda de antecedentes y soluciones — encontrar propuestas anteriores similares, casos de éxito relevantes, fichas de producto, referencias de cliente.
- Generación de bloques de respuesta — redactar la parte técnica, la parte de servicios, la parte de equipo y los anexos.
- Cálculo de coste y precio — montar el modelo de pricing, ajustar márgenes y generar el Excel de costes y la oferta económica.
Cada subtarea necesita herramientas distintas, contexto distinto y se puede ejecutar en paralelo con las demás durante buena parte del tiempo. Eso es exactamente lo que un sistema multi-agente bien diseñado hace mejor que un único modelo: paralelizar la exploración y especializar la ejecución. Anthropic publicó datos contundentes al respecto: en la evaluación BrowseComp, un sistema multi-agente con Opus como lead y Sonnet como subagentes superó a Opus en solitario en un 90,2%. La trampa: ese sistema consume aproximadamente 15× más tokens que una conversación de chat normal, y el 80% de la varianza de rendimiento se explica por uso de tokens.
Es decir: el multi-agente no es magia, es comprar más cómputo a cambio de calidad. La pregunta entera del artículo es cómo gastar ese cómputo de forma quirúrgica.
Las tres iteraciones
Iteración 1 · La aplicación web "paso a paso"
La primera versión la monté como una app web Next.js con Prisma y MySQL — internamente la llamamos generadorOfertas — que guía al usuario por un flujo lineal: crear proyecto → subir el PDF/DOCX/XLSX del pliego → análisis contextual con IA → gestión de secciones reutilizables → chat con IA por sección → generación del DOCX final. Detrás, un único modelo (azure/gpt-4.1) servido por LiteLLM y Redis como sidecars en Azure Container Apps, con observabilidad en Langfuse.
La fontanería de generación es interesante: cinco scripts Python (merge_docs.py, structure_content_with_ai.py, apply_corporate_styles.py, convert_pdf_to_docx.py, extract_excel.py) hacen el trabajo pesado. merge_docs.py recibe un array de secciones — algunas en HTML editable de TipTap, otras como DOCX preexistentes — y compone el documento final aplicando estilos corporativos desde una plantilla base.
Funcionó para la primera ronda de pruebas y topó pronto con dos límites. Primero, los prompts crecían: cada paso necesitaba contexto del anterior y al final el modelo recibía decenas de miles de tokens por llamada para hacer cosas relativamente simples. Segundo, no escalaba al alto: hacer paralelismo real desde una arquitectura síncrona Next.js es feo, los timeouts HTTP de 120 s son una espada de Damocles, y el flujo de pasos quedaba hardcoded. Todo iba además a un único modelo: ni routing entre tareas fáciles y duras, ni embeddings activos para retrieval (estaban configurados pero sin uso real).
Eso no la descartó como herramienta — la situó. generadorOfertas sigue en uso y en evolución para pliegos previsibles o estándar, donde la rigidez del flujo es una ventaja: el comercial sabe exactamente qué pasos tiene que tocar, los tiempos de respuesta encajan en su jornada y el coste por propuesta es bajo. Para esa franja la aplicación es la opción correcta. El problema aparece cuando el pliego sale del estándar — y ahí necesitaba algo distinto.
Iteración 2 · Flujos n8n
La segunda versión movió la lógica a n8n. La gracia para este caso es que el grafo es visual: un coordinador disparaba en paralelo cuatro ramas — extractor, buscador interno con RAG, redactor por bloque y calculador de pricing — y los hand-offs se veían en pantalla. El coste por propuesta cayó alrededor de la mitad gracias al paralelismo y la latencia pasó de minutos largos a un par de minutos.
Pero apareció el problema clásico de las arquitecturas low-code de orquestación: el coordinador es tonto a propósito. n8n no decide en tiempo real si necesita un quinto subagente porque acaba de descubrir que el pliego tiene un anexo de SLA inesperado. Hay que diseñar todas las ramas posibles de antemano. Para los pliegos "tipo" funcionaba bien; para los pliegos raros — y los pliegos raros son los que más margen dejan — se quedaba corto. Esta iteración la descartamos: cubría un terreno que ya cubría la webapp, sin aportar lo que necesitábamos para los casos no estándar.
Iteración 3 · Orquestador con subagentes especializados
La versión actual — la llamamos presales_agent internamente — está hoy en desarrollo activo como alternativa definitiva para responder cualquier pliego u oferta, especialmente los que se salen del patrón. Es un sistema Python con framework propio sobre LiteLLM, capaz de hablar indistintamente con la API de Anthropic, AWS Bedrock o un proxy interno (CLIProxyAPI). El orquestador maneja una máquina de estados con cuatro fases (discovery → sizing → deliverables → iteration) y un tool-use loop con catorce tools sobre las que decide en cada turno. La arquitectura, simplificada:
Orchestrator (claude-opus-4-7)
├─ DocParser ────────→ extrae VMs, tablas, SLA del pliego
├─ DocAnalyzer ──────→ summary, keypoints, entidades, priority
├─ CloudSizer ───────→ dimensiona Cloud privado Econocom
├─ CloudPublicoSizer → dimensiona Azure/AWS gestionado
├─ MSPSizer ─────────→ perfiles de servicios gestionados
├─ CatalogAgent ─────→ búsqueda fuzzy + semántica en SQLite
├─ OfferReviewer ────→ revisa duplicados, gaps, inconsistencias
├─ DocGenerator ─────→ Word narrativo sobre plantilla Econocom
├─ PPTGenerator ─────→ PowerPoint sobre plantilla branded
└─ PricingEngine ────→ Python puro, sin LLM
El salto cualitativo respecto a n8n es que el orquestador toma decisiones en tiempo real. Si el pliego es tipo cloud_privado, invoca CloudSizer; si es cloud_publico, invoca CloudPublicoSizer; si es mixto, ambos. Si el reviewer detecta una incoherencia, el orquestador re-encola con feedback específico. Genera además los entregables finales en formato cliente — .xlsm con macros VBA preservadas, .docx con la plantilla corporativa y .pptx con el branding — sin pasos manuales intermedios. Para el Excel, una pasada de LibreOffice headless fuerza el recálculo de fórmulas antes de entregar, para que el cliente lo abra y vea números, no celdas vacías.
Y aquí, naturalmente, llegó el problema.
La factura
Tras las primeras dos semanas de pruebas con pliegos reales, los tokens consumidos por propuesta se habían multiplicado por siete respecto a la versión n8n. La cifra absoluta no la voy a publicar — depende mucho del tipo de pliego y del cliente — pero el orden de magnitud bastaba para que la conversación dejase de ir de "qué bien funciona" y pasase a ir de "cuánto va a costar mantener esto cuando entre en producción".
Lo curioso es que la calidad de salida estaba claramente por encima — los compañeros que revisaron las primeras propuestas lo notaron sin que se lo dijéramos. El multi-agente hacía su trabajo. El problema era estructural: tres comportamientos del orquestador inflaban el coste sin aportar.
Primero, rework loops sin disciplina. La literatura reciente apunta a que los loops de revisión y re-elaboración consumen alrededor del 59% de los tokens en sistemas agénticos. El reviewer detectaba algo, devolvía a un redactor, el redactor reescribía, el reviewer volvía a mirar — y a veces se quedaba en bucle hasta agotar un límite duro.
Segundo, expansión innecesaria. Anthropic lo describe textualmente en su post de ingeniería: agentes tempranos llegan a spawnear cincuenta subagentes para queries simples. Mi orquestador no llegaba a cincuenta, pero se inventaba subagentes para cosas que un workflow determinista habría resuelto sin tokens. Caso emblemático: el cálculo de coste, que no tiene ninguna ambigüedad — es aritmética sobre catálogo. Eso ya no pasa por LLM en absoluto.
Tercero, handoffs verbosos. Cuando el subagente buscador devolvía sus hallazgos al orquestador, le mandaba una transcripción larga del razonamiento, no solo la conclusión. El orquestador la metía entera en el contexto del siguiente subagente. Cada eslabón de la cadena arrastraba el peso de los anteriores.
La pregunta dejó de ser "¿el multi-agente compensa?" y pasó a ser "¿qué palancas tengo para mantener la calidad y bajar el coste un 60–70%?". Esa es la conversación interesante.
Las palancas
Las repaso ordenadas por impacto, con los números que vi en mi caso y los que circulan en la literatura. No son alternativas, se aplican en capas — y combinadas suelen llevar a recortes del 70–80% sobre la línea base sin tocar.
1. Routing en cascada
El cambio individual con más impacto. La regla es brutalmente simple: clasificación, extracción y formateo van a modelos baratos; razonamiento complejo y consolidación van a modelos top. La investigación lo cuantifica: una capa de routing que envía tareas fáciles a modelos baratos y duras a caros recorta costes del 40 al 60%; el spread entre modelos puede ser de hasta 190× para la misma tarea.
En mi caso, mover el extractor de requisitos a Haiku 4.5 — sin pérdida de calidad medible — recortó esa subtarea un 85%. La asignación final de la Iteración 3, después de la limpieza, es esta:
| Subagente | Modelo | Justificación |
|---|---|---|
Orchestrator | claude-opus-4-7 | Decisiones, planificación, consolidación |
DocParser | claude-sonnet-4-6 | Extracción estructurada con tablas y SLAs |
DocAnalyzer | claude-sonnet-4-6 | Resúmenes y entidades, soporta visión |
CloudSizer · CloudPublicoSizer · MSPSizer | claude-sonnet-4-6 | Razonamiento de dimensionamiento |
CatalogAgent | claude-haiku-4-5-20251001 | Lookup fuzzy + semántico, alto volumen |
OfferReviewer | claude-haiku-4-5-20251001 | Verificación dirigida, no creación |
DocGenerator · PPTGenerator | claude-sonnet-4-6 | Calidad de redacción sobre plantilla |
PricingEngine | Sin LLM | Aritmética determinista, no necesita modelo |
El último punto merece mención propia: la mejor optimización de tokens es no gastarlos. El cálculo de costes — sumar coste de catálogo, aplicar margen, recalcular fórmulas Excel — es Python puro. Al principio lo hacía un agente; pasarlo a código determinista no perdió un ápice de capacidad, ganó velocidad y bajó coste a cero. Aplica esta pregunta a cada agente que tengas: ¿realmente necesita razonar?
2. Prompt caching
La segunda palanca más potente, y la que más se infrautiliza. El prompt caching de Anthropic da un 90% de descuento sobre tokens de input cacheados. En multi-agente el efecto se amplifica porque cada subagente repite system prompt, descripción de tools y contexto base en cada llamada — esos tokens son ideales para caché.
Estructurar los prompts con los bloques estáticos al principio (system prompt, instrucciones, ejemplos) y los dinámicos al final (la query concreta) hace que el cache hit sea muy alto. En mi sistema esto solo recortó otro ~25% del coste total. La inversión: media tarde de reordenar prompts.
3. Handoffs estructurados
El antídoto al problema de los handoffs verbosos. La regla: los subagentes devuelven al orquestador JSON estructurado, no transcripciones. El razonamiento se queda en el contexto aislado del subagente y muere ahí; al orquestador solo llega el resultado. En mi caso esto se traduce en que cada tool del orquestador tiene un schema fijo y el merge de resultados es por hostname u otro identificador estable, sin reinyectar prosa.
El detalle técnico clave: cada subagente tiene su propio context window y devuelve un schema fijo. El orquestador nunca ve el cómo, solo el qué. Output tokens, recordemos, cuestan 4× a 8× más que input tokens — comprimir el output es donde más palanca hay.
4. Disciplina del orquestador
Los prompts del orquestador deben escalar el esfuerzo a la complejidad. Una instrucción explícita del tipo "para queries simples, usa un único subagente y como mucho dos herramientas; reserva paralelismo y subagentes especializados solo para tareas que claramente lo justifiquen" cambia el comportamiento de inflación.
En mi sistema, esto se tradujo en un prompt de orquestador con un budget explícito por propuesta — un máximo orientativo de subagentes y de iteraciones del reviewer. El reviewer ahora hace una o dos pasadas máximo. Si tras la segunda pasada sigue habiendo issues, escala a humano. Esa única regla mató el grueso del 59% de rework.
5. Output discipline y Chain of Draft
Más allá de structured output y max_tokens agresivo, hay un truco de prompting que casi nadie usa: Chain of Draft en lugar de Chain of Thought. El modelo borra cada paso del razonamiento en cinco palabras o menos en lugar de escribir párrafos enteros. Iguala accuracy con un 7–8% del coste de tokens de razonamiento. Para subagentes que necesitan pensar pero no necesitan justificarse, es un cambio de prompt de una línea con efecto desproporcionado.
6. Routing local + cloud
La palanca que más diferencia hace contra una arquitectura puramente cloud, y la que mejor se alinea con la dirección que sigue Econocom AI Fabric. En mis pruebas, la extracción de requisitos y la reformulación de queries para el RAG (que ya solo manejan trozos pequeños de texto y devuelven JSON) bajaron a un Gemma 4 31B local en vLLM. Coste marginal por token: cero. Latencia: igual o mejor que cloud, sin tránsito de red. Privacidad: el pliego no sale del perímetro hasta que el redactor técnico, en cloud, lo necesita para los bloques de respuesta.
Va exactamente en la línea de lo que describe la literatura sobre arquitecturas híbridas: usar modelos locales open-source para trabajo rutinario bien acotado, cloud frontier para razonamiento complejo y casos extremos. La parte técnica importante es tener una capa de gateway que abstraiga el origen — en mi caso LiteLLM — para que el subagente no sepa si su modelo está en localhost:11434 o en api.anthropic.com. Cambiar el motor es una línea de configuración.
7. Caché semántico para el RAG
Las preguntas que el redactor técnico hace al RAG ("propuestas anteriores con SLA crítico", "casos en banca de migración a cloud", "referencias de implantación de OpenShift en sector público") se repiten conceptualmente entre propuestas. Una caché semántica delante del retrieval — embedding de la pregunta, similitud sobre queries previas, devuelve resultados sin invocar al LLM — eliminó otro 15–20% de llamadas. Hay que ajustar bien el threshold de similitud para no cachear de más, pero la ganancia es sustancial.
RAG agéntico: agentes que construyen el RAG, no solo lo consumen
Esta es la sección que más me importa, y la que va más a contracorriente del discurso habitual.
El RAG, tal y como se enseña, es un sistema pasivo: indexas tus documentos, generas embeddings y los agentes consultan. La calidad del sistema entero depende de cómo se haya hecho la ingesta — chunking, metadatos, calidad del texto extraído. Y la ingesta, normalmente, es batch, manual y mediocre. PDFs mal OCR-eados, presentaciones con texto en imágenes, Excels con tablas dinámicas, propuestas antiguas en formatos heterogéneos. El RAG hereda toda esa miseria, y luego nos quejamos de que el agente alucina.
Mi propuesta es invertir el flujo. Convertir la ingesta en un proceso multi-agente especializado, donde la entrada de un documento dispara su propia mini-pipeline de razonamiento antes de tocar el índice.
La arquitectura objetivo tiene cuatro agentes encadenados:
- Analizador de documento. Detecta tipo (propuesta antigua, ficha de producto, caso de éxito, normativa interna, plantilla legal), extrae metadatos estructurales, decide qué tipo de procesamiento aplicar a continuación. Modelo barato; tarea bien acotada. En el sistema actual, esto lo hace ya el agente
DocAnalyzer(Sonnet) — producesummary,keypoints, entidades ypriority1–5 por documento, con soporte de visión para imágenes. - Extractor de contenido. Convierte el documento a texto limpio adaptado al tipo. Para PDFs con OCR pobre, llama a un OCR agéntico que vuelve a procesar con corrección. Para presentaciones, extrae texto y describe figuras. Para Excels, extrae tablas como markdown estructurado y describe el contenido. Para documentos largos, ejecuta chunking semántico, no por número de tokens. Hoy esto lo cubre
DocParser: detecta VMs, tablas, requisitos textuales y SLAs en pliegos PDF/DOCX/XLSX. - Enriquecedor semántico. Genera resúmenes por sección, etiquetas temáticas, entidades nombradas, fechas relevantes, sector del cliente, tipología de servicio, criticidad. Esto se persiste como metadatos del chunk en la base vectorial. Es el siguiente paso natural de la pipeline actual.
- Validador de calidad. Revisa muestras del output, detecta incoherencias o pérdidas de información respecto al original, marca el documento para reproceso si la calidad cae por debajo de un umbral. Cierra el loop antes de que la basura entre al índice.
El resultado es un RAG donde cada chunk no es un trozo bruto de texto — es una unidad rica en metadatos, validada y, lo más importante, describible. Cuando el redactor técnico pregunta "casos de migración cloud en banca con SLA 99,99%", el retrieval devuelve los tres chunks más relevantes filtrados por sector y criticidad, no quince ruidosos. Eso compensa con creces el coste extra de la ingesta.
Encaja además con la tendencia que veo en los sistemas serios de 2026: dejar de tratar el RAG como un sistema de búsqueda de documentos y empezar a tratarlo como una base de conocimiento estructurada que se construye con agentes. La ingesta deja de ser un job nocturno tonto y se convierte en una pequeña pipeline cognitiva propia, con sus propios criterios de calidad, sus reintentos y su trazabilidad.
Cuándo NO multi-agente
He defendido el multi-agente, pero conviene cerrar con la otra cara. Hay tareas en las que un único modelo bien instruido vence a cualquier orquestador. La regla práctica que aplico:
| Característica | Single-agent gana | Multi-agent compensa |
|---|---|---|
| Complejidad | Tarea acotada, una sola dimensión | Sub-dominios heterogéneos |
| Valor del output | Bajo o medio | Alto o muy alto |
| Tolerancia a coste | Sensible | Inversión justificada |
| Paralelismo útil | Lineal, dependencias fuertes | Exploración simultánea |
| Predictibilidad | Pasos previsibles | Decisiones en tiempo real |
Una clasificación de tickets no merece un orquestador. Una propuesta a un cliente estratégico, sí. La conversación no es ideológica — es de calculadora.
Y dentro del multi-agente, el principio que nunca falla: la mejor optimización de tokens es la que se evita gastar. Cada vez que añades un subagente, tienes que justificar por qué la calidad incremental que aporta supera el coste marginal. Si no la supera, lo que tienes no es un orquestador — es un experimento caro.
Reflexión final
El multi-agente no es ni la solución universal ni un experimento de laboratorio. Es una arquitectura más, con una ecuación de coste-beneficio muy concreta: paga 15× más tokens a cambio de un 90% más de capacidad en tareas heterogéneas y de alto valor. La pregunta interesante no es si usarla, sino cómo gastar esos tokens con disciplina quirúrgica.
Las tres iteraciones del sistema de RFP que he ido construyendo me han dejado un convencimiento: el orquestador no es el ganador por sí solo; el ganador es la arquitectura híbrida. Modelos pequeños y locales para tareas rutinarias y bien acotadas; modelos top en cloud para razonamiento; un RAG construido por agentes en lugar de poblado por scripts; caché agresivo en cada capa donde se pueda; un orquestador con presupuesto explícito; un pricing engine determinista que ni siquiera toca el LLM; y, sobre todo, la disciplina de no añadir un agente más solo porque sea posible.
En esa misma línea va la plataforma Econocom AI Fabric — pensada para que orquestar agentes, rutearlos entre cloud y on-prem, cachear sus salidas y observar su coste sea operación rutinaria, no un proyecto. Si la siguiente fase de la GenAI empresarial va de pasar de demos chulas a sistemas que aguantan una factura, la diferencia la van a marcar las plataformas que tratan el coste como un ciudadano de primera clase, no como una métrica que se mira al final del mes.
El multi-agente está aquí para quedarse. Solo hay que mantenerlo a raya.
Volver a artículos