Cuando una empresa implanta un agente de IA para atender clientes o automatizar procesos, la primera decepción suele llegar a la semana: el agente no recuerda lo que pasó en la conversación anterior. No reconoce al cliente que llamó ayer. No sabe qué reglas de negocio se establecieron en la reunión de onboarding. En la práctica, se comporta como si empezara de cero cada vez.
El problema no es el modelo de lenguaje, sino la ausencia de una arquitectura de memoria bien diseñada. Antes de elegir un framework o una base de datos vectorial, hay que entender qué tipos de memoria existen, qué problema resuelve cada uno, y cuándo utilizarlos. Para eso existe el CoALA framework, y para eso está esta guía.
Los 4 tipos de memoria según el CoALA framework
El CoALA framework (Cognitive Architectures for Language Agents, arXiv:2309.02427) es la taxonomía académica de referencia para los agentes de IA para empresas. Publicado por investigadores de Princeton y Cornell con más de 1.000 citas en la literatura técnica, propone que un agente LLM puede tener cuatro tipos de almacenamiento de información, cada uno con características de persistencia y casos de uso distintos.
La distinción importa porque cada tipo de memoria responde a una pregunta diferente:
- Memoria de trabajo: ¿qué sé ahora mismo, en esta conversación?
- Memoria episódica: ¿qué ha pasado antes en mis interacciones pasadas?
- Memoria semántica: ¿qué sé sobre el mundo, los productos o las reglas de mi empresa?
- Memoria procedimental: ¿cómo debo comportarme y qué procesos debo seguir?
Ignorar esta taxonomía lleva a agentes que «recuerdan» cosas que deberían olvidar, olvidan cosas que deberían recordar, o acumulan contexto innecesario hasta que el coste por llamada se dispara. La siguiente tabla resume los cuatro tipos antes de profundizar en cada uno:
| Tipo | ¿Qué almacena? | Persistencia | Dónde vive |
|---|---|---|---|
| Memoria de trabajo | Contexto activo de la conversación en curso | Temporal (se pierde al cerrar la sesión) | Context window del LLM |
| Memoria episódica | Historial de conversaciones y acciones pasadas | Persistente (recuperable bajo demanda) | Base de datos + vector store |
| Memoria semántica | Conocimiento factual: productos, políticas, datos de clientes | Persistente (actualizable) | Vector store / knowledge graph |
| Memoria procedimental | Instrucciones, flujos de trabajo, comportamiento del agente | Persistente (embedded en el sistema) | System prompt / código |
Memoria de trabajo (in-context): la RAM del agente
La memoria de trabajo es todo lo que cabe en el context window en un momento dado: el mensaje del usuario, el historial reciente de la conversación, los resultados de las herramientas que el agente ha invocado, y las instrucciones del sistema. Es la única memoria que el modelo «ve» directamente cuando genera su respuesta.
Su ventaja es la velocidad: no requiere recuperación, no tiene latencia de búsqueda, y el modelo puede razonar sobre ella sin pasos adicionales. Su limitación es el tamaño. Un context window de 200.000 tokens parece grande, pero una conversación de soporte técnico con historial completo, resultados de búsqueda y documentación de producto puede superar ese límite en minutos. Cuando eso ocurre, el modelo empieza a «olvidar» la parte más antigua del contexto, o el coste por llamada se vuelve prohibitivo.
En la práctica empresarial, la memoria de trabajo es suficiente para agentes de consulta única (un chatbot que responde una pregunta y termina) o workflows de corta duración. En cuanto la conversación supera los 10-15 turnos o el agente necesita recordar algo de una sesión anterior, hay que complementarla con los otros tipos de memoria.
La técnica de context window optimization más usada es la compactación: resumir el historial antiguo antes de que llene el contexto, manteniendo solo los hechos relevantes para la conversación actual. Anthropic documenta en su blog de ingeniería cómo agentes internos mantienen un fichero NOTES.md que el propio agente actualiza al cierre de cada sesión, preservando lo importante sin saturar el contexto.
En LangChain, las dos implementaciones más usadas de memoria de trabajo son ConversationBufferMemory y ConversationSummaryMemory. La primera guarda el historial de mensajes completo tal cual hasta que el contexto se agota; la segunda genera un resumen acumulativo del historial pasado, reduciendo el consumo de tokens a costa de perder algo de granularidad. Para la mayoría de agentes B2B con conversaciones de más de 10 turnos, ConversationSummaryMemory es el punto de partida correcto.
Memoria episódica: el diario de acciones del agente
La memoria episódica almacena el historial de lo que ha ocurrido: conversaciones pasadas, acciones ejecutadas, decisiones tomadas y sus resultados. Es la memoria del «cuándo y qué pasó», equivalente al diario de un empleado que anota lo que hizo con cada cliente para poder retomarlo mañana.
A diferencia de la memoria de trabajo, la memoria episódica persiste entre sesiones. Cuando un cliente vuelve a contactar con el agente, este puede recuperar el contexto de interacciones anteriores: qué preguntó, qué se le respondió, qué problema tenía pendiente. Esa continuidad es la diferencia entre un agente que «parece inteligente» y uno que parece un formulario de autoservicio que no recuerda nada.
Técnicamente, la memoria episódica se implementa combinando una base de datos tradicional (para almacenamiento estructurado: fecha, usuario, tipo de interacción) con un vector store (para búsqueda semántica: «¿qué conversaciones pasadas son relevantes para la pregunta actual?»). El agente realiza una búsqueda de similitud al inicio de cada sesión para recuperar los episodios más relevantes antes de generar su respuesta.
El principal riesgo de la memoria episódica es la acumulación sin filtro: si el agente guarda cada interacción sin criterio, la base de datos crece indefinidamente y la búsqueda de recuperación devuelve ruido. La solución pasa por definir un esquema de consolidación periódica: qué episodios se conservan en detalle, qué se resume y qué se descarta.
Memoria semántica: el conocimiento factual persistente
La memoria semántica es el conocimiento que el agente tiene sobre el mundo y sobre el negocio: el catálogo de productos con sus precios actuales, las políticas de devolución, los datos de clientes del CRM, los documentos técnicos de soporte. Es la memoria del «qué es y cómo funciona», el equivalente a la base de conocimiento que un empleado consulta cuando no sabe la respuesta de memoria.
Es el tipo de memoria que más se implementa con RAG (Retrieval-Augmented Generation): los documentos se vectorizan y se almacenan en un vector store (Pinecone, Qdrant, Chroma, pgvector), y el agente recupera los fragmentos relevantes en cada consulta antes de generar su respuesta. La ventaja frente a meter toda la documentación en el system prompt es el coste y la escalabilidad: se recuperan solo los 3-5 fragmentos más relevantes, no los 500 documentos completos.
La memoria semántica también incluye datos estructurados de clientes (nombre, empresa, historial de compras, preferencias), que el agente puede consultar directamente mediante llamadas a APIs o SQL. Para implementar esta capa de forma persistente y escalable, existen frameworks de memoria para agentes que abstraen la lógica de almacenamiento y recuperación, como Mem0, LangMem o Zep. En arquitecturas más avanzadas, la memoria semántica se combina con el Model Context Protocol para exponer bases de conocimiento externas como herramientas que el agente puede invocar directamente.
Un error frecuente es confundir memoria semántica con los parámetros del modelo. Lo que el LLM «sabe» por entrenamiento (que París es la capital de Francia) es conocimiento paramétrico, no memoria semántica del agente. La memoria semántica es el conocimiento específico del negocio que el modelo base no puede tener: los precios de tu empresa, tus clientes, tus procedimientos internos.
Memoria procedimental: el manual que no se olvida
La memoria procedimental define cómo debe comportarse el agente: qué tono usar, qué pasos seguir en cada tipo de consulta, qué herramientas invocar en qué orden, qué respuestas dar ante situaciones específicas. Es la memoria del «cómo se hace», el equivalente al manual de empleado que describe los protocolos de la empresa.
A diferencia de los otros tipos, la memoria procedimental rara vez se almacena en una base de datos externa. Vive principalmente en el system prompt (las instrucciones que se inyectan al inicio de cada conversación) y en el código del agente (los nodos del grafo, las condiciones de bifurcación, las herramientas disponibles). En ese sentido, es el tipo de memoria menos «dinámico»: no cambia conversación a conversación, sino que se actualiza cuando el negocio decide modificar el comportamiento del agente.
El patrón más robusto en producción combina instrucciones de alto nivel en el system prompt («eres un agente de soporte técnico de nivel 1, escalas al nivel 2 cuando el problema no se resuelve en 3 intentos») con reglas de comportamiento específicas hardcodeadas en el flujo del agente («si el cliente menciona cancelación, transfiere siempre a agente humano»). Las primeras dan flexibilidad; las segundas garantizan comportamientos críticos que no se deben dejar al razonamiento del modelo.
La memoria procedimental también puede evolucionar con el tiempo mediante técnicas de in-context reinforcement: el agente, tras cada interacción positiva o negativa, actualiza un conjunto de «reglas aprendidas» que se inyectan en el system prompt de las siguientes conversaciones. Es el equivalente a que un empleado tome notas de lo que funciona y lo que no, y las consulte antes de cada turno.
Cómo elegir el tipo correcto: matriz de decisión
En la práctica, un agente en producción no usa un solo tipo de memoria, sino una combinación. La clave está en identificar qué necesita cada caso de uso antes de diseñar la arquitectura. Esta es la guía que usamos en Baigency cuando diseñamos la memoria de agentes para clientes PYME, y el punto de partida para entender cómo construir la memoria de tu agente de forma completa.
| Caso de uso | Tipo de memoria principal | Backend recomendado | Coste estimado mensual |
|---|---|---|---|
| Chatbot FAQ / soporte básico (sin historial entre sesiones) | Trabajo + Semántica | Context window + RAG (Qdrant/pgvector) | 5-30 €/mes (infra) + coste LLM |
| Agente de soporte con historial por cliente | Trabajo + Episódica + Semántica | Context window + Mem0 (managed) + vector store | 50-150 €/mes (Mem0 Pro) + LLM |
| Agente de ventas que recuerda prospectos | Episódica + Semántica | Mem0 / Zep + CRM integration | 50-200 €/mes según volumen |
| Agente de automatización de procesos internos | Procedimental + Semántica | System prompt estructurado + RAG (base de conocimiento interna) | 5-50 €/mes (infra) + LLM |
| Agente de investigación / análisis a largo plazo | Episódica + Semántica + Trabajo | LangMem / Letta + vector store | 100-400 €/mes según escala |
| MVP rápido sin infraestructura propia | Trabajo + Semántica básica | Context window + ficheros Markdown como memoria | <10 €/mes (solo LLM) |
| Agente con comportamiento crítico (escalados, RGPD, compliance) | Procedimental + Trabajo | System prompt reforzado + reglas hardcodeadas en el grafo | 0 €/mes adicional (está en el código) |
Dos aclaraciones sobre la tabla. Primero, los costes son estimaciones de infraestructura para una empresa pequeña-mediana con 500-2.000 conversaciones mensuales; el coste del LLM (OpenAI, Anthropic, Mistral) se añade encima y depende del volumen de tokens. Segundo, «backend recomendado» no significa que no haya alternativas válidas: en cada categoría existen opciones open source que reducen el coste a precio de hosting.
Errores comunes al diseñar la memoria de un agente (y cómo evitarlos)
Después de diseñar la arquitectura de memoria de varios agentes para clientes B2B en España, estos son los errores que reaparecen con más frecuencia:
1. Usar solo memoria de trabajo para todo. Es el error de principiante: meter todo el historial en el context window porque es lo más sencillo de implementar. El agente funciona en las primeras conversaciones y se degrada cuando el contexto crece: las respuestas tardan más, el coste se dispara y el modelo empieza a «olvidar» la parte más antigua del historial. La solución no es un context window más grande, sino un sistema de compactación y persistencia externa.
2. Guardar todo en la memoria episódica sin criterio de consolidación. Un agente que acumula cada interacción sin filtro genera una base de datos que crece a 20-50 KB por conversación. Con 1.000 conversaciones mensuales, son 20-50 MB de datos sin estructura, con señal de recuperación cada vez más ruidosa. Definir un esquema de retención (qué se guarda completo, qué se resume, qué se descarta tras N días) es parte del diseño del sistema, no un detalle técnico que se resuelve después.
3. Confundir memoria semántica con fine-tuning. Hacer fine-tuning del modelo para que «recuerde» el catálogo de productos o las políticas de la empresa es caro, lento y difícil de actualizar. La memoria semántica implementada con RAG es más barata, más flexible y no requiere reentrenar el modelo cuando cambia un precio o una política. El fine-tuning tiene su lugar (adaptar el estilo de respuesta, mejorar el seguimiento de instrucciones), pero no es el mecanismo correcto para inyectar conocimiento de negocio dinámico.
4. Dejar la memoria procedimental solo en el system prompt. Un system prompt largo y no estructurado es frágil: el modelo puede ignorar instrucciones que aparecen al final, las reglas interactúan entre sí de formas inesperadas, y es difícil de auditar cuando el agente se comporta de forma incorrecta. Los comportamientos críticos (escalado a humano, restricciones de compliance, respuestas prohibidas) deben estar hardcodeados en el grafo del agente, no solo en el prompt.
5. No diseñar la memoria para el caso de uso real. La pregunta no es «¿qué framework de memoria es el mejor?» sino «¿qué necesita este agente específico para este caso de uso?» Un agente de FAQ simple no necesita Letta ni LangMem. Un agente de soporte premium que atiende a los mismos 200 clientes durante meses necesita memoria episódica persistente bien estructurada. Partir de la matriz de decisión, no de la tecnología.
6. Ignorar los requisitos de privacidad en la memoria episódica. En España, la memoria persistente de conversaciones con clientes es un tratamiento de datos personales sujeto al RGPD. Almacenar conversaciones sin base legal, sin política de retención y sin mecanismo de borrado es un riesgo de compliance real. Antes de activar memoria episódica en producción, definir cuánto tiempo se conservan los datos, bajo qué base legal y cómo se gestiona una solicitud de supresión.
Conclusión. Los cuatro tipos de memoria del CoALA framework no son opciones excluyentes: la mayoría de los agentes en producción combinan tres o cuatro de ellos. La clave está en partir del caso de uso (qué necesita recordar el agente, durante cuánto tiempo, con qué precisión) y elegir la combinación de backends que lo implementa de forma sostenible en coste y mantenimiento. Si tu empresa está evaluando implementar un agente con memoria persistente, en Baigency podemos ayudarte a diseñar la arquitectura correcta desde el primer sprint.
Preguntas frecuentes
¿Qué tipos de memoria tiene un agente de IA?
Según el CoALA framework (Princeton, arXiv:2309.02427), un agente de IA puede tener cuatro tipos de memoria: memoria de trabajo (in-context, temporal), memoria episódica (historial de conversaciones pasadas, persistente), memoria semántica (conocimiento factual y de negocio, persistente en vector store o base de datos) y memoria procedimental (instrucciones y comportamientos del agente, embedded en el system prompt y el código). En la práctica, un agente en producción combina varios de estos tipos según su caso de uso.
¿Qué es la memoria episódica en un agente de IA?
La memoria episódica almacena el historial de interacciones pasadas del agente: qué conversaciones tuvo, qué acciones ejecutó y cuáles fueron sus resultados. Es la memoria del «qué pasó antes», equivalente al diario de un empleado. Se implementa típicamente con una combinación de base de datos relacional (para metadatos estructurados: fecha, usuario, tipo de interacción) y un vector store (para recuperación semántica: encontrar qué episodios pasados son relevantes para la conversación actual). Permite que el agente reconozca a clientes recurrentes y retome conversaciones sin volver a empezar desde cero.
¿En qué se diferencia la memoria semántica de la episódica?
La memoria episódica es el historial de lo que ha ocurrido (conversaciones, acciones, resultados concretos con fecha y contexto). La memoria semántica es el conocimiento factual atemporal: el catálogo de productos, las políticas de la empresa, los datos del CRM. Una forma de distinguirlas: la episódica responde a «¿qué pasó con este cliente el martes?»; la semántica responde a «¿cuál es el precio de este producto?» o «¿cuáles son las condiciones de devolución?». En muchos agentes, la memoria semántica se implementa con RAG y la episódica con un sistema de recuperación de conversaciones pasadas.
¿Qué es la memoria procedimental de un agente?
La memoria procedimental define el comportamiento del agente: qué tono usar, qué pasos seguir, qué herramientas invocar en cada situación y qué respuestas dar ante casos específicos. Es la memoria del «cómo se hace», equivalente al manual de empleado. A diferencia de los otros tipos, no se almacena en una base de datos externa: vive en el system prompt y en el código del agente (las condiciones del grafo, las reglas de escalado, las herramientas disponibles). Es el tipo de memoria más estático: se modifica cuando el negocio decide cambiar el comportamiento del agente, no conversación a conversación.
¿Qué es el CoALA framework?
CoALA (Cognitive Architectures for Language Agents) es un framework académico publicado en 2023 por investigadores de Princeton y Cornell (arXiv:2309.02427) con más de 1.000 citas en la literatura técnica. Propone una taxonomía unificada de los componentes de un agente LLM: los cuatro tipos de memoria (trabajo, episódica, semántica, procedimental), los tipos de acciones que puede ejecutar (retrieval, razonamiento, interacción externa) y el ciclo de decisión. Es la referencia estándar del campo cuando se habla de arquitectura de agentes y el punto de partida para entender por qué existen tantos frameworks de memoria distintos.
¿Qué tipo de memoria necesita mi caso de uso?
Depende de tres preguntas: ¿El agente necesita recordar información entre sesiones distintas? (Si no, la memoria de trabajo es suficiente.) ¿Necesita conocimiento específico del negocio que el modelo base no tiene? (Si sí, memoria semántica con RAG.) ¿Necesita reconocer a usuarios individuales y retomar conversaciones pasadas? (Si sí, memoria episódica persistente.) Los comportamientos críticos (escalados, compliance, restricciones) siempre necesitan memoria procedimental hardcodeada. La matriz de decisión de Atlan también es una referencia útil para este tipo de evaluación por caso de uso.
Diseña la memoria de tu agente con criterio
Elegir el tipo de memoria correcto no es una decisión técnica menor: determina si tu agente aprende de cada conversación o empieza de cero, si reconoce a tus clientes o los trata como desconocidos, si escala a coste controlado o se dispara con el volumen. La taxonomía del CoALA framework es el punto de partida, pero la aplicación depende del caso de uso concreto de tu empresa.
En Baigency llevamos la arquitectura de memoria de agentes para PYMEs que no quieren gestionar infraestructura compleja pero sí necesitan que su agente funcione bien en producción. Si estás evaluando qué tipo de memoria necesita tu agente, nuestra consultoría de IA es el primer paso para definirlo con criterio, sin sobre-ingeniería y sin quedarte corto.
