Am 6. Oktober 2026 beschrieb AWS mit Sprout ein Muster für einen kontextbezogenen KI-Assistenten: OpenClaw läuft auf AgentCore Runtime, AgentCore Memory hält Gesprächsereignisse fest und bereitet daraus längerfristige Erinnerungen auf. Telegram-Nachrichten und geplante Aufgaben erreichen denselben Agenten über getrennte Wege. Der entscheidende Punkt für den Alltag: Neue Langzeiterinnerungen stehen nicht zwingend sofort bereit. AWS’ Beispiel richtet sich an Entwickler, die den Aufbau nachvollziehen und eine passende Bereitstellungsroute wählen möchten.
Voraussetzungen und Aufbau
Für das Beispiel braucht man Zugriff auf AgentCore Runtime und AgentCore Memory sowie auf die ausgewählten Modelle in Amazon Bedrock. Hinzu kommen ein Telegram-Bot-Token und Kenntnisse zu Orchestrierung und AWS CloudFormation. Für den eigenen Image-Build sind außerdem Docker mit Unterstützung für linux/arm64 und eine konfigurierte AWS CLI erforderlich.
Der Aufbau lässt sich in vier Stationen gliedern:
- Eingang festlegen: Telegram-Nachrichten treffen über API Gateway und eine Webhook-Lambda ein. Geplante Aufgaben starten über Amazon EventBridge Scheduler und eine Cron-Lambda. Die getrennten Wege führen beide zum selben AgentCore-Runtime-Agenten.
- Runtime bereitstellen: Ein Container hostet den Agenten. Die Wrapper-Datei
server.pyerfüllt den Runtime-Vertrag über Port 8080 sowieGET /pingfür die Statusabfrage undPOST /invocationsfür Agentenanfragen. Die AWS-Dokumentation zum HTTP-Vertrag beschreibt diese Schnittstelle. - Anfrage bearbeiten: OpenClaw übernimmt im Beispiel den Agentenablauf. Textanfragen gehen über OpenClaw an Claude Haiku 4.5 in Amazon Bedrock. Bildanfragen leitet
server.pydirekt an Claude Sonnet 4.5 in Bedrock weiter. - Gespräch für später speichern: Der Agent ruft passende Langzeitdatensätze ab, stellt sie dem Modell im Prompt bereit und speichert Gesprächsereignisse für die weitere Verarbeitung. So kann eine spätere Unterhaltung auf früher genannte Vorlieben oder Informationen zurückgreifen.
Wie Telegram und Zeitpläne denselben Agenten erreichen
Telegram und geplante Aufgaben kommen über unterschiedliche AWS-Komponenten herein. Bei Telegram führt der Weg über API Gateway zur Webhook-Lambda; bei zeitgesteuerten Aufgaben löst EventBridge Scheduler eine Cron-Lambda aus. Beide Funktionen rufen denselben AgentCore-Runtime-Agenten auf.
Diese Trennung hält die Eingänge auseinander, während die Verarbeitung beim Agenten zusammenläuft. Ein Telegram-Chat startet eine unmittelbare Anfrage; ein geplanter Auftrag kann denselben Agenten über den Zeitplanweg anstoßen.
Runtime-Vertrag und Modellwege
server.py startet und überwacht im beschriebenen Aufbau das OpenClaw-Gateway. Der Container lauscht auf Port 8080. GET /ping dient der Statusabfrage, POST /invocations nimmt Agentenanfragen entgegen. AWS beschreibt außerdem, dass die Invocation die Gateway-Gesundheit prüft und es bei Bedarf neu startet, wenn ein eingefrorener Container wieder aktiv wird.
Die Modellzuordnung unterscheidet zwischen Text und Bildern: Claude Haiku 4.5 verarbeitet Text über das OpenClaw-Gateway; Claude Sonnet 4.5 erhält Bilddaten direkt über Bedrock. AWS begründet den direkten Bildweg mit der konkret beschriebenen OpenClaw-Version im Container, die image_url-Inhaltsteile verworfen habe. Derselbe Persona- und Memory-Prompt werde für beide Wege verwendet.
Wie aus Gesprächen Langzeitgedächtnis wird
AgentCore Memory speichert zunächst Gesprächsereignisse für die laufende Unterhaltung. Daraus extrahiert der Beispielaufbau asynchron Langzeitinformationen mit den Strategien USER_PREFERENCE, SEMANTIC und SUMMARIZATION. Eine neu erwähnte Information kann deshalb erst in einer späteren Sitzung als Langzeiterinnerung abrufbar sein.
Bei einer neuen Anfrage sucht das Beispiel im Langzeitbereich des jeweiligen Telegram-Chats nach passenden Datensätzen. Es kann bis zu 50 Einträge innerhalb eines Abrufbudgets von drei Sekunden berücksichtigen und stellt ausdrücklich genannte Vorlieben vor abgeleiteten Informationen an. Schlägt der Abruf fehl oder dauert er zu lange, kann der Assistent ohne abgerufene Erinnerungen antworten.
Die Namespaces sind im Beispiel nach Telegram-Chat-ID getrennt. Für Sprout heißen sie sprout/{chat_id}/long_term und sprout/{chat_id}/episodic/{session_id}. Indexierte Metadatenfelder sind type, section und plants.
Launch Stack oder eigenes Image?
AWS beschreibt zwei Bereitstellungswege. Der Launch Stack verwendet ein öffentliches ECR-Image; die eigene Image-Route baut und veröffentlicht ein privates ARM64-Image und richtet anschließend den Telegram-Webhook ein.
| Bereitstellungsweg | Image | Voraussetzungen | Beschriebene Schritte |
| CloudFormation Launch Stack | Öffentliches ECR-Image | Zugriff auf AgentCore Runtime und Memory sowie die ausgewählten Bedrock-Modelle; Telegram-Bot-Token | Launch Stack starten und den Bot-Token bereitstellen |
| Eigenes Image | Selbst gebautes linux/arm64-Image, in eine private ECR-Registry übertragen | Zugriff auf AgentCore Runtime und Memory sowie die ausgewählten Bedrock-Modelle; Telegram-Bot-Token; Docker mit linux/arm64-Build-Unterstützung und konfigurierte AWS CLI | scripts/deploy.sh prüft die CloudFormation-Vorlage, baut und überträgt das Image, stellt den Stack bereit und registriert den Telegram-Webhook |
Der Launch Stack ist der kürzere der beiden beschriebenen Wege, weil er ein öffentliches Image nutzt. Der eigene Image-Build ergänzt den Bau- und Übertragungsschritt sowie die Bereitstellung per Skript. Docker und AWS CLI nennt AWS als Anforderungen für genau diesen eigenen Build-Weg.
Betrieb und Bereinigung
Zum beschriebenen Stack gehören S3 für den Workspace, KMS für Verschlüsselung, Secrets Manager für das Telegram-Token sowie CloudWatch für Protokolle und Messwerte. Die Bereinigung umfasst das Löschen des Memory-Speichers und seiner Namespaces. Diese Komponenten und Schritte gehören zum AWS-Beispiel und zeigen, an welchen Stellen Speicherung, Zugangsdaten, Beobachtbarkeit und Entfernung in der Umsetzung liegen.
