AWS’s Sprout example combines OpenClaw, AgentCore Runtime, and AgentCore Memory to give a gardening assistant context it can retrieve in later conversations. In a tutorial published October 6, 2026, AWS described how Telegram messages and scheduled jobs reach the same agent, how the example routes text and images, and why long-term memory may take until a later session to become retrievable. AWS’s implementation guide lays out a practical pattern for developers assessing this architecture.
What you need
The example requires access to AgentCore Runtime and AgentCore Memory, access to the selected Amazon Bedrock models, and a Telegram bot token. AWS also lists familiarity with agent orchestration and CloudFormation as prerequisites.
A custom image adds two tools to that list: Docker with linux/arm64 build support and a configured AWS CLI. Those are specified for the custom-image route, not the Launch Stack route.
How two request paths reach one agent
Telegram messages and scheduled tasks enter through different services, then invoke the same AgentCore Runtime agent:
- Telegram: Telegram sends a webhook through Amazon API Gateway to a webhook Lambda function, which invokes AgentCore Runtime.
- Scheduled jobs: Amazon EventBridge Scheduler triggers a cron Lambda function, which also invokes AgentCore Runtime.
Inside the runtime, the sample uses OpenClaw for the agent loop, tools, skills, and session state. The shared runtime means both entry points can use the same assistant rather than separate agents for chat and scheduled work.
The runtime contract and model routes
The sample’s server.py wrapper listens on port 8080 and exposes GET /ping for health checks and POST /invocations for agent requests. Those endpoints form its runtime contract; AWS’s AgentCore Runtime HTTP protocol documentation describes the interface.
The example routes text and image requests differently:
- Text: Claude Haiku 4.5 runs through the OpenClaw gateway on Amazon Bedrock.
- Images:
server.pysends image bytes directly to Claude Sonnet 4.5 on Amazon Bedrock.
AWS describes the direct image route as a workaround for the particular OpenClaw build in the sample, which dropped image_url content parts. The text and image paths use the same persona and memory prompt.
How short-term events become long-term memory
The sample records user and assistant turns as short-term conversation events. It also stores a Telegram chat ID as the actor ID and uses a session ID to distinguish conversations. Its example namespaces are sprout/{chat_id}/long_term and sprout/{chat_id}/episodic/{session_id}.
Long-term records are extracted asynchronously using USER_PREFERENCE, SEMANTIC, and SUMMARIZATION strategies. That means a newly mentioned preference can be part of the current conversation without yet being available as a long-term memory; AWS says it may become retrievable in a later session.
For a later request, the sample searches the user’s long-term namespace, ranks explicit preferences ahead of inferred records, and adds selected memories to the system prompt. Retrieval is configured for up to 50 records with a three-second budget. If retrieval fails or times out, the sample can still answer without retrieved memory.
Choosing a deployment path
Both routes deploy the assistant through AWS infrastructure. The Launch Stack uses a public Amazon ECR image; the custom route builds and pushes a private image before deploying the stack and registering the Telegram webhook.
| Deployment path | Image | Additional requirements | Actions described |
| CloudFormation Launch Stack | Public Amazon ECR image | Telegram bot token | Deploy the stack through the Launch Stack. |
| Custom image | Custom linux/arm64 image | Telegram bot token, Docker with linux/arm64 build support, and configured AWS CLI | Run scripts/deploy.sh to validate the template, build and push the image, deploy the stack, and register the webhook. |
Choose the Launch Stack if you want to use the public image. The custom route is for building and pushing an image yourself; it involves extra tooling and deployment steps.
Operations and cleanup
The sample scopes memory namespaces by Telegram chat ID. Its architecture also uses Amazon S3 for workspace storage, AWS Key Management Service for encryption, AWS Secrets Manager for the Telegram bot token, and Amazon CloudWatch for logs and metrics.
During cleanup, the described sequence deletes the memory store and its namespaces along with the deployed resources. That step matters: removing the stack alone is not the same cleanup action as deleting stored memory.
Quick reference
- Telegram and scheduled jobs use separate paths to invoke the same AgentCore Runtime agent.
- The runtime wrapper uses port 8080,
GET /ping, andPOST /invocations. - Long-term memory extraction is asynchronous, and retrieval failure can result in an answer without retrieved memories.
- Use the Launch Stack with its public image or build a custom
linux/arm64image with Docker and AWS CLI.