Bedrock AgentCore Memory: las 3 decisiones de diseño

Por qué la memoria del agente es un problema de ingeniería de contexto

Guardar la conversación y devolverla en el siguiente turno parece, en la superficie, un problema simple. En producción, cualquier founder que haya desplegado un agente sabe que esa aproximación falla rápido: el contexto crece sin control, los datos críticos se pierden entre sesiones y la recuperación se vuelve imprecisa.

El blog oficial de AWS, firmado por Neuton Assis (Enterprise Solutions Architect en AWS AGS), organizó el problema alrededor de tres preguntas que suelen confundirse en una sola: dónde persistir cada tipo de dato, quién debe ser responsable de persistir, y cómo recuperar la información correcta en el momento adecuado.

Amazon Bedrock AgentCore Memory resuelve buena parte del trabajo pesado de almacenamiento, extracción y consolidación, pero no elimina las decisiones de diseño que siguen bajo responsabilidad de quien construye el agente. El servicio separa dos tipos de memoria:

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Corto plazo: historial crudo de la conversación, cada mensaje y cada llamada de herramienta, organizado por actor y sesión.
Largo plazo: insights estructurados extraídos de forma asíncrona por modelos de lenguaje, según estrategias configurables. Hasta la publicación del artículo estaban disponibles las estrategias semántica, preferencias, resumen y episódica, además de la posibilidad de crear estrategias custom.

La integración con Strands Agents (el SDK open-source de AWS) llega por dos caminos: el AgentCore Memory Session Manager se acopla al ciclo de vida del agente, persiste cada turno automáticamente y hace búsqueda semántica al inicio de cada turno; la alternativa es tratar la memoria como herramienta y dejar que el agente decida cuándo consultar o escribir. Ninguno de los dos es universalmente correcto. La elección depende de la naturaleza del dato y de las consecuencias de perderlo. Eso convierte a la memoria en un problema de ingeniería de contexto, no de configuración.

Dónde persistir: no todos los datos viven en el mismo lugar

La primera decisión es clasificar el dato por la fuerza de las relaciones que carga.

Datos contextuales sin relación directa → AgentCore Memory. Cuando la información enriquece la conversación pero no necesita navegarse como un grafo, la Custom Strategy de AgentCore Memory es la más recomendada. Los namespaces separan grandes grupos temáticos cuando hace falta, y la fragmentación eventual es tolerable porque el uso es contextual.

Datos con correlación fuerte → grafo. Un agente de detección de fraude acumula entidades como cuenta, transacción, comerciante y patrón de fraude. El valor está en las relaciones: una transacción es sospechosa porque la cuenta tiene cierto perfil de riesgo y el comerciante está asociado a un patrón conocido. Registros planos de memoria, dispersos por namespaces, difícilmente reconstruyen esa cadena de forma confiable. Para estos casos, un banco de grafos como Amazon Neptune es el almacenamiento adecuado, y AgentCore Memory pasa a ser la capa conversacional, no la fuente de verdad del dominio.

Continuidad conversacional → los últimos N turnos. En canales como WhatsApp, donde la relación con la persona es una única conversación continua, lo esencial es que el agente no responda como si fuera la primera vez. Recuperar las últimas interacciones (los dos últimos turnos o las cuatro últimas mensagens, por ejemplo) al procesar la primera mensagem de cada nueva sesión restablece esa continuidad con poco contexto.

Quién persiste: por qué la sesión es más confiable que el agente

La intuición natural es delegar la grabación al propio agente. Él entiende el dominio mediante el system prompt y parece el candidato ideal para decidir qué vale la pena recordar. Una estrategia genérica podría no reconocer que el prompt del usuario "paciente relata dolor torácico con inicio hace 72 horas" es un dato clínico crítico, pero un agente bien instruido sí lo reconocería.

El problema está en el horizonte de visión de cada aproximación. Cuando el agente graba mediante una herramienta, decide con base solo en el historial disponible en ese instante. Si el usuario interrumpe la conversación, si la sesión expira antes de la próxima decisión de grabación, o si el dato crítico aparece después de la última grabación, la información se pierde. En salud, legal o finanzas, ese tipo de pérdida puede ser inaceptable.

La sesión, en cambio, tiene visión sobre la conversación entera. El Session Manager persiste cada turno y dispara la extracción asíncrona considerando todo el material acumulado, no recortes. La consolidación de AgentCore Memory recupera las memorias semánticamente cercanas en el mismo namespace, las envía al modelo con un prompt de consolidación y decide entre añadir, actualizar o ignorar, usando la fecha de actualización más reciente como una de las señales para resolver conflictos.

Por eso, para garantizar que los datos relevantes sean efectivamente persistidos, la sesión es el mecanismo más confiable, siempre que la estrategia de extracción sepa qué buscar.

Cómo recuperar: del RAG determinístico al agéntico

Aparece aquí la limitación más sutil de la aproximación automática. La recuperación embebida en el Session Manager dispara una búsqueda semántica basada en el mensaje actual del usuario. Es el equivalente a un RAG literal: embedding de la pregunta, búsqueda por similitud, inyección en el contexto. Funciona cuando el mensaje es autosuficiente, pero falla cuando el sentido depende de lo dicho antes.

Si el usuario pregunta "¿y sobre aquello que hablamos?", la búsqueda por esa frase genérica no recupera nada útil. Si la conversación evolucionó por varios turnos y la intención real está distribuida en el historial, buscar por el último mensaje no la captura.

La solución es el RAG de memoria agéntico: darle al agente una herramienta de búsqueda e instruirlo a formular la consulta considerando el historial acumulado de la sesión, no solo el último turno. El agente pasa a razonar sobre qué buscar, reformulando la consulta y consultando más de un namespace cuando el tema lo exige.

Un punto importante: las estrategias no compiten entre sí en la recuperación, se suman. La memoria semántica trae situaciones similares ocurridas antes; la de preferencias trae lo que el usuario suele preferir. Cuando coexisten, la recuperación ideal las combina en el momento de la consulta, en lugar de depender de una sola.

Amazon Neptune: cuando la respuesta vive en las relaciones

La señal más clara de que AgentCore Memory no es suficiente por sí solo es cuando la respuesta correcta depende de recorrer relaciones entre entidades, no solo de recuperar trechos de texto por similitud semántica. Un agente financiero que debe verificar si un fondo de inversión es elegible para un cliente lo ilustra: la elegibilidad depende del perfil de riesgo del cliente, del segmento del fondo, de la jurisdicción regulatoria y de eventuales restricciones contractuales. Cada dimensión es un nodo conectado por aristas tipadas. Una búsqueda vectorial puede recuperar el hecho "cliente tiene perfil conservador", pero no navega la cadena completa hasta la conclusión "fondo X es ineligible porque exige perfil arriesgado y jurisdicción internacional". El grafo hace esa travessia en una sola consulta.

La recomendación es usar Amazon Neptune como fuente de verdad del dominio y AgentCore Memory como capa conversacional. El agente consulta el grafo mediante herramienta cuando necesita respuestas que involucran relaciones, y AgentCore Memory sigue cuidando de las preferencias, los resúmenes y los hechos simples. El ejemplo del artículo usa Strands Agents con una herramienta que ejecuta consultas openCypher (lenguaje declarativo para grafos de propiedad) sobre Neptune mediante el SDK Python de AWS (Boto3), recorriendo cadenas como cuenta → transacción → comerciante → patrón de fraude en una sola consulta Cypher.

Qué significa esto para tu startup

Clasifica el dato antes de elegir el almacenamiento. Si la respuesta exige recorrer relaciones tipadas entre entidades de dominio, usa un grafo (Neptune o equivalente). Si depende de contexto conversacional, preferencias o hechos simples, usa AgentCore Memory con Custom Strategy. Para continuidad en canales como WhatsApp, recupera los últimos N turnos.
Deja que la sesión persista, no solo el agente. El Session Manager ofrece visión completa de la conversación y extracción consolidada. Reserva la grabación vía herramienta para casos en que el agente necesita control explícito sobre un registro puntual. En dominios regulados (salud, legal, finanzas, compliance) la grabación por sesión no es opcional.
Diseña estrategias de extracción específicas de tu dominio. Las estrategias genéricas no reconocerán relevancia específica de tu contexto. Sobrescribe el prompt de extracción con instrucciones explícitas sobre qué es crítico: entidades de riesgo, datos clínicos, términos contractuales, señales de fraude. No confíes solo en una estrategia genérica para reconocer relevancia.
Implementa RAG agéntico para queries ambiguas. Da al agente una herramienta de búsqueda con instrucciones de formular la consulta a partir del historial completo de la sesión. Combina múltiples namespaces y estrategias (semántica + preferencias + custom) en la recuperación, en lugar de depender de una sola.
Audita la seguridad de tu framework antes de producción. Según TechTimes, los investigadores Hedi Ingber y Aviyam Ivgi presentaron en Black Hat USA 2026 (agosto) la clase de vulnerabilidad CoreBreak que afectaba a Bedrock AgentCore, Google ADK y Vercel. AWS parchó AgentCore el 31 de julio de 2026 con validación server-side (CVE-2026-18830), pero el SDK open-source Strands Python mantiene sin parchear un camino de salto de modelo: si despliegas Strands directamente, debes auditar manualmente los puntos donde un caller no confiable pueda inyectar bloques tool-use en el historial de mensajes.

Conclusión

Memoria para agentes no es guardar historial: es decidir arquitecturalmente dónde vive cada dato, quién lo persiste y cómo se recupera. Las decisiones pesan más que la herramienta: AgentCore Memory con Custom Strategy para datos contextuales, Neptune para datos correlacionados, Session Manager para persistencia confiable, y RAG agéntico para recuperación precisa. Tratar la memoria como decisión arquitectural deliberada es lo que separa un agente que solo guarda conversaciones de uno que realmente entiende a sus usuarios a lo largo del tiempo.