Multi-agente vs. RAG: cuándo gana cada uno.

La mitad de los equipos de ingeniería con los que hablo en 2026 hacen la misma pregunta: '¿deberíamos construir un RAG o un sistema multi-agente?' Es la pregunta equivocada. RAG es un patrón de retrieval — cómo le das contexto fresco al modelo. Multi-agente es un patrón de orquestación — cómo cooperan varios modelos especializados. Son ortogonales. Puedes construir un RAG dentro de un único agente. Puedes correr multi-agente con cero retrieval. La mayoría de la IA en producción hace ambas.

Pero la pregunta persiste porque los equipos eligen una como su arquitectura primaria, y esa elección sí importa. Elige mal, y pasarás el año siguiente reescribiendo. Este post es el árbol de decisión que usamos en GOGOGO LLC en Goddo, GoPeople, GoVista y GoTrack — más los modos de falla que, en retrospectiva, te dicen que elegiste mal.

Qué es realmente cada uno

RAG (retrieval-augmented generation): el modelo recibe una pregunta, embebes la pregunta, encuentras los K trozos más similares en tu vector store, los metes en el prompt, el modelo responde. Un modelo, una ronda. Mayor context window o mejor embedding = mejor RAG. El modelo hace el trabajo; el retrieval es combustible.

Multi-agente: descompones una tarea en roles especialistas (planner, executor, critic, retriever, validator) y les dejas pasarse payloads tipados entre sí. La salida de un agente es la entrada del siguiente. El orchestrator es pequeño y con forma de regla; los especialistas son generativos. Varios modelos, varias rondas. La estructura hace el trabajo; la generación es el último paso.

Cuándo gana RAG

1. Q&A de un solo turno sobre un corpus definido. Un bot de ayuda para tus docs de producto. Un asistente legal sobre tus contratos. El usuario hace una pregunta, el modelo da una respuesta, el corpus está acotado.
2. Presupuesto de latencia por debajo de 1 segundo. RAG es una llamada al modelo (más una búsqueda vectorial). Multi-agente es como mínimo tres (plan + execute + critic). Para responsividad tipo chat frente a usuarios, las matemáticas del round-trip fuerzan RAG.
3. La salida es un párrafo, no un workflow. Si la respuesta correcta es texto, no una secuencia de acciones con side-effects (mandar email, agendar job, escribir a una base), RAG lo cubre limpiamente.
4. El coste por consulta tiene que ser sub-céntimo. RAG ≈ una llamada al modelo. Multi-agente ≈ N llamadas. A escala esto domina la factura.

Si la respuesta a las cuatro es sí, construye RAG. Multi-agente es over-engineering y se sentirá más lento sin darles a los usuarios nada que noten.

Cuándo gana multi-agente

1. La tarea es un proceso, no una pregunta. "Compone, clasifica y enruta este mensaje entrante de cliente a través de RR. HH., nómina e IT" no es el trabajo de un solo modelo. Es el trabajo de GoPeople, y la descomposición es el producto.
2. Distintas partes de la tarea necesitan modelos distintos. Visión para la imagen, retrieval para el catálogo, clasificación para la intención, generación para la respuesta. RAG aplana todo en un prompt; multi-agente deja a cada modelo ser el mejor en su trabajo.
3. El estado sobrevive a una sola llamada. Workflows multi-turno donde 'qué pasó en el paso 3' importa en el paso 7. RAG olvida entre llamadas a menos que reconstruyas contexto; multi-agente trata el grafo de conversación como ciudadano de primera.
4. Necesitas replay. Debugging en producción requiere poder re-ejecutar una tarea fallida con las mismas entradas. Las trazas multi-agente te lo dan nativamente; las trazas RAG sólo te dan el par chunks-recuperados-más-respuesta, que no captura por qué el modelo respondió como respondió.

Si dos de estos son ciertos, construye multi-agente. El coste de la orquestación extra vale la pena en el momento en que tengas que debuggear algo.

La tabla comparativa honesta

// Misma tarea — detección de pickup en una tienda — ambas formas.

// Enfoque RAG (un modelo, retrieval contextual)
const candidates = await vectorStore.search(frame.embedding, k=20);
const answer = await llm.complete({
  system: "Identificas productos retail desde imágenes y un catálogo.",
  context: candidates.map(c => c.metadata),
  question: `¿Qué se llevó el cliente del rack ${rack.id}?`,
});
// → respuesta string. Rápida. Sin estado. Sin replay.

// Enfoque multi-agente (especialistas se traspasan)
const ranked = await retrievalAgent.rank(frame);
const scored = await rerankAgent.score(ranked, ctx);
const decision = await validationAgent.confirm(scored, history);
const action = await signageAgent.swap(decision);
// → acción tipada, traza completa de input/output/decisión de cada
//    paso, reproducible, debuggeable, observable.

Ambos funcionan. La versión RAG se lanza en un fin de semana. La versión multi-agente tarda un mes. La versión RAG deja de escalar en el primer bug de producción que no puedas reproducir. La versión multi-agente se construyó alrededor de poder reproducirlo. La decisión es si la reproducibilidad importa más que el tiempo-al-primer-demo.

Tres modos de falla que, en retrospectiva, te dicen que elegiste mal

Modo 1: Hiciste RAG y tu equipo de soporte sigue preguntando '¿por qué respondió eso?'

Si no puedes mostrarle a un ingeniero de soporte qué chunks recuperados llevaron a qué frase de la respuesta, tu RAG es indebuggeable y en meses te encontrarás atornillándole scaffolding con forma de agente. En ese punto, reescríbelo como multi-agente directamente. Lo hicimos con la primera versión de GoPeople.

Modo 2: Hiciste multi-agente y el demo es 4× más lento que tu competidor RAG

La fortaleza de multi-agente es debuggeabilidad; su debilidad son los round-trips. Si tu tarea genuinamente es de un turno y la envolviste en 3 llamadas de agente porque 'se sentía más correcto', gastaste tu presupuesto de latencia en orquestación que no necesitabas. Colápsalo de vuelta a un solo agente con retrieval fuerte.

Modo 3: Elegiste RAG y ahora no puedes representar el 'por qué' de una decisión

Banca, salud, compliance — cualquier dominio donde debas defender por qué un sistema hizo lo que hizo. RAG te da la respuesta; multi-agente te da el camino a la respuesta. Si un regulador va a preguntar, necesitas multi-agente.

Cómo usamos ambos en GOGOGO

Dentro de cada sistema multi-agente, el agente de retrieval hace RAG. El agente de retrieval es un especialista entre muchos; su trabajo es traer contexto fresco y pasárselo al siguiente agente. Así que nuestro GoTrack reranker es RAG (vector search + cross-encoder), pero vive dentro de un runtime multi-agente que también tiene agentes de visión, scoring, validación y signage.

Multi-agente no es lo opuesto de RAG. Multi-agente es el contenedor dentro del cual RAG corre cuando retrieval es una de varias cosas que tu sistema debe hacer. Si retrieval es lo único — RAG solo. Si retrieval es uno de muchos — multi-agente, con RAG como un especialista.

Árbol de decisión, condensado

• Un solo turno, limitado por latencia, salida de texto, coste sub-céntimo → RAG.
• Proceso multi-paso, varios tipos de modelo, con estado, necesita replay → Multi-agente.
• Indeciso → arranca con RAG dentro de un cascarón multi-agente. El cascarón es barato; reescribir después no.

“RAG es combustible. Multi-agente es el motor. La pregunta no es 'cuál' — es 'cuándo el combustible solo es la respuesta, y cuándo necesitas un motor para quemarlo dentro'.”

Hemos construido ambos en GOGOGO LLC y los dos siguen en la caja de herramientas. Si quieres comparar notas sobre una decisión concreta de tu stack — Atakan, o ezagor si quieres el handle dev.