Agentic RAG: Cómo los agentes de IA que buscan, razonan y actúan están reemplazando los pipelines de retrieval tradicionales

Construiste un pipeline RAG. Chunkeaste tus documentos, los embebiste en una base vectorial y armaste un paso de retrieval antes de tu llamada al LLM. Para preguntas simples funciona bien. Hasta que un usuario pregunta algo como:

"Compará los modelos de precios del plan enterprise y el starter, y decime cuál tuvo mejor retención el trimestre pasado según los datos del dashboard de analytics."

Tu pipeline RAG trae un par de chunks vagamente relacionados con precios. De retención no sabe nada, porque esos datos viven en una fuente completamente distinta. El LLM fabrica una respuesta que suena segura, y tu usuario toma una mala decisión de negocio.

Este escenario se repite miles de veces al día en sistemas de IA en producción. Y expone la limitación fundamental del RAG tradicional: es una búsqueda de un solo paso en un mundo que necesita razonamiento multi-paso.

Ahí entra Agentic RAG — el patrón arquitectónico donde tu IA no solo busca y genera. Planifica, busca iterativamente, evalúa lo que encontró, decide que necesita más información, consulta fuentes distintas, y sintetiza una respuesta final solo cuando tiene evidencia suficiente. Es la diferencia entre un motor de búsqueda y un analista de investigación.

En esta guía vamos a fondo. Cubrimos por qué RAG tradicional se rompe, cómo funciona Agentic RAG por dentro, patrones de arquitectura listos para producción con código, y los trade-offs reales que tenés que entender antes de adoptarlo.

Por qué RAG tradicional se queda corto

Arranquemos definiendo exactamente qué es "RAG tradicional" y dónde falla de forma sistemática.

El pipeline RAG estándar

Query del usuario → Embeber query → Búsqueda vectorial → Top-K chunks → LLM + contexto → Respuesta

Es un pipeline single-pass, buscar-y-generar. El retrieval corre una vez, agarra los K chunks más similares, los mete en la ventana de contexto del LLM y cruza los dedos. Funciona notablemente bien para:

• Consultas factuales simples ("¿Cuál es nuestra política de reembolso?")
• Preguntas donde la respuesta vive en una sección contigua de un documento
• Casos donde el corpus documental es pequeño y bien estructurado

Pero falla sistemáticamente en estas categorías:

Falla 1: Preguntas multi-hop

"¿Qué equipo de ingeniería tuvo la mayor mejora en velocidad después de adoptar el nuevo pipeline CI/CD, y qué cambios específicos hicieron?"

Esto requiere: (1) encontrar datos de velocidad por equipo, (2) identificar qué equipos adoptaron el nuevo pipeline, (3) correlacionar esos dos datasets, y (4) encontrar detalles de implementación del equipo ganador. Una búsqueda vectorial devuelve chunks dispersos de distintos documentos, y el LLM no tiene el panorama completo.

Falla 2: Análisis comparativo

"¿Cómo difiere nuestro approach de auth entre la API móvil y la web? ¿Hay brechas de seguridad?"

Requiere buscar documentación de dos sistemas separados, entender ambos en contexto completo y hacer un análisis comparativo. Una sola llamada de retrieval mezcla chunks de ambos sin distinguir.

Falla 3: Queries que necesitan cómputo

"¿Cuál fue nuestro tiempo de respuesta promedio para el endpoint de pagos la semana pasada, y cómo se compara con el SLA?"

Esto requiere consultar una base de métricas (no un document store), hacer aritmética, y comparar contra un valor almacenado en otra fuente. RAG tradicional ni siquiera puede hacer las llamadas API necesarias.

Falla 4: Queries ambiguas que necesitan clarificación

"Contame sobre la migración."

¿Qué migración? ¿De base de datos? ¿De cloud? ¿De React 18 a 19? RAG tradicional trae los chunks con mayor score para "migración" y espera lo mejor. Un sistema inteligente pediría aclaración — o al menos buscaría en múltiples contextos posibles.

El problema de fondo

RAG tradicional trata el retrieval como un paso de preprocesamiento de caja negra. El LLM no controla qué se busca, cuántas veces se busca, ni en qué fuentes. Consume pasivamente lo que le dan.

Agentic RAG invierte esto por completo: el LLM se convierte en el orquestador de su propia recolección de información.

Qué es Agentic RAG exactamente

Agentic RAG no es una librería ni un producto. Es un patrón de arquitectura donde un agente LLM tiene control autónomo sobre el proceso de retrieval:

Query del usuario
    ↓
Agente (LLM con herramientas)
    ├── Analizar complejidad de la query
    ├── Planificar estrategia de retrieval
    ├── Herramienta: Búsqueda vectorial (documentos)
    ├── Herramienta: SQL Query (datos estructurados)
    ├── Herramienta: API Call (datos en tiempo real)
    ├── Herramienta: Búsqueda web (conocimiento externo)
    ├── Evaluar: "¿Tengo suficiente para responder?"
    │     ├── No → Refinar query, buscar de nuevo
    │     └── Sí → Sintetizar respuesta
    └── Respuesta final (con citas)

Las diferencias clave con RAG tradicional:

El loop del agente

El corazón de Agentic RAG sigue un patrón ReAct (Reason + Act):

1. Razonar: El agente analiza la query y decide qué información necesita
2. Actuar: Llama a una herramienta (búsqueda, query, API) para obtenerla
3. Observar: Examina los resultados
4. Razonar de nuevo: Decide si tiene suficiente o necesita buscar otra vez
5. Repetir hasta tener evidencia suficiente para sintetizar

Este loop es lo que le da a Agentic RAG su poder — y su complejidad. Veamos cómo construirlo.

Construyendo Agentic RAG: Patrones de arquitectura

Hay tres patrones dominantes, cada uno con trade-offs distintos.

Patrón 1: Agente Router (El más simple)

En vez de siempre pegarle a la base vectorial, un LLM decide qué fuente de retrieval consultar según la pregunta.

import { ChatOpenAI } from '@langchain/openai';
import { tool } from '@langchain/core/tools';
import { createReactAgent } from '@langchain/langgraph/prebuilt';
import { z } from 'zod';

const searchDocs = tool(
  async ({ query }) => {
    const results = await vectorStore.similaritySearch(query, 5);
    return results.map(r => r.pageContent).join('\n\n');
  },
  {
    name: 'search_documentation',
    description: 'Buscar en documentación interna y artículos de knowledge base.',
    schema: z.object({ query: z.string() }),
  }
);

const queryMetrics = tool(
  async ({ sql }) => {
    const result = await metricsDb.query(sql);
    return JSON.stringify(result.rows);
  },
  {
    name: 'query_metrics',
    description: 'Ejecutar queries SQL contra la base de métricas.',
    schema: z.object({ sql: z.string() }),
  }
);

const searchTickets = tool(
  async ({ query, status }) => {
    const tickets = await jiraClient.search(
      `text ~ "${query}" AND status = "${status}"`
    );
    return JSON.stringify(tickets.issues.map(i => ({
      key: i.key, summary: i.fields.summary, status: i.fields.status.name,
    })));
  },
  {
    name: 'search_tickets',
    description: 'Buscar tickets en Jira.',
    schema: z.object({
      query: z.string(),
      status: z.enum(['Open', 'In Progress', 'Done', 'All']).default('All'),
    }),
  }
);

const agent = createReactAgent({
  llm: new ChatOpenAI({ model: 'gpt-4o', temperature: 0 }),
  tools: [searchDocs, queryMetrics, searchTickets],
});

El Router maneja bien las fallas 2 y 3, pero solo hace un retrieval por fuente. Para preguntas multi-hop, necesitás algo más potente.

Patrón 2: Agente de retrieval iterativo (El más común)

El workhorse de producción. El agente busca información, la evalúa, y decide si buscar de nuevo con una query refinada.

import { StateGraph, Annotation } from '@langchain/langgraph';
import { ChatOpenAI } from '@langchain/openai';

const AgentState = Annotation.Root({
  question: Annotation<string>,
  retrievedDocs: Annotation<string[]>({
    reducer: (a, b) => [...a, ...b], default: () => []
  }),
  searchQueries: Annotation<string[]>({
    reducer: (a, b) => [...a, ...b], default: () => []
  }),
  evaluation: Annotation<string>,
  finalAnswer: Annotation<string>,
  iterations: Annotation<number>({
    reducer: (_, b) => b, default: () => 0
  }),
});

const llm = new ChatOpenAI({ model: 'gpt-4o', temperature: 0 });

async function planRetrieval(state: typeof AgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Analizá esta pregunta y generá 1-3 queries de búsqueda específicas.
      Considerá la información ya recuperada.
      Devolvé JSON: { "queries": [...], "reasoning": "..." }`,
    },
    {
      role: 'user',
      content: `Pregunta: ${state.question}\n\nYa recuperado:\n${state.retrievedDocs.join('\n---\n') || 'Nada aún'}`,
    },
  ]);

  const plan = JSON.parse(response.content as string);
  return { searchQueries: plan.queries };
}

async function retrieve(state: typeof AgentState.State) {
  const newDocs: string[] = [];
  for (const query of state.searchQueries.slice(-3)) {
    const results = await vectorStore.similaritySearch(query, 3);
    newDocs.push(...results.map(r =>
      `[Fuente: ${r.metadata.source}]\n${r.pageContent}`
    ));
  }
  return { retrievedDocs: newDocs, iterations: state.iterations + 1 };
}

async function evaluate(state: typeof AgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Evaluá si la información recuperada es suficiente para responder
      la pregunta de forma completa y precisa.
      Devolvé JSON: { "sufficient": true/false, "missing": "qué falta", "confidence": 0-100 }`,
    },
    {
      role: 'user',
      content: `Pregunta: ${state.question}\n\nInformación:\n${state.retrievedDocs.join('\n---\n')}`,
    },
  ]);
  return { evaluation: response.content as string };
}

async function synthesize(state: typeof AgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Respondé la pregunta basándote SOLO en la información recuperada.
      Citá fuentes para cada afirmación.`,
    },
    {
      role: 'user',
      content: `Pregunta: ${state.question}\n\nEvidencia:\n${state.retrievedDocs.join('\n---\n')}`,
    },
  ]);
  return { finalAnswer: response.content as string };
}

function shouldContinue(state: typeof AgentState.State) {
  if (state.iterations >= 5) return 'synthesize';
  try {
    const eval_ = JSON.parse(state.evaluation);
    if (eval_.sufficient && eval_.confidence >= 70) return 'synthesize';
    return 'plan';
  } catch { return 'synthesize'; }
}

const graph = new StateGraph(AgentState)
  .addNode('plan', planRetrieval)
  .addNode('retrieve', retrieve)
  .addNode('evaluate', evaluate)
  .addNode('synthesize', synthesize)
  .addEdge('__start__', 'plan')
  .addEdge('plan', 'retrieve')
  .addEdge('retrieve', 'evaluate')
  .addConditionalEdges('evaluate', shouldContinue, {
    plan: 'plan', synthesize: 'synthesize',
  })
  .addEdge('synthesize', '__end__')
  .compile();

Este patrón es potente porque el agente descompone preguntas complejas, evalúa calidad del retrieval, itera cuando falta información y limita las iteraciones para evitar costos descontrolados.

Patrón 3: RAG multi-agente (El más potente)

Para los casos más complejos, múltiples agentes especializados colaboran en paralelo:

import { StateGraph, Annotation } from '@langchain/langgraph';

const MultiAgentState = Annotation.Root({
  question: Annotation<string>,
  subQuestions: Annotation<string[]>,
  agentResults: Annotation<Record<string, string>>({
    reducer: (a, b) => ({ ...a, ...b }), default: () => ({}),
  }),
  finalAnswer: Annotation<string>,
});

async function decompose(state: typeof MultiAgentState.State) {
  const response = await llm.invoke([
    {
      role: 'system',
      content: `Descomponé esta pregunta compleja en 2-4 sub-preguntas
      independientes que se puedan investigar en paralelo.
      Devolvé JSON: { "subQuestions": [...] }`,
    },
    { role: 'user', content: state.question },
  ]);
  const { subQuestions } = JSON.parse(response.content as string);
  return { subQuestions };
}

async function researchDocs(state: typeof MultiAgentState.State) {
  const results: Record<string, string> = {};
  for (const q of state.subQuestions) {
    const docs = await vectorStore.similaritySearch(q, 5);
    results[`docs_${q.slice(0, 30)}`] = docs.map(d => d.pageContent).join('\n');
  }
  return { agentResults: results };
}

async function researchMetrics(state: typeof MultiAgentState.State) {
  const results: Record<string, string> = {};
  // ... lógica de retrieval de métricas
  return { agentResults: results };
}

async function synthesizeMulti(state: typeof MultiAgentState.State) {
  const allEvidence = Object.entries(state.agentResults)
    .map(([key, val]) => `### ${key}\n${val}`).join('\n\n');

  const response = await llm.invoke([
    {
      role: 'system',
      content: `Sintetizá una respuesta comprehensiva con los hallazgos
      de múltiples agentes de investigación. Citá fuentes.`,
    },
    {
      role: 'user',
      content: `Pregunta original: ${state.question}\n\nHallazgos:\n${allEvidence}`,
    },
  ]);
  return { finalAnswer: response.content as string };
}

const multiAgentGraph = new StateGraph(MultiAgentState)
  .addNode('decompose', decompose)
  .addNode('research_docs', researchDocs)
  .addNode('research_metrics', researchMetrics)
  .addNode('synthesize', synthesizeMulti)
  .addEdge('__start__', 'decompose')
  .addEdge('decompose', 'research_docs')
  .addEdge('decompose', 'research_metrics')
  .addEdge('research_docs', 'synthesize')
  .addEdge('research_metrics', 'synthesize')
  .addEdge('synthesize', '__end__')
  .compile();

Desafíos en producción: Las partes difíciles

Armar un demo de Agentic RAG lleva un día. Hacerlo production-ready lleva meses. Los desafíos reales:

1. Presupuesto de latencia

Cada iteración suma latencia. RAG tradicional tarda 1-2 segundos. Agentic RAG con 3 iteraciones tarda 5-10. Multi-agente: 10-20 segundos.

Estrategias de mitigación:

// 1. Streaming — mostrá progreso al usuario
const stream = await graph.stream(
  { question: userQuery },
  { streamMode: 'updates' },
);

for await (const update of stream) {
  const [nodeName] = Object.entries(update)[0];
  sendToClient({
    type: 'progress',
    step: nodeName,
    detail: nodeName === 'retrieve'
      ? 'Buscando información...'
      : nodeName === 'evaluate'
      ? 'Evaluando resultados...'
      : 'Sintetizando respuesta...',
  });
}

// 2. Clasificación de queries — rutear las simples a RAG tradicional
const complexity = await classifyComplexity(userQuery);
if (complexity === 'simple') {
  return traditionalRag(userQuery);  // ~1-2s
} else {
  return agenticRag(userQuery);  // ~5-15s, pero mucho más preciso
}

2. Control de costos

Cada iteración quema tokens. Una query Agentic RAG de 3 iteraciones puede usar 10-15x más tokens que RAG simple.

// Tracking de presupuesto de tokens
const MAX_INPUT_TOKENS = 50_000;
const MAX_OUTPUT_TOKENS = 10_000;
let totalInputTokens = 0;

async function trackedLlmCall(messages: Message[]) {
  const tokenEstimate = messages.reduce(
    (sum, m) => sum + (typeof m.content === 'string'
      ? m.content.length / 4 : 0),
    0
  );

  if (totalInputTokens + tokenEstimate > MAX_INPUT_TOKENS) {
    // Forzar síntesis con lo que tengamos
    return { action: 'force_synthesize' };
  }

  const response = await llm.invoke(messages);
  totalInputTokens += response.usage?.input_tokens || 0;
  return response;
}

// Deduplicación inteligente para reducir tamaño de contexto
function deduplicateChunks(docs: Document[]): Document[] {
  const seen = new Set<string>();
  return docs.filter(doc => {
    // Hash de contenido para detectar cuasi-duplicados
    const hash = simpleHash(doc.pageContent.slice(0, 200));
    if (seen.has(hash)) return false;
    seen.add(hash);
    return true;
  });
}

3. Evaluación: ¿cómo sabés que funciona?

La parte más difícil. ¿Cómo se evalúa un sistema Agentic RAG?

// Framework de evaluación para Agentic RAG
interface AgentEvalMetrics {
  // Calidad de retrieval
  retrievalPrecision: number;   // % de docs recuperados que eran relevantes
  retrievalRecall: number;      // % de docs relevantes que se recuperaron

  // Comportamiento del agente
  avgIterations: number;        // Loops promedio hasta responder
  unnecessaryIterations: number; // Loops que no aportaron info
  toolSelectionAccuracy: number; // ¿Eligió la herramienta correcta?

  // Calidad de respuesta
  answerCorrectness: number;    // Precisión factual vs ground truth
  answerCompleteness: number;   // ¿Respondió todas las partes?
  citationAccuracy: number;     // ¿Las citas son correctas?

  // Eficiencia de costo
  totalTokensUsed: number;
  latencyMs: number;
  costPerQuery: number;
}

// Golden dataset con comportamientos esperados
const evalDataset = [
  {
    query: 'Compará retención del plan enterprise y startup del último trimestre',
    expectedTools: ['search_documentation', 'query_metrics'],
    expectedMinIterations: 2,
    expectedSources: ['pricing-docs', 'analytics-dashboard'],
    groundTruth: 'Enterprise: 94.2% retención, Startup: 87.1% retención...',
  },
  // ... más casos de prueba
];

// Ejecutar evaluación
async function evaluateAgent(dataset: EvalCase[]) {
  const results: AgentEvalMetrics[] = [];

  for (const testCase of dataset) {
    const trace = await agentGraph.invoke(
      { question: testCase.query },
      { configurable: { tracing: true } },
    );

    results.push({
      retrievalPrecision: calculatePrecision(
        trace.retrievedDocs, testCase.expectedSources
      ),
      toolSelectionAccuracy: calculateToolAccuracy(
        trace.toolCalls, testCase.expectedTools
      ),
      answerCorrectness: await llmJudge(
        trace.finalAnswer, testCase.groundTruth
      ),
      avgIterations: trace.iterations,
      totalTokensUsed: trace.tokenUsage.total,
      latencyMs: trace.durationMs,
      costPerQuery: calculateCost(trace.tokenUsage),
      // ...
    });
  }

  return aggregateMetrics(results);
}

4. Guardrails de seguridad

Los sistemas agénticos se pueden descarrilar. Un agente con acceso a SQL podría, en teoría, hacer DROP TABLE. Necesitás múltiples capas de defensa:

// 1. Validación a nivel de herramienta
const querySql = tool(
  async ({ sql }) => {
    // Validar SQL antes de ejecutar
    const forbidden = ['DROP', 'DELETE', 'UPDATE', 'INSERT', 'ALTER', 'TRUNCATE'];
    const upperSql = sql.toUpperCase();

    for (const kw of forbidden) {
      if (upperSql.includes(kw)) {
        return `Error: ${kw} no permitido. Solo soporta SELECT.`;
      }
    }

    // Agregar timeout y límite de filas
    const safeSql = `${sql} LIMIT 1000`;
    const result = await db.query(safeSql, { timeout: 5000 });
    return JSON.stringify(result.rows);
  },
  {
    name: 'query_database',
    description: 'Queries SQL de solo lectura. Solo SELECT permitido.',
    schema: z.object({ sql: z.string() }),
  }
);

// 2. Límites de iteración (ya mostrado arriba)

// 3. Validación de output — detección de alucinaciones
async function validateResponse(
  response: string,
  context: string
): Promise<{ isGrounded: boolean; hallucinations: string[] }> {
  const validation = await llm.invoke([
    {
      role: 'system',
      content: `Verificá si cada afirmación factual en la respuesta está respaldada
      por el contexto. Listá afirmaciones NO respaldadas (alucinaciones).
      Devolvé JSON: { "isGrounded": boolean, "hallucinations": [...] }`,
    },
    {
      role: 'user',
      content: `Respuesta: ${response}\n\nContexto: ${context}`,
    },
  ]);

  return JSON.parse(validation.content as string);
}

5. Observabilidad

No se puede debuggear un sistema agéntico sin trazabilidad completa. Cada decisión del agente tiene que ser rastreable.

// Logging estructurado para cada paso del agente
interface AgentTrace {
  traceId: string;
  question: string;
  steps: {
    node: string;
    input: Record<string, unknown>;
    output: Record<string, unknown>;
    llmCalls: {
      model: string;
      inputTokens: number;
      outputTokens: number;
      latencyMs: number;
    }[];
    toolCalls: {
      tool: string;
      input: Record<string, unknown>;
      output: string;
      latencyMs: number;
    }[];
    durationMs: number;
  }[];
  totalDurationMs: number;
  totalTokens: number;
  finalAnswer: string;
}

// Integración con LangSmith, Langfuse o tracing custom
import { Client } from 'langsmith';

const langsmith = new Client();

const tracedGraph = graph.withConfig({
  callbacks: [langsmith.getTracer()],
  runName: 'agentic-rag',
  metadata: {
    userId: currentUser.id,
    sessionId: session.id,
    queryComplexity: complexity,
  },
});

Benchmarks reales: Agentic RAG vs RAG tradicional

Benchmarkeamos tres arquitecturas contra 200 preguntas reales de distintas complejidades:

Los números hablan claro:

• Queries simples: Los tres rinden similar. Agentic RAG es overkill.
• Queries complejas: Agentic RAG gana por goleada, especialmente multi-hop y comparativas.
• Costo: 10x más caro por query. Ruteá las simples a RAG tradicional.
• Alucinaciones: El loop de auto-evaluación atrapa más errores.

Cuándo NO usar Agentic RAG

No lo uses cuando:

• La mayoría de las queries son lookups simples → RAG tradicional es más rápido y barato
• El requisito de latencia es <2 segundos → el agent loop es muy lento
• El presupuesto es ajustado → los costos de tokens escalan rápido
• Los datos viven en una sola fuente bien estructurada → RAG tradicional alcanza
• No podés invertir en infraestructura de evaluación → no vas a saber si funciona

Usalo cuando:

• Los usuarios hacen preguntas complejas multi-parte habitualmente
• Necesitás consultar múltiples fuentes para una respuesta
• La precisión importa más que la velocidad (Q&A enterprise, legal, médico)
• La respuesta requiere cómputo o llamadas API
• La precisión de tu RAG se estancó y necesitás un salto

Ecosistema de frameworks en 2026

LangGraph (LangChain): La opción más madura para grafos de agentes. TypeScript y Python SDKs son production-ready.

LlamaIndex Workflows: Sistema basado en eventos asincrónicos, una abstracción diferente del grafo de estados.

Semantic Kernel (Microsoft): Para el ecosistema .NET, con integración nativa con Azure AI Search.

Implementaciones custom: Muchos equipos arman loops de agentes custom sin frameworks, con control total a costa de reinventar patrones comunes.

Conclusión: El cambio de paradigma

RAG tradicional fue revolucionario — le dio a los LLMs acceso a datos privados sin fine-tuning. Pero su arquitectura single-pass tiene un límite fundamental. Las preguntas complejas necesitan un approach que pueda planificar, iterar y razonar entre múltiples fuentes.

Agentic RAG no es una mejora incremental. Es un cambio de paradigma de "buscar y rezar" a "investigar y verificar." La mejora de precisión en queries complejas (34% → 78%) no es marginal — es la diferencia entre un sistema útil y uno peligroso.

Pero adoptalo con criterio:

1. Empezá con clasificación de queries. Ruteá las simples a RAG tradicional (rápido, barato) y las complejas a Agentic RAG (preciso, caro). La mayoría de los sistemas en producción usan ambos.

2. Construí evaluación primero. Si no lo podés medir, no lo podés mejorar. Creá un golden dataset antes de escribir código de agentes.

3. Instrumentá todo. Cada decisión del agente, cada retrieval, cada evaluación tiene que ser trazable.

4. Poné límites duros. Máximo de iteraciones, tokens y latencia. Un sistema agéntico sin guardrails es un sistema caro e impredecible.

5. Invertí en tus herramientas. La calidad del agente depende directamente de la calidad de sus tools. Un agente con razonamiento perfecto no compensa una base vectorial mal configurada.

El futuro del retrieval no son mejores embeddings ni ventanas de contexto más grandes. Es darle a la IA el mismo workflow de investigación que usan los expertos humanos: entender la pregunta, planificar la búsqueda, recolectar evidencia de múltiples fuentes, evaluar lo encontrado y sintetizar solo cuando hay confianza.

Eso es Agentic RAG. Y es la arquitectura que va a dominar los sistemas de IA en producción en 2026 y después.