Cómo construir un asistente IA con memoria usando AgentCore y OpenClaw

Por qué la continuidad importa

Los asistentes conversacionales modernos responden bien a preguntas puntuales, pero fallan cuando la interacción requiere memoria: ¿recuerdan que mencionó sus camas elevadas que drenan rápido, que usa fertilizantes orgánicos o que sus petunias sufrieron una ola de calor hace semanas? Si cada sesión empieza desde cero, el usuario debe repetir contexto y la experiencia se vuelve frustrante. El punto no es la calidad de la respuesta puntual, sino la ausencia de conocimiento acumulado sobre el usuario.

En este artículo explicamos cómo construir un asistente personal que acumule contexto usando OpenClaw —un sistema agente open source— ejecutándose en el runtime de AgentCore, una capacidad de Amazon Bedrock. AgentCore memory convierte chats descartables en conocimiento durable y recuperable, y permite etiquetar recuerdos con metadatos estructurados para traer solo lo relevante en cada turno.

Nuestro ejemplo de referencia es Sprout, un asistente para jardinería, pero la arquitectura es aplicable a cualquier dominio: soporte al cliente, coach de fitness o mesa de ayuda interna. El despliegue completo está empaquetado en una plantilla de AWS CloudFormation y puede lanzarse con un comando, funcionando con un modelo de consumo que, para uso personal ligero, cuesta apenas unos dólares al mes.

Componentes clave de la solución

La solución integra varios servicios de AWS con OpenClaw y AgentCore:

• AgentCore runtime: ejecuta el agente en contenedores con facturación por consumo, es decir, solo paga por el compute activo y no por tiempo de espera de I/O.
• OpenClaw: proporciona el ciclo de agente, uso de herramientas y un sistema de habilidades (skills).
• AgentCore memory: almacenamiento de recuerdos persistentes que el agente puede indexar y recuperar por relevancia.
• Amazon Bedrock (Converse API): modelos LLM y multimodales; la solución usa dos modelos con distintas funciones.
• Servicios auxiliares: Amazon API Gateway, AWS Lambda, Amazon EventBridge Scheduler, Amazon S3, AWS KMS, AWS Secrets Manager y Amazon CloudWatch.

Dos puntos de entrada convergen en un solo agente: mensajes entrantes desde Telegram (vía API Gateway y una Lambda webhook) y tareas programadas (por EventBridge Scheduler y otra Lambda de cron). Ambas invocan la API InvokeAgentRuntime del runtime de AgentCore, donde un proceso ligero server.py orquesta la puerta de enlace OpenClaw, AgentCore memory y las llamadas a Bedrock.

Flujo operativo resumido

1. El usuario envía un mensaje por Telegram o se activa un recordatorio programado.
2. La Lambda correspondiente hace la llamada al runtime de AgentCore.
3. El container del agente escucha la petición en POST /invocations; server.py valida la salud del gateway OpenClaw, recupera memoria relevante, arma el contexto y reenvía la interacción a OpenClaw o directamente al modelo de Bedrock según la tarea.
4. La respuesta y cualquier nuevo recuerdo se persisten en AgentCore memory.
5. Logs y métricas se envían a CloudWatch; objetos de workspace quedan en S3 y las credenciales sensibles en Secrets Manager.

El wrapper en server.py implementa una lógica práctica: si el proceso de OpenClaw no está vivo, el servicio se encarga de reiniciarlo antes de procesar la petición. Ese patrón facilita adaptar cualquier framework que corra como proceso local al contrato HTTP que exige AgentCore: escuchar en el puerto 8080, exponer GET /ping y POST /invocations.

Ruteo de modelos por tarea

Para equilibrar costo y calidad, el diseño dirige distintos tipos de solicitudes a modelos distintos en Bedrock:

• Claude Haiku 4.5 para texto: rápido y económico, ideal para la mayoría de las conversaciones diarias.
• Claude Sonnet 4.5 para visión: modelo multimodal más potente para tareas puntuales, como diagnosticar una planta a partir de una foto.

En la implementación, los turns de texto fluyen por la puerta de enlace de OpenClaw —que aporta skills y estado de sesión— mientras que las solicitudes que incluyen imágenes se envían directamente a Bedrock desde server.py, enviando los bytes de la imagen como bloques multimodales.

Ventajas económicas y operativas

AgentCore runtime utiliza un modelo basado en consumo: se factura por el cómputo activo del agente, no por el tiempo en que el contenedor está en espera. Para uso personal en ráfagas cortas esto marca una diferencia importante en costos; el artículo original compara un base aproximado de $1–2 al mes frente a un servidor siempre encendido en EC2 que podría costar alrededor de $35/mes (estimaciones a julio de 2026). El ahorro hace viable ofrecer asistentes personalizados de bajo costo a usuarios y equipos en América Latina.

Además, la plantilla CloudFormation agrupa todos los componentes principales, lo que facilita despliegues repetibles y permite a organizaciones con equipos pequeños lanzar prototipos sin un pipeline de build complejo.

Requisitos para desplegar y consideraciones prácticas

Antes de lanzar la plantilla deben cumplirse varios prerrequisitos técnicos:

• Acceso a Amazon Bedrock AgentCore, incluyendo AgentCore runtime y AgentCore memory.
• Permisos de modelo para Claude Haiku 4.5 (texto) y Claude Sonnet 4.5 (visión), o los equivalentes disponibles en su cuenta.
• Docker con soporte linux/arm64 (solo si va a construir y subir su propia imagen), y AWS CLI configurada.
• Token de bot de Telegram (obtenido desde BotFather) para exponer el asistente al usuario.
• Conocimientos básicos de orquestación de agentes y CloudFormation.

Para audiencias en América Latina conviene añadir pruebas de latencia y considerar regiones de AWS cercanas, además de verificar cumplimiento y cifrado de datos sensibles con KMS. El patrón es útil para equipos que necesiten asistentes que recuerden historial de usuarios, preferencias o incidencias, por ejemplo, en servicios de campo, atención al cliente local o iniciativas educativas.

Diseño y buenas prácticas

• Etiquetado de recuerdos: use metadatos estructurados para que las búsquedas traigan solo lo relevante para la interrogante actual (por ejemplo: “problema_planta”, “fertilizante_organico”, “fecha-evento”).
• Límite y política de retención: defina cuánto contexto conservar y reglas para purgar recuerdos antiguos o sensibles.
• Separación de responsabilidades: enrute tareas sencillas por modelos rápidos y reserve modelos multimodales y más costosos para situaciones que realmente lo requieran.
• Resiliencia operativa: implemente verificaciones de salud y reinicio automático del gateway, tal como hace el wrapper server.py.

Conclusión

Combinar OpenClaw con AgentCore y Amazon Bedrock permite transformar asistentes sin estado en compañeros conversacionales con memoria persistente, económicos y fáciles de desplegar. El ejemplo de Sprout demuestra cómo este stack puede personalizarse a dominios específicos; intercambiando la personalidad y el manifiesto de habilidades, la misma tubería sirve para múltiples verticales. Para organizaciones latinoamericanas, la combinación de costos bajos por consumo y despliegues sencillos hace atractivo explorar asistentes con memoria que mejoren la experiencia del usuario y reduzcan carga operativa.