RAG (retrieval-augmented generation) se ha convertido en el default: mete documentos en un vector store y pregunta. Sirve. También engaña.
Documentos ≠ operación
Un manual de procedimientos describe la norma. La memoria operativa es lo que el equipo hace de verdad: excepciones, clientes especiales, estados del ticket, “esto no se toca los viernes”. Esa memoria vive en ERP, CRM, chats y cabezas — no en el PDF de onboarding.
Si tu agente solo lee la wiki, responderá como un becario el primer día.
Qué aporta RAG (y qué no)
Aporta: contexto textual, políticas, FAQs, snippets de código o contratos.
No aporta solo: estado actual del pedido, permisos del usuario, historial de incidencias, ni la decisión de ayer del supervisor.
Para eso necesitas herramientas y estado: APIs, consultas, y a veces un almacén de hechos vivos — no solo embeddings.
Un modelo mental útil
| Capa | Pregunta que responde |
|---|---|
| RAG / KB | “¿Qué dice la documentación?” |
| Estado / tools | “¿Qué está pasando ahora?” |
| Memoria de episodio | “¿Qué hicimos en este caso?” |
| Política | “¿Se puede hacer?” |
Los agentes decentes combinan las cuatro. Los demos se quedan en la primera.
Cómo empezar sin overengineering
- Lista las 10 preguntas que de verdad importan al negocio.
- Marca cuáles se responden con texto y cuáles con datos vivos.
- Conecta tools solo donde haga falta; el resto, buen RAG con chunks limpios y citas.
- Mide fallos: alucinación vs dato obsoleto vs permiso denegado — son problemas distintos.
RAG sigue siendo útil. Solo deja de ser la arquitectura completa en cuanto el agente tiene que operar, no solo explicar.