Los asistentes de IA estándar responden bien a las preguntas individuales, pero se quedan cortos en un eje diferente: la continuidad. Pregúntale a un asistente apátrida sobre tu huerto hoy y no tendrá ni idea de que mencionaste que hace tres semanas mencionaste que tus canteros elevados se drenaban rápidamente, que solo utilizabas fertilizantes orgánicos o que tus petunias estaban pasando apuros por una ola de calor. Cada conversación comienza desde cero, y la carga de volver a explicar el contexto recae

El problema no es la calidad de las respuestas, sino que el asistente no recuerda nada de ti. En este artículo se muestra cómo crear un asistente personal que acumule contexto mediante OpenClaw, un sistema de agencia de código abierto que funciona con AgentCore Runtime, una funcionalidad de Amazon Bedrock AgentCore. La memoria AgentCore, una capacidad de Amazon Bedrock AgentCore, convierte los chats desechables en conocimiento duradero. También aprenderá a etiquetar esos recuerdos con metadatos estructurados para recuperar los registros relevantes para la pregunta en cuestión

Nuestro ejemplo habitual es Sprout, un asistente de jardinería, pero la arquitectura es independiente del dominio. Cambie la personalidad por la que se manifiesten sus habilidades y obtendrá el mismo flujo de trabajo para un robot de apoyo, un preparador físico o un servicio de asistencia interno. Todo el sistema se encuentra en una única plantilla de AWS CloudFormation, se implementa con un solo comando y se ejecuta según un modelo basado en el consumo que cuesta unos pocos dólares al mes para un uso personal ligero. Además, compartimos las directrices de diseño que puede aplicar a los asistentes que cree a partir de

Descripción general de la solución

AgentCore es una plataforma para crear, conectar y optimizar agentes a escala, con cualquier marco o modelo. El siguiente diagrama muestra el flujo de solicitudes de principio a fin, desde un webhook entrante de Telegram hasta el motor de ejecución de AgentCore

Figura 1: Los webhooks de Telegram y las programaciones de Amazon EventBridge invocan el mismo agente de ejecución de AgentCore, que coordina la puerta de enlace de OpenClaw, la memoria de AgentCore y Amazon Bedrock

Dos puntos de entrada convergen en un agente. Los mensajes de Telegram llegan a través de Amazon API Gateway y una función Webhook de AWS Lambda, mientras que las tareas programadas, como los recordatorios de agua por la mañana, llegan a través de Amazon EventBridge Scheduler y una función cronjob Lambda. Ambas utilizan la API InvokeAgentRuntime en el entorno de ejecución de AgentCore, donde un proceso server.py ligero coordina la puerta de enlace de OpenClaw, la memoria de AgentCore y la API Amazon Bedrock Converse. Amazon Simple Storage Service (Amazon S3) proporciona almacenamiento en el espacio de trabajo, AWS Key Management Service (AWS KMS) gestiona el cifrado, AWS Secrets Manager almacena el token del bot y Amazon CloudWatch captura

Requisitos previos

Para implementar su propia versión con el botón Launch Stack o con scripts/ deploy.sh (descrito en la sección Haga crecer su propia versión), necesitará:

• Acceso a Amazon Bedrock AgentCore, incluido el tiempo de ejecución de AgentCore y la memoria de AgentCore.
• Se concede acceso a los modelos a los que tiene pensado enviar una ruta: Claude Haiku 4.5 para texto y Claude Sonnet 4.5 para visión (o los modelos equivalentes disponibles en su cuenta).
• Docker compatible con la compilación de linux/arm64, además de la interfaz de línea de comandos de AWS (CLI de AWS) configurada. Esto solo es necesario si tiene previsto crear y publicar su
propia imagen.
• Un token de bot de Telegram (de BotFather) que sirva de puerta de entrada al asistente.
• Familiaridad básica con los conceptos de orquestación de agentes y CloudFormation.

La arquitectura: un agente sin servidor en tiempo de ejecución de AgentCore

Todos los componentes se encuentran en una única plantilla de CloudFormation y no se necesitan herramientas de compilación para lanzarlos. En las siguientes secciones se describen las decisiones que implican una carga

Tiempo de ejecución de AgentCore: pague solo por el procesamiento activo

El agente reside en un contenedor en AgentCore Runtime, que utiliza precios basados en el consumo. Se le factura por los recursos informáticos que consume activamente su agente, no por el tiempo de actividad habitual, y no paga por el tiempo de espera de la E/S, por ejemplo, de la respuesta del modelo. En el caso de un asistente personal que se utiliza en ráfagas breves, esa es la diferencia entre un valor base de aproximadamente 1 a 2 dólares al mes y una instancia de Amazon Elastic Compute Cloud (Amazon EC2) siempre activa de aproximadamente 35 dólares al mes. Estas cifras son estimaciones para un uso personal ligero en julio de 2026. Consulte los precios de AgentCore para conocer las tarifas actuales

El motor de ejecución impone un contrato de contenedor mínimo: escucha en el puerto 8080 y expone GET /ping para el estado y POST /invocations como punto de entrada del agente. Nuestro contenedor es linux/arm64, creado en varias etapas

OpenClaw como sustrato agente

OpenClaw proporciona el ciclo de agentes, el uso de herramientas y un sistema de habilidades. Ejecuta un contenedor (server.py) que lo adapta al contrato de protocolo HTTP de AgentCore

• Al iniciar el contenedor, server.py lanza la ejecución de openclaw gateway como un subproceso y comprueba su estado.
• GET /ping vuelve a funcionar rápidamente, por lo que la sonda de preparación de AgentCore es correcta.
• POST /invocations se encarga de todo: analizar la carga útil, recuperar la memoria, ensamblar el contexto, reenviar el turno a la puerta de enlace y conservar el resultado. Un aviso: AgentCore puede descongelar un contenedor congelado cuyo subproceso haya finalizado. Por lo tanto, la ruta de invocación no asume que la puerta de enlace está activa, sino que llama a un ayudante ensure_openclaw_ready () que vuelve a comprobar su estado (y reinicia la puerta de enlace si es necesario) antes de reenviar el turno
.

Este patrón de envoltura se generaliza a otros casos de uso. Cualquier marco de agente que se ejecute como un proceso local se puede adaptar al tiempo de ejecución de AgentCore de la misma manera, sin modificar el

Dos modelos, enrutados por tarea

El chat de texto y la comprensión de imágenes tienen diferentes desventajas en cuanto a coste y calidad, por lo que el asistente los dirige a diferentes modelos de Claude en Bedrock:

• Claude Haiku 4.5 para texto: rápido y económico para los turnos de conversación de gran volumen que dominan el uso diario.
• Claude Sonnet 4.5 para la visión: Razonamiento multimodal más sólido para la tarea menos frecuente pero más difícil de diagnosticar una planta a partir de una fotografía.

texto cambia el flujo a través de la puerta de enlace OpenClaw, que aporta habilidades y estado de sesión. Los turnos de imagen llaman al modelo de lenguaje grande (LLM) de Bedrock directamente desde server.py y transfieren los bytes de la imagen como bloques de contenido multimodales. Distribuimos las imágenes por la puerta de enlace de forma deliberada: la compilación de OpenClaw integrada en el contenedor eliminaba las partes del contenido de image_url antes de que llegaran a Bedrock, por lo que al llamar a la API de Converse directamente desde server.py, se asegura de que el modelo vea los píxeles reales. Ambas rutas comparten el mismo indicador del sistema (persona más memoria)

Los ID de los modelos son variables de entorno (MODEL_ID, VISION_MODEL_ID), por lo que puede intercambiar modelos por implementación sin tener que reconstruir la imagen.

Habilidades como unidad de capacidad

Un script en el momento de la implementación las materializa en el contenedor y las registra en la configuración de OpenClaw antes de crear la imagen. Al momento de publicar este artículo, Sprout viene con habilidades meteorológicas, recordatorios y notas sobre plantas. Cambia el manifiesto y la misma canalización servirá a un dominio diferente. Esto es lo que hace que todo sea un patrón reutilizable y no solo un bot.

Telegram como puerta de entrada sin servidores

Telegram es un canal práctico para un asistente personal, ya que está basado en webhooks y mantiene todo sin servidor. No requiere desarrollo por parte del cliente, funciona en todos los dispositivos que el usuario ya posee y admite texto, imágenes y formatos enriquecidos a través de una sencilla API de bots. BotFather emite un token de bot, que se almacena en Secrets Manager. La implementación registra un webhook que dirige a Telegram al punto final de la puerta de enlace de la API. Cuando el usuario envía un mensaje, Telegram lo envía a la función Lambda del webhook para validar la carga útil y llamar a InvokeAgentRuntime. La respuesta regresa a través de la API del bot de Telegram

Una lección de formato a tener en cuenta: el antiguo modelo de markdown de Telegram es implacable con los caracteres que no se escapan y un solo subrayado suelto en una respuesta modelo puede hacer que no se envíe todo el mensaje. La representación de las respuestas en formato HTML es fiable, por lo que el asistente convierte la salida del modelo

Memoria: convertir las conversaciones desechables en conocimiento duradero

La arquitectura descrita hasta ahora consiste en un agente capaz, barato y sin servidor, pero por sí solo se olvida de ti entre una conversación y otra. La memoria es lo que cambia eso. Imagina que hace semanas mencionaste que hacías un huerto orgánico, y hoy el ayudante te recomienda un tratamiento y añade, por sí solo, que eligió la opción orgánica porque no utilizas fertilizantes sintéticos. Un modelo apátrida no puede hacer eso

El modelo mental: eventos a corto plazo, extracción a largo plazo

memoria de AgentCore tiene dos capas. La memoria a corto plazo almacena cada turno de conversación como un evento a través de CreateEvent, tecleado mediante actOrID (el identificador de chat de Telegram) y sessionID. Esta es la transcripción sin procesar. La memoria a largo plazo se produce de forma asincrónica mediante estrategias de extracción gestionadas para convertirla en registros estructurados y duraderos. Configuramos tres estrategias

• USER_PREFERENCE: elecciones explícitas que indicó el jardinero («Solo uso fertilizante orgánico»).
• SEMÁNTICA: hechos inferidos («cultiva petunias mexicanas en una cama elevada de acero corten»).
• RESUMEN: resúmenes de sesiones episódicas («se discutió el amarilleo de las hojas inferiores durante una ola de calor»).

Espacios de nombres: un jardín por jardinero

Sprout archiva los registros en espacios de nombres por usuario, para que no se mezclen dos chats:

• sprout/ {chat_id} /long_term: preferencias y hechos semánticos.
• sprout/ {chat_id} /episodic/ {session_id}: resúmenes de las sesiones.

El ID de chat es el único segmento variable, lo que hace que el aislamiento sea sencillo de razonar y probar: cada jardinero único se asigna exactamente a un espacio de nombres y no hay dos jardineros que choquen.

La tubería de recuperación, ensamblaje e inyección

En cada turno, el agente recupera los registros relevantes a largo plazo, los clasifica y los inyecta en el indicador del sistema.

• Recuperar. Llama a RetrieveMemoryRecords con sprout/ {chat_id} /long_term y utiliza el mensaje del usuario como consulta de búsqueda, con un límite de 50 resultados, por debajo de un presupuesto de 3 segundos. Si se agota el tiempo de recuperación o se produce un error, se degrada correctamente y respondemos sin memoria en lugar de fallar.

prueba:
 records = memory_client.retrieve_memory_records (
 memoryID=memory_id,
 namespace=f'sprout/ {chat_id} /long_term',
 Criterios de búsqueda = {
 'searchQuery': user_message,
 «a PK»: 50,
 'Filtros de metadatos': []
 },
 ) Tiempo de espera de 3 segundos
excepto la excepción:
 records = [] # recurre a responder sin memoria

Fragmento 1: Recuperar los registros a largo plazo del turno actual (representativo). Consulte el repositorio para

La función de ensamblaje agrega lógica personalizada adicional. Queremos que las preferencias explícitas se clasifiquen por encima de los hechos inferidos, que el orden sea estable dentro de cada clase y que el resultado esté limitado antes de la inyección

def assemble (registros, cap=50):
 explicit = [r para r en los registros si r.type == 'USER_PREFERENCE']
 inferred = [r para r en los registros de r.type! = 'USER_PREFERENCE']
 # tiempos explícitos inferidos; orden estable dentro de cada clase
 ordenado = explícito + inferido
 devolución ordenada [:cap]

Fragmento 2: La fase de ensamblaje clasifica las preferencias explícitas antes que los hechos inferidos.

Metadatos: subagrupar memorias dentro de un espacio de nombres

Los espacios de nombres indican de quién es la memoria de un registro, pero los metadatos indican de qué se trata. Dentro de sprout/ {chat_id} /long_term, una búsqueda semántica de «mis petunias se están marchitando» arrojaría todo lo que tenga un significado parecido. Para un jardinero, eso significa que su preferencia de fertilizante a partir de marzo y una nota de poda de higuera se clasifican junto con los registros que realmente importan. Además, los metadatos estructurados nos ayudan a reducir el alcance de los recuerdos antes de que lleguen al mensaje.

este caso, cada decisión se basa en una regla. Una clave de metadatos solo se puede filtrar en el servidor si la declaras como clave indexada. Puede obtener más información en Filtrado de memoria estructurada con metadatos en Amazon Bedrock AgentCore Memory. En este caso, sprout usa

IndexedKeys: # en el recurso AWS: :BedrockAgentCore: :Memory
 - Clave: escriba # para separar los tipos de registros
 Tipo: CADENA
 - Clave: número de sección de qué cama o área describe
 Tipo: CADENA
 - Clave: plantas # lo que crece allí
 Tipo: STRINGLIST

Cada entrada nombra una clave, que debe coincidir con una clave indexada para poder filtrarse, y establece ExtractionType en STRICTLY_CONSISTENT, transmitida desde el evento, o en LLM_INFERRED, extraída de la conversación. En el caso de las claves inferidas, una configuración de extracción puede restringir los valores a una lista fija. Sprout hace eso exactamente, por lo que ambas rutas de escritura crearían el mismo vocabulario y un filtro tendría el mismo significado independientemente de la parte que haya creado el registro

Manteniendo el turno y cerrando el bucle

Cuando el modelo responde, server.py llama a CreateEvent con el turno del usuario y el turno del asistente. Ese nuevo evento alimenta las estrategias de extracción, que enriquecen la tienda a largo plazo para la próxima vez

memory.create_event (
 memoryID=memory_id,
 ID de actor = chat_id,
 ID de sesión = ID de sesión,
 carga útil = [
 {'rol': 'usuario', 'contenido': user_message},
 {'rol': 'asistente', 'contenido': responder},
 ],
) # alimenta la extracción de USER_PREFERENCE/SEMANTIC/SUMMARIZATION; los errores se registran, nunca son fatales

Fragmento 3: Mantener el turno para que las estrategias de extracción puedan enriquecer la memoria a largo plazo de forma asincrónica.

La extracción es asincrónica, por lo que un hecho mencionado en esta sesión normalmente se puede recuperar en una sesión posterior. Diseñe para ese retraso: los eventos de sesión a corto plazo cubren la conversación actual y los registros a largo plazo

Preparándolo: un plan de riego personalizado

Aquí es donde todo el oleoducto funciona de principio a fin. En unas cuantas conversaciones, catalogas todo tu jardín, una planta a la vez, en un lenguaje sencillo. Cada mención se convierte en un evento. Las estrategias de extracción extraen información sobre la planta, su ubicación y su exposición al sol para convertirla en sprout/ {chat_id} /long_term. Esta mañana, el usuario hace una pregunta: «¿Recuerdas las otras plantas de mi jardín?» Retrieval recupera los registros, Assembly los clasifica y los coloca en el indicador del sistema. El asistente responde con la ubicación del usuario, la exposición al sol, la construcción de los lechos, el comportamiento del suelo y el inventario de las plantas, nada de lo cual aparece en el propio mensaje

Figura 2: Sprout responde a una pregunta sobre el huerto recordando el inventario de plantas almacenadas y las condiciones de cultivo

Con la habilidad programador de Amazon EventBridge → Cron path, Sprout también puede convertir ese plan en recordatorios proactivos («omita las hierbas, la tierra aún está húmeda como la de ayer») y ajustarla según las condiciones meteorológicas cuando se avecina una lluvia o una ola de calor.

La memoria y la visión también se complementan. Cuando el usuario envía una foto de una planta marchita, la imagen pasa a Claude Sonnet 4.5, mientras que el indicador del sistema aún contiene todo lo que sabe la capa de memoria. El asistente compara la foto con las petunias mexicanas que ya están en el inventario guardado por el usuario y diagnostica el estrés causado por la marchitez en su contexto, en lugar de analizar una foto anónima de una planta en

Figura 3: Visión y memoria trabajando juntas. La foto pasa al modelo de visión, mientras que el indicador del sistema muestra el contexto del jardín almacenado por el usuario

Los modelos de visión no son infalibles. En un intercambio anterior sin el contexto del inventario, la misma planta fue identificada con seguridad como una planta luisa, una especie con flores púrpuras similares en forma de trompeta. Basar el modelo de visión en el inventario almacenado del propio usuario es lo que convirtió una suposición plausible en un diagnóstico correcto y personalizado, y es un buen ejemplo de por qué la memoria mejora la precisión y no solo el tono

Mantener bajos los costos de inferencia con un almacenamiento rápido en caché

inyecta memoria en cada turno, las solicitudes del sistema se agotan, y una implementación ingenua pagaría por esos tokens en cada solicitud. El almacenamiento rápido en caché en Amazon Bedrock soluciona este problema. El asistente estructura su mensaje de modo que el prefijo estable, la persona y el bloque de memoria ensamblado, ocupen el primer lugar y el mensaje volátil del usuario quede en último lugar. Bedrock almacena en caché el prefijo procesado de todas las solicitudes, de modo que los turnos repetidos dentro de una conversación omiten volver a calcular la parte que no ha cambiado. El almacenamiento rápido en caché puede reducir los costos hasta en un 90 por ciento y la latencia hasta en un 85 por ciento en los modelos

La regla de ordenamiento es más importante que cualquier otra configuración: poner el contenido estable en primer lugar, el contenido volátil en último lugar y mantener el orden interno del bloque de memoria determinista (lo que facilita la función de ensamblaje anterior) para que el prefijo coincida realmente entre las solicitudes.

Pautas de diseño para basarse en AgentCore y OpenClaw

Sprout es un asistente, pero las decisiones que lo sustentan son generalizadas. Si estás creando tu propio asistente a partir de esta pila, las siguientes directrices son las que aplicaríamos a cualquier dominio

• Envuélvalo, no lo use con un tenedor. Adapte el marco de su agente al contrato de contenedor de AgentCore con un contenedor HTTP delgado en lugar de modificar el marco. El contrato es pequeño, el puerto 8080 contiene /ping y /invocations, y un contenedor
lo mantiene en la ruta de actualización del marco.
• Diseñe los espacios de nombres antes de almacenar cualquier cosa. Los espacios de nombres de memoria son su límite de aislamiento. Convierte el ID de usuario en el único segmento variable y elígelo entre un ID nativo del canal en el que ya confíes, como el ID de chat. Los diseños con varios usuarios reciben con el tiempo auditorías y solicitudes de eliminación. Un esquema de espacio de nombres limpio hace que ambas cosas sean triviales
.
• Trate la memoria como una mejora, nunca como una dependencia. Se debe permitir que todas las operaciones de memoria fallen correctamente. Los errores de recuperación deberían producir una respuesta sin memoria sin bloquear la respuesta. Los usuarios perdonan un giro olvidadizo con mucha más facilidad que
uno fallido.
• Modelos de rutas por tarea. Utilice un modelo rápido y rentable para textos de gran volumen y reserve un modelo multimodal más sólido para los turnos que lo necesiten. Mantenga los ID del modelo en las variables de entorno para que los cambios de enrutamiento sean de configuración, no
de código.
• Solicita solicitudes para la caché. La personalidad y la memoria estables primero, las entradas volátiles del usuario al final y un orden determinista en todo momento. Este hábito estructural es de donde provienen la mayoría de los ahorros de inferencia
.
• Planifique la latencia de extracción. La memoria a largo plazo se extrae de forma asincrónica, así que no prometas recordar datos nuevos en la misma sesión. Deje que los eventos de la sesión a corto plazo cubran la conversación actual y los registros a largo plazo
cubran las anteriores.
• Haga un presupuesto desde el primer día. Un agente basado en el consumo no es costoso hasta que un bucle de reintentos o un usuario que habla por teléfono hace lo contrario. Una alerta de AWS Budgets con el 80 por ciento y el 100 por ciento de un límite mensual no cuesta nada
y atrapa las sorpresas con antelación.
• Mantenga las habilidades reducidas y con un único propósito. Una habilidad debe hacer algo que un usuario nombraría en una oración, como comprobar el tiempo o establecer un recordatorio. Las habilidades pequeñas se pueden comprobar de forma independiente, se pueden intercambiar de forma independiente y el modelo puede seleccionarlas fácilmente. Una habilidad que lo permite todo obliga al modelo a adivinar a cuál de sus
comportamientos te refieres.

Cultiva el tuyo

Dos formas de plantarlo, en el mismo jardín:

• Launch Stack en un solo paso: la plantilla de CloudFormation apunta a una imagen pública de Amazon Elastic Container Registry (Amazon ECR), por lo que solo implementa un token de bot de Telegram.
• Crea la tuya propia: el script scripts/ deploy.sh valida la plantilla, crea y envía tu propia imagen ARM64 a tu repositorio privado de Amazon ECR, implementa la pila y registra el webhook de Telegram para crear una compilación totalmente personalizable.

El uso personal ligero cuesta entre 5 y 9 dólares al mes en julio de 2026 (aproximadamente 2 dólares en infraestructura, entre 1 y 3 dólares en texto en Haiku y 2 dólares en Sonnet Vision), con un presupuesto de AWS integrado que alerta del 80 y el 100 por ciento del límite que establezca.

El código fuente completo está disponible en repositorio de GitHub sample-agentcore-memory-openclaw

Limpiar

Cuando termines de experimentar, derriba todo para evitar cargas continuas. Como todo el sistema es una pila de CloudFormation, la limpieza consiste principalmente en eliminar una

1. Elimine la pila de CloudFormation. Esto elimina el agente de ejecución de AgentCore, API Gateway, las funciones de Lambda, la programación de Amazon EventBridge y las funciones asociadas de AWS Identity and Access Management
(IAM).
2. Elimine el almacén de memoria de AgentCore (y sus espacios de nombres) para que no se conserve ningún registro de usuario.
3. Elimine todas las imágenes que haya subido a su repositorio ECR privado y, si ya no es necesario, el repositorio en sí.
4. Elimine la alerta de presupuesto de AWS si ha creado una fuera de la pila.
5. Revoca el webhook de Telegram (o elimina el bot a través de BotFather) y revoca el acceso al modelo Bedrock si ya no lo necesitas.

Conclusión

El núcleo reutilizable de esta solución es un agente sin servidor en Amazon Bedrock AgentCore con un sistema de habilidades y memoria gestionada. La memoria de AgentCore elimina la necesidad de crear almacenes vectoriales y procesos de extracción personalizados y, al mismo tiempo, deja el control total sobre lo que el agente recuerda y olvida. La computación basada en el consumo y el almacenamiento rápido en caché permiten mantener un asistente realmente personalizado por unos pocos dólares al mes, y el conjunto de habilidades de OpenClaw hace que todo el patrón sea portátil en todos los dominios. La personalización también se agrava: cuanto más interactúa un usuario, más útil resulta el asistente

Para ir más allá, empieza con un único dominio, como los recordatorios, y amplía el alcance de la memoria de forma gradual. Explora la memoria episódica para que el agente pueda hacer referencia a conversaciones pasadas específicas («la última vez que hablamos de la higuera, decidiste dejar de usar fertilizante»), o bifurcar el repositorio, cambiar tu personalidad y habilidades y hacer crecer el asistente que necesites.

Para obtener más información, consulta la documentación de AgentCore. Las siguientes publicaciones relacionadas cubren los componentes básicos con más profundidad

• Memoria Amazon Bedrock AgentCore: creación de agentes sensibles al contexto
• Creación de agentes de IA más inteligentes: análisis profundo de la memoria a largo plazo de AgentCore
• Utilice de forma eficaz el almacenamiento rápido en caché en Amazon Bedrock

Acerca de los autores