Todo el mundo quiere un agente de IA corriendo. Poca gente entiende la anatomía. Sin esa claridad, el equipo arma un chatbot con un prompt grande, lo llama agente, y descubre en tres meses que el sistema responde rápido, inventa hechos, ignora datos nuevos y no ejecuta ninguna acción fuera de la conversación.
Este post abre el capó. Vas a entender qué es un agente de verdad, por qué necesita RAG (Retrieval-Augmented Generation), cómo un banco vectorial hace que la búsqueda semántica ocurra, y cómo todo se conecta en el flujo de ejecución. Sin misticismo, solo ingeniería.
Qué es un agente: el loop detrás del hype
Un agente no es un modelo. Un agente es un loop estructurado alrededor del modelo. El LLM razona y decide; el resto del sistema (memoria, herramientas, validación, control de flujo) ejecuta. Sin ese armazón, tienes un generador de texto bonito, no un agente.
El loop básico tiene cuatro fases: (1) percepción (recibe input del usuario o de otro sistema), (2) razonamiento (el LLM analiza el contexto, recupera memoria, elige la próxima acción), (3) ejecución (llama a una tool, consulta un banco, escribe en una API), (4) observación (lee el resultado y decide si continúa, termina o pide ayuda). El loop se repite hasta que la tarea se cierra o se acaba el budget.
Tres variaciones se sostienen en producción: el agente reactivo (un paso, decisión simple), el agente con plan (genera un plan, ejecuta por etapas, replanifica cuando algo falla) y el agente multiagente (varios roles especializados conversando entre sí, con un orquestador). Empieza por el reactivo. La mayoría de los casos reales se resuelven en el primer nivel y te enseñan lo que importa antes de que compliques las cosas.
RAG: por qué el agente necesita memoria externa
El LLM tiene conocimiento congelado en el entrenamiento. No sabe el nombre de tu cliente, el historial del ticket, el contenido del PDF que subiste ayer. Todo eso es dato externo. Para entrar en el razonamiento del agente, ese dato tiene que ser recuperado e inyectado en el prompt en tiempo de ejecución. Ese es el corazón del RAG.
RAG significa Retrieval-Augmented Generation. El agente no intenta recordar, busca. En cada turno, antes de razonar, el sistema consulta una base de conocimiento, trae los fragmentos relevantes y los agrega al contexto enviado al LLM. El modelo entonces genera la respuesta con fundamento, citando o referenciando la fuente, en vez de inventar.
RAG resuelve tres problemas que el prompt solo no resuelve. Actualización: indexas documentos nuevos en cualquier momento, sin reentrenar el modelo. Escala: el LLM no necesita haber visto tu corpus entero, solo necesita leer el fragmento relevante. Auditoría: la respuesta cita la fuente, así que un humano la valida y el equipo confía.
Vector database: cómo funciona la búsqueda semántica
El banco vectorial es la infraestructura que hace que el RAG escale. En vez de buscar por palabra clave (que ignora sinónimos y contexto), buscas por similitud semántica entre lo que el usuario pidió y lo que está indexado.
Funciona así. Cada pedazo de texto (chunk) se convierte en un vector numérico de alta dimensión (768, 1024 o 1536 dimensiones, dependiendo del modelo de embedding). Ese vector representa el significado del texto en un espacio matemático. Cuando el usuario pregunta algo, la pregunta también se vuelve vector, y el banco devuelve los k vectores más cercanos por distancia (coseno, euclidiana o producto interno).
Elecciones que importan: el modelo de embedding (OpenAI text-embedding-3-large, Cohere embed v4, BGE para self-hosted), el banco vectorial (Qdrant para self-hosted, Pinecone para managed, pgvector si ya tienes Postgres, Weaviate cuando necesitas filtro híbrido) y la estrategia de indexación (HNSW para velocidad, IVF para volumen gigante, exacto para datasets pequeños). No existe una elección universal, existe una elección justificada por requisitos de latencia, volumen y costo.
Pipeline de ingesta: del documento al chunk indexable
La ingesta es donde la mayoría de los agentes RAG mueren antes incluso de salir a producción. El dataset bruto rara vez es lo que entra al banco. Necesitas un pipeline con etapas claras.
(1) Parsing: extraer texto limpio de PDFs, planillas, HTML, transcripción de audio. Herramientas como Unstructured, LlamaParse y Docling hacen el trabajo pesado, pero siempre exigen revisión por tipo de documento. (2) Chunking: quebrar en pedazos de tamaño útil (300 a 800 tokens funciona para la mayoría de los casos), respetando fronteras semánticas (párrafo, sección, nunca cortes a mitad de la frase). (3) Enriquecimiento: agregar metadatos (fuente, fecha, autor, tags, ACL) que el agente pueda filtrar después. (4) Embedding: pasar cada chunk por el modelo elegido y almacenar el vector junto con el texto y los metadatos. (5) Indexación: guardar en el vector DB con el índice apropiado.
Un detalle que separa al amateur del profesional: reindexación continua. Los documentos cambian, los modelos de embedding evolucionan, la estrategia de chunking necesita ser revisada. Trata tu índice como código: versión, tests, rollback. Sin eso, quedas atrapado en la primera elección equivocada y lo descubres demasiado tarde.
Tool calling: lo que diferencia a un agente de un chatbot
Un chatbot habla. Un agente actúa. Tool calling es el mecanismo que le da manos al LLM: defines un conjunto de funciones (cada una con nombre, descripción y schema de entrada), el modelo elige cuál llamar y con qué argumentos, tu código la ejecuta de verdad, devuelve el resultado, y el ciclo continúa.
Tools comunes en un agente serio: search_knowledge_base (hace la recuperación RAG), query_database (consulta datos estructurados), call_external_api (integra con CRM, ERP, sistemas internos), execute_code (sandbox seguro para cálculo o transformación), write_action (crea un ticket, envía un email, agenda una reunión). Cada tool se valida por schema y tiene su propio retry, timeout y log.
Protocolos modernos como MCP (Model Context Protocol) estandarizan cómo el agente descubre y llama tools entre sistemas. Adoptar MCP temprano evita rehacer la integración para cada modelo nuevo y abre la puerta a usar tools de terceros sin reescribir el cliente.
Del prompt a la acción: el flujo end-to-end
Mira el camino completo de una pregunta real hasta la acción. Un usuario pregunta en el chat interno: ¿cuál es el margen del contrato 4421 en el último trimestre?. El agente lo recibe, lo pasa por el planner, e identifica que necesita dos datos: el contrato (estructurado, en el banco SQL) y la regla de cálculo de margen (no estructurada, en el manual de finanzas en PDF).
Tool 1: query_database(contract_id=4421, period=Q3) trae el valor bruto. Tool 2: search_knowledge_base(query="cálculo de margem para contratos do tipo X") hace el embedding de la pregunta, consulta el vector DB, devuelve los tres chunks más relevantes del manual. El LLM ahora tiene el dato bruto y la regla de cálculo en el contexto, hace el cálculo, formatea la respuesta con la fuente citada (página del manual, ID del contrato) y responde. Todo en segundos, con una auditoría del razonamiento grabada.
Ese es el patrón que escala: el agente decide cuándo usar RAG, cuándo usar consulta estructurada y cuándo solo responder directo. RAG no es la respuesta para todo, es una herramienta en el cinturón.
Errores que matan agentes RAG en producción
Chunks demasiado grandes: el fragmento irrelevante contamina el contexto y el modelo se confunde. Chunks demasiado pequeños: pierde contexto, recupera un fragmento sin sentido. Un embedding único para todo: los dominios jurídico, técnico y conversacional piden modelos diferentes (o fine-tuning de embedding). Sin reranker: la primera recuperación rara vez es óptima, un reranker (Cohere Rerank, BGE-reranker) eleva mucho la precisión. Sin feedback loop: no sabes cuándo el agente se equivocó si no registras la query, el contexto recuperado, la respuesta generada y una muestra de juicio humano.
Y el más común: falta de evaluación. Un agente sin golden set, sin métrica de retrieval (recall@k, MRR, NDCG), sin test de regresión, se vuelve una apuesta. Empujas un prompt nuevo a ciegas, rompes algo, lo descubres cuando el cliente reclama. La evaluación no es opcional, es lo que separa un agente que escala de una demo bonita que muere en el segundo mes.
El agente es arquitectura, no modelo
El LLM se volvió un commodity. Cuesta centavos por millón de tokens y mejora en cada release. Lo que diferencia a un agente que funciona de uno que falla no es el modelo elegido, es la arquitectura a su alrededor: un pipeline de ingesta sólido, un vector DB bien configurado, tools con schema disciplinado, observabilidad desde el día cero y feedback continuo.
Construir un agente es ingeniería de sistemas distribuidos con una pieza nueva en el medio. Trátalo como ingeniería, no como prompt engineering con cara nueva, y tu agente va a durar.