Rebuilding OpenClaw on AWS: Why Identity-Driven Agents Are the Way Forward
How we mapped OpenClaw's identity files, two-tier memory, and heartbeat scheduling onto S3, AgentCore Memory, EventBridge, and AgentCore Runtime — building a persistent, self-evolving AI agent entirely on AWS managed services with a single `cdk deploy`
Ever since OpenClaw launched, I've been playing around with it. Not because it's the most polished agent framework out there — it's not trying to be. But because it shows you what good looks like.
Most agent projects obsess over the tool-calling loop. OpenClaw obsesses over everything else: how context should be managed across sessions, how an agent should maintain a consistent personality without you re-prompting it every time, how memory should be structured so the agent actually gets better the more you use it, and how an agent should be able to act on its own without waiting for you to type something.
That's what makes it powerful. It's not a framework — it's a reference architecture for what agents should be. It stores personality in Markdown files, keeps memories in SQLite, and runs a heartbeat loop so the agent can act on its own schedule. The result is an agent that feels persistent — it remembers you, evolves its self-conception, and doesn't just respond to prompts but lives between them.
The more I dug into it, the more I realized: this pattern — identity files, two-tier memory, proactive scheduling, extensible tools — maps cleanly onto AWS managed services. And when you make that mapping, you get something that scales, persists, and extends without any infrastructure to manage.
This post walks through how we took OpenClaw's core ideas and rebuilt them on S3, AgentCore Memory, AgentCore Runtime, EventBridge Scheduler, and Bedrock. No databases. No embedding pipelines. No servers. One
cdk deploy and you're running.Why the OpenClaw Pattern Matters
Most agent frameworks focus on the loop: receive prompt → think → call tools → respond. OpenClaw adds three things that change the game:
- Identity as configuration. The agent's personality, instructions, and self-conception live in editable Markdown files. Change
SOUL.mdand the agent behaves differently. No redeployment needed. The agent can even update its ownIDENTITY.mdas it learns who it is. - Memory that outlives sessions. Short-term conversation context is expected. But OpenClaw also maintains durable memory — facts it's learned, user preferences, curated knowledge — that persists across sessions and shapes future interactions.
- Proactive behavior. The agent doesn't just wait for prompts. It has a heartbeat — a scheduler that triggers it to check on things, send reminders, and act autonomously. This is the difference between a chatbot and an assistant.
These aren't features. They're an architecture. And they map cleanly onto AWS managed services.
The Architecture
The Gradio UI is just a test harness. The agent runs on AgentCore Runtime and exposes a standard
invoke_agent_runtime API — any client can call it. Slack, Teams, a mobile app, a CLI, a custom web frontend — anything that can make an HTTP request can talk to this agent. The architecture is client-agnostic by design.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
┌──────────────┐
│ Gradio UI │◄──── polls SQS for 🔔
└──────┬───────┘
│ invoke
▼
┌─────────────────────┐
│ AgentCore Runtime │ (container on AWS)
│ Strands Agent + │
│ 7 tools │
└──┬──────┬───────┬──┘
│ │ │
┌────────┘ │ └────────┐
▼ ▼ ▼
┌──────────┐ ┌────────────┐ ┌─────────────────┐
│ S3 │ │ AgentCore │ │ EventBridge │
│ Identity │ │ Memory │ │ Scheduler │
│ Tasks │ │ STM + LTM │ └────────┬────────┘
│ Schedules│ └────────────┘ │ cron
└──────────┘ ▼
┌──────────────┐
┌────────────┐ │ Lambda │
│ Bedrock │ └──────┬───────┘
│ Claude 4 │ │
└────────────┘ ▼
┌──────────────┐
┌────────────┐ │ SQS │──► UI
│ AgentCore │ └──────────────┘
│ Gateway │
│ (future) │
└────────────┘Every box in the bottom half is a managed AWS service. The agent code is pure Python — Strands Agents SDK for the framework, Pydantic for data models, CDK for infrastructure.
Mapping 1: Identity — Local Filesystem → S3
OpenClaw stores personality in "Sacred Text" files on the local filesystem. We moved them to S3:
1
2
3
4
5
s3://{bucket}/agents/{agent_id}/SOUL.md ← Core personality (required)
s3://{bucket}/agents/{agent_id}/AGENTS.md ← Tool instructions (required)
s3://{bucket}/agents/{agent_id}/IDENTITY.md ← Self-conception (agent updates this)
s3://{bucket}/agents/{agent_id}/USER.md ← What it knows about you (dynamic)
s3://{bucket}/agents/{agent_id}/MEMORY.md ← Curated knowledge (dynamic)S3 versioning means if the agent corrupts its own files, you roll back. Conditional writes via ETag give conflict detection for concurrent sessions. The same bucket stores identity files, task data, and schedule metadata — one resource, three use cases, zero databases.
The agent has tools to update its own identity:
update_identity, update_user_profile, and save_to_memory. It literally rewrites its own personality files as it learns. That's the OpenClaw pattern — the agent isn't static, it evolves.Mapping 2: Memory — SQLite + Embeddings → AgentCore Memory
OpenClaw maintains two-tier memory: ephemeral daily logs and durable curated knowledge, backed by SQLite with custom embedding pipelines.
AgentCore Memory maps directly:
| OpenClaw Concept | AgentCore Strategy |
|---|---|
| Daily conversation logs | Short-Term Memory (STM) |
| Session summaries | summaryMemoryStrategy |
| User preferences | userPreferenceMemoryStrategy |
| Curated facts | semanticMemoryStrategy |
At session end, we call
flush_to_ltm() and AgentCore automatically runs summary extraction, preference detection, and semantic indexing. No SQLite. No embedding pipeline. No vector search infrastructure.The
MemoryManager degrades gracefully — if AgentCore Memory is unreachable, the agent falls back to in-memory conversation history with exponential backoff retries. It keeps working, just without persistence.Mapping 3: Scheduling — HEARTBEAT.md → EventBridge + Lambda + SQS
This is where the architecture gets interesting.
OpenClaw uses a
HEARTBEAT.md file and a local gateway that pings the agent every 30 minutes. We replaced that with EventBridge Scheduler — but with a twist.EventBridge can't directly invoke AgentCore Runtime (it's not a supported target yet). So we built a Lambda bridge:
1
2
3
4
5
User: "remind me every 2 minutes to stretch"
→ Agent calls schedule_task tool
→ Creates EventBridge Scheduler cron rule (targets Lambda)
→ Every 2 minutes: Lambda fires, sends task to SQS
→ Gradio UI polls SQS, shows 🔔 notificationThe key improvement over OpenClaw: users create schedules through natural conversation. "Remind me about standup every weekday at 9am" creates a real
cron(0 9 ? * MON-FRI *) EventBridge rule. No config files. No fixed intervals. The agent manages its own schedule.The Lambda is 30 lines of code. SQS decouples notification delivery. Schedule names are prefixed with
agent_id to prevent collisions across agents. The whole pattern costs essentially nothing.Mapping 4: Deployment — Local Process → AgentCore Runtime
OpenClaw runs as a local Python process. We containerized it with the
BedrockAgentCoreApp pattern and deploy to AgentCore Runtime via CDK:1
2
3
4
5
6
7
8
9
10
app = BedrockAgentCoreApp()
def invoke(payload):
_config, orchestrator, heartbeat_handler = _build_components(payload["agent_id"])
if payload.get("type") == "heartbeat":
return heartbeat_handler.handle_heartbeat(payload)
handle = orchestrator.create_agent(payload["agent_id"], payload["user_id"])
response = orchestrator.handle_message(handle, payload["message"])
return {"status": "completed", "output": response}CDK builds the Docker image, pushes to ECR, and deploys — all in one command. The Gradio UI connects to the deployed runtime via
invoke_agent_runtime, so you're always testing the real agent, not a local mock.Mapping 5: Model Selection → Intelligent Prompt Routing
Not every message needs Claude Sonnet. "What's on my task list?" doesn't require the same model as "help me design a distributed caching layer."
The
ModelRouter supports Bedrock Intelligent Prompt Routing as a drop-in replacement for the model ID. The router ARN goes where the model ID would — Bedrock decides Sonnet vs Haiku per request. Estimated 30-50% cost reduction for typical assistant workloads, zero code changes.Extending the Agent: AgentCore Gateway as Hands
Here's where the OpenClaw pattern really shines. The agent currently has 7 built-in tools (tasks, schedules, identity, memory, time). But what if it needs to check the weather? Query a database? Call an external API?
AgentCore Gateway gives the agent extensible hands through MCP (Model Context Protocol). You create a Gateway, add targets — Lambda functions, OpenAPI endpoints, Smithy models — and the agent discovers and uses them automatically:
1
2
3
4
5
AgentCore Gateway (MCP endpoint)
├── Lambda target: "check-weather" → Your weather Lambda
├── OpenAPI target: "jira-api" → Jira REST API
├── Smithy target: "dynamodb" → DynamoDB operations
└── Lambda target: "send-email" → SES email senderEach target becomes a tool the agent can call. The Gateway handles authentication, scaling, and discovery. You don't modify the agent code — you add capabilities by adding Gateway targets.
This is the OpenClaw philosophy taken further: the agent's capabilities aren't hardcoded, they're configured. Just like
SOUL.md defines personality and AGENTS.md defines behavior, Gateway targets define what the agent can do. Add a target, and the agent gains a new ability.The agent could even create its own tools — a Lambda that writes and deploys new Lambda targets to its own Gateway. Self-extending agents, configured through conversation.
What OpenClaw Taught Us About Building Agents
We didn't set out to clone OpenClaw. We set out to understand what makes an agent feel like more than a chatbot — and OpenClaw gave us the blueprint.
Most agent tutorials start and end with the tool-calling loop. OpenClaw showed us that the loop is the easy part. What matters is everything around it: the identity that gives the agent a consistent voice, the memory that lets it build a relationship with you over time, and the heartbeat that turns it from a reactive tool into a proactive assistant.
These aren't OpenClaw-specific ideas. They're what any serious agent needs. OpenClaw just made them explicit — Markdown files you can read, edit, and version control. That clarity is what made it possible to map the whole thing onto managed services.
The mapping isn't one-to-one. We didn't replicate OpenClaw's SQLite schema or its gateway protocol. We took the concepts — identity as configuration, two-tier memory, proactive scheduling, self-evolving personality — and asked: what's the simplest AWS architecture that preserves all of these properties?
The answer turned out to be surprisingly clean. S3 for identity. AgentCore Memory for the brain. EventBridge for the calendar. Lambda and SQS for the notification plumbing. AgentCore Runtime for deployment. AgentCore Gateway for extensibility. Bedrock for reasoning.
One
cdk deploy. No databases. No servers. No embedding pipelines.If you're building agents and they don't have identity, memory, and agency — you're building chatbots. OpenClaw showed us the difference. AWS managed services made it practical.
Try It
The full source code is at https://github.com/lusoal/openclaw-redesign-awsbedrock.
1
2
3
4
5
6
git clone https://github.com/lusoal/openclaw-redesign-awsbedrock.git
cd openclaw-redesign-awsbedrock
pip install -e ".[dev,infra]"
cd infra && cdk deploy
# Upload identity files to S3, then:
python chat_ui.py --agent-id my-agentFork it, change
SOUL.md, and make it yours.Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article