Il 6 ottobre 2026 AWS ha descritto un pattern per costruire Sprout, un assistente per il giardinaggio basato su OpenClaw, Amazon Bedrock AgentCore Runtime e AgentCore Memory. Telegram e le attività pianificate seguono percorsi diversi, ma arrivano allo stesso agente; la memoria a lungo termine può dare contesto alle conversazioni successive, dopo un’elaborazione asincrona. (Tutorial di AWS)
Cosa serve per realizzare il pattern
Per seguire l’esempio servono accesso ad AgentCore Runtime e AgentCore Memory, accesso ai modelli scelti in Amazon Bedrock e un token per il bot Telegram. Sono inoltre utili familiarità con l’orchestrazione dei servizi AWS e con CloudFormation.
Docker con supporto alla creazione di immagini linux/arm64 e AWS CLI configurata servono se si sceglie di costruire un’immagine personalizzata. La procedura Launch Stack, invece, usa un’immagine pubblica in Amazon ECR.
Come le richieste raggiungono lo stesso agente
Il pattern prevede due ingressi. Un messaggio Telegram passa da API Gateway e da una funzione Lambda che gestisce il webhook; un’attività pianificata passa da EventBridge Scheduler a una Lambda dedicata. Entrambi i percorsi invocano lo stesso agente su AgentCore Runtime.
La sequenza, in pratica, è questa:
- Scegli gli ingressi. Collega Telegram tramite webhook oppure configura le attività pianificate con EventBridge Scheduler. I due ingressi possono convivere e puntano allo stesso runtime.
- Prepara il runtime. Inserisci l’agente OpenClaw in un container e aggiungi il wrapper
server.py, che avvia e controlla il gateway OpenClaw. - Imposta il contratto HTTP. Il container ascolta sulla porta 8080;
GET /pingrisponde al controllo di stato ePOST /invocationsriceve le richieste dell’agente. (Contratto HTTP di AgentCore Runtime) - Collega memoria e modelli. Prima di comporre la risposta, il pattern recupera i ricordi pertinenti e li inserisce nel prompt; poi instrada la richiesta al modello previsto.
Il runtime separa testo e immagini
Nel pattern descritto da AWS, le richieste testuali passano attraverso il gateway OpenClaw e usano Claude Haiku 4.5 su Amazon Bedrock. Le richieste con immagini vengono invece inviate direttamente da server.py a Bedrock, usando Claude Sonnet 4.5.
Questa seconda strada aggira un problema della build di OpenClaw inclusa nel container descritto: quella versione non conservava le parti di contenuto image_url. Il percorso diretto invia i byte dell’immagine al modello e riutilizza lo stesso prompt con persona e memoria. È una scelta specifica di quell’implementazione.
Come gli eventi diventano memoria a lungo termine
AgentCore Memory registra gli scambi della conversazione come eventi a breve termine. In parallelo, il sistema estrae informazioni durature attraverso le strategie USER_PREFERENCE, SEMANTIC e SUMMARIZATION. L’estrazione è asincrona: un fatto appena menzionato può essere recuperabile soltanto in una sessione successiva.
A ogni richiesta, l’esempio cerca nella memoria a lungo termine usando il messaggio corrente, poi inserisce i record selezionati nel prompt. Le preferenze espresse chiaramente hanno priorità sulle informazioni inferite. La configurazione prevede un budget di recupero di 3 secondi e un massimo di 50 record; se il recupero fallisce o supera il tempo disponibile, l’agente può rispondere senza memoria recuperata.
Per la conversazione in corso restano gli eventi a breve termine: l’estrazione asincrona non sostituisce il contesto della sessione attuale.
Scegliere tra Launch Stack e immagine personalizzata
AWS descrive due percorsi di distribuzione. La scelta dipende soprattutto da quanto vuoi intervenire sulla build del container.
| Percorso | Immagine | Requisiti specifici | Operazioni descritte |
| Launch Stack | Immagine pubblica in Amazon ECR | Token del bot Telegram | Avviare lo stack CloudFormation |
| Immagine personalizzata | Immagine linux/arm64 costruita e caricata in un repository privato | Docker con supporto alle build linux/arm64 e AWS CLI configurata | Validare il template CloudFormation, costruire e caricare l’immagine, distribuire lo stack e registrare il webhook Telegram |
Il primo percorso riduce i passaggi dedicati alla build. Quello personalizzato aggiunge controllo sull’immagine e richiede di occuparsi della compilazione e della pubblicazione nel repository privato.
Gestione e pulizia
Nell’esempio, gli spazi dei nomi della memoria sono organizzati usando l’ID della chat Telegram. Lo stack usa inoltre S3 per lo spazio di lavoro, KMS per la cifratura, Secrets Manager per il token del bot e CloudWatch per log e metriche.
La procedura di pulizia descritta da AWS comprende l’eliminazione dell’archivio della memoria e dei relativi spazi dei nomi.
