El 6 de octubre de 2026, AWS publicó un tutorial sobre Sprout, un asistente de jardinería que combina OpenClaw con Amazon Bedrock AgentCore. El patrón lleva mensajes de Telegram y tareas programadas a un mismo agente, y usa AgentCore Memory para recuperar contexto en conversaciones posteriores. La pieza clave es que la extracción de memoria a largo plazo ocurre de forma asíncrona: un dato recién mencionado puede no estar disponible hasta más adelante.
Qué necesitas para seguir el patrón
El ejemplo requiere acceso a AgentCore Runtime y AgentCore Memory, acceso a los modelos elegidos en Amazon Bedrock y un token para el bot de Telegram. AWS también enumera familiaridad con la orquestación de servicios y CloudFormation.
Para crear una imagen personalizada, hacen falta Docker con capacidad de compilación para linux/arm64 y AWS CLI configurada. Esos requisitos corresponden a esa ruta de despliegue, no al uso de la imagen pública del Launch Stack.
Cómo llegan dos vías de entrada al mismo agente
El diseño separa la entrada de mensajes de la ejecución del agente. Telegram envía solicitudes por un webhook; las tareas programadas siguen una ruta distinta. Ambas acaban invocando el mismo agente alojado en AgentCore Runtime.
- Un mensaje de Telegram pasa por API Gateway y una función Webhook Lambda, que invoca el agente.
- Una tarea programada parte de EventBridge Scheduler y llega al agente a través de una función cron Lambda.
- AgentCore Runtime recibe cualquiera de las dos solicitudes y ejecuta el agente con OpenClaw, que aporta el ciclo de agente, las herramientas, las habilidades y el estado de sesión.
El ejemplo de Sprout incluye habilidades para consultar el tiempo, crear recordatorios y guardar notas sobre plantas. Así, Telegram sirve para iniciar una conversación y EventBridge Scheduler para activar tareas programadas, pero ambas entradas comparten el mismo agente.
El contrato del runtime y las rutas de los modelos
El contenedor del ejemplo escucha en el puerto 8080 y expone GET /ping para comprobar su estado y POST /invocations para recibir solicitudes. Un envoltorio llamado server.py inicia y comprueba el estado de OpenClaw Gateway; si el contenedor se reanuda con la pasarela bloqueada, la invocación comprueba su salud y la reinicia cuando hace falta.
AWS asigna rutas diferentes al texto y a las imágenes. El texto pasa por OpenClaw y utiliza Claude Haiku 4.5 en Amazon Bedrock. Las solicitudes con imágenes usan Claude Sonnet 4.5 en Bedrock: server.py envía directamente los bytes de imagen porque la versión de OpenClaw incluida en ese contenedor descartaba partes de contenido image_url. El ejemplo conserva el mismo prompt de personalidad y memoria para ambas rutas.
Cómo fluye la memoria de Sprout
En cada turno, el ejemplo busca registros en el espacio de memoria a largo plazo del usuario usando el mensaje actual. Ordena las preferencias explícitas antes que los datos inferidos y añade los registros seleccionados al prompt del sistema. La búsqueda tiene un presupuesto de 3 segundos y la solicitud puede recuperar hasta 50 registros.
Las conversaciones también se guardan como eventos de corto plazo, asociados al identificador del chat de Telegram y a una sesión. AgentCore Memory extrae después registros de preferencias, semánticos y resúmenes. Como esa extracción es asíncrona, el historial de corto plazo cubre la conversación actual mientras que un dato nuevo puede incorporarse a la memoria de largo plazo en una sesión posterior.
Si la recuperación de memoria falla o supera el tiempo previsto, el ejemplo puede generar una respuesta sin los recuerdos recuperados. La memoria añade contexto, pero el flujo descrito permite que la solicitud continúe sin él.
Elegir entre Launch Stack e imagen personalizada
AWS describe dos formas de desplegar el ejemplo. El Launch Stack de CloudFormation usa una imagen pública de Amazon ECR; la ruta personalizada crea y publica una imagen ARM64 propia antes de desplegar la pila.
| Ruta | Imagen | Requisitos específicos | Acciones descritas |
| Launch Stack | Imagen pública de Amazon ECR | Token de un bot de Telegram | Iniciar la pila de CloudFormation con la imagen pública |
| Imagen personalizada | Imagen ARM64 compilada y publicada en un repositorio privado | Docker con compilación linux/arm64 y AWS CLI configurada | Ejecutar scripts/deploy.sh para validar la plantilla, compilar y publicar la imagen, desplegar la pila y registrar el webhook de Telegram |
La opción pública evita el paso de construir una imagen personalizada. La segunda ruta incorpora esa compilación al despliegue y registra el webhook desde el script.
Servicios auxiliares y limpieza
El patrón asigna espacios de memoria según el identificador del chat de Telegram. También describe el uso de AWS KMS para el cifrado, Secrets Manager para guardar el token del bot, CloudWatch para registros y métricas, y S3 para el almacenamiento del espacio de trabajo.
Al retirar la implementación, el proceso descrito elimina el almacén de memoria y sus espacios de nombres, además de la pila de CloudFormation. Estos componentes forman parte de la configuración del ejemplo; la tarea concreta de limpieza incluye borrar los datos de memoria.
