Running OpenClaw on Bedrock AgentCore: A Shared AI Assistant for Teams and Families
Forget the Mac Mini under your desk. When AgentCore runs OpenClaw, every family member and every teammate gets their own isolated agent — with enterprise security, pay-per-use economics, and zero infrastructure to maintain.
The Setup Friction Is the Real Problem
Let me tell you what actually happens when someone tries to set up OpenClaw for their team.
Day 1: Buy a Mac Mini. Unbox it. Install Docker. Clone the repo. Spend 45 minutes figuring out why the gateway won't start. Get it running. Connect WhatsApp. It works. You're excited.
Day 3: Your colleague wants to use it too. You add them as a user. Now their conversations are in the same SQLite database as yours. Their scheduled tasks run in the same process as yours. If they ask the agent to do something that crashes it, your tasks stop too.
Day 7: You realize the agent has been running with your Anthropic API key stored in plaintext in
~/.openclaw/openclaw.json. You Google "OpenClaw security" and find the ZeroLeaks report: security score 2/100, prompt injection success rate 91%, 1,800+ exposed instances on the public internet.Day 14: The Mac Mini crashes at 2 AM. Your morning email summary doesn't arrive. You spend 20 minutes SSHing in to restart it.
This isn't a hypothetical. This is the experience that hundreds of developers described on Reddit and Hacker News after the initial excitement wore off. One comment from the HN thread stuck with me: "The setup friction is real. Docker, API keys, channel auth, gateway config." Another: "It's 'n8n but you talk to it' — the concept is right, the deployment model is wrong."
The concept is right. The deployment model is wrong.
AWS Bedrock AgentCore Runtime is the deployment model that makes the concept actually work — for teams, for families, for anyone who wants an AI assistant that's reliable, secure, and doesn't require a home lab.
Let me show you exactly why, starting with the architecture.
The Core Difference: One Process vs. Isolated MicroVMs
This is the most important thing to understand. Everything else follows from it.
When OpenClaw runs on a Mac Mini or EC2 instance, it runs as a single process. All users share that process. All users share the memory. All users share the file system access. All users share the API credentials.
When OpenClaw runs on AgentCore Runtime, each user session gets its own dedicated microVM. Isolated compute. Isolated memory. Isolated file system. Isolated credentials. When the session ends, the microVM is terminated and memory is sanitized.
This isn't a minor implementation detail. It's a fundamentally different security model.
In the single-process model, a prompt injection attack against User B's session can affect User A's data. A bug in one user's task can crash the agent for everyone. A leaked API key compromises every user simultaneously. These aren't theoretical risks — the Asana MCP incident in May 2025 showed exactly this: a logic flaw in session isolation caused one organization's data to appear in another organization's agent responses. The exposure lasted 34 days and affected 1,000 organizations.
In the microVM model, User B's session is physically isolated from User A's. There's no shared memory to contaminate, no shared process to crash, no shared credentials to leak. When User B's session ends, the entire microVM is terminated and sanitized. User A never knew it existed.
For a team or family deployment, this changes everything about what's possible.
The Session Lifecycle: How AgentCore Actually Manages Agent Execution
Understanding the session lifecycle is key to understanding why AgentCore fits agent workloads so well.
A few things worth noting here.
Sessions persist up to 8 hours. This covers essentially every real-world agent workflow. A complex multi-step task — research a topic, draft a document, send it for review, follow up — can run within a single session without losing context.
Idle sessions cost nothing. When the agent is waiting for your next message, the microVM is in Idle state. You're not paying for compute. This is fundamentally different from an EC2 instance or Mac Mini that's burning CPU cycles (and electricity) whether or not anyone is using it.
State is preserved across invocations within a session. This is the key difference from Lambda. If you send three messages in a conversation, each message invocation can access the state from the previous ones — the files the agent created, the intermediate results, the conversation context — without needing to reload everything from a database each time.
Long-term memory survives session termination. When a session ends, the ephemeral state is gone. But AgentCore Memory persists the important stuff — conversation history, user preferences, learned facts — so the next session starts with full context. This is how OpenClaw's "remember everything" capability works in the cloud model.
Why Agent Workloads and Serverless Are Made for Each Other
There's a common assumption that serverless is bad for stateful, long-running workloads. Lambda reinforced this — 15-minute timeout, stateless by design, external state management required for everything.
AgentCore Runtime breaks this assumption. Here's why agent workloads are actually a better fit for serverless than most traditional workloads.
The utilization problem.
A typical AI agent session looks like this:
The agent is actively using CPU for only 18 seconds out of 60. The other 42 seconds it's waiting — for the LLM to respond, for tools to execute, for external APIs to return.
Traditional compute charges you for all 60 seconds. AgentCore Runtime charges you for 18.
AWS ran the math on a customer support agent handling 10,000 sessions per day:
1
2
3
4
5
6
7
8
9
Per session (AgentCore pricing):
CPU: 18s × 1 vCPU × ($0.0895/3600) = $0.000448
Memory: 60s × 2GB avg × ($0.00945/3600) = $0.000315
Total: ~$0.00076 per session
10,000 sessions/day:
AgentCore: $7.60/day = ~$228/month
Traditional (full 60s): $25.30/day = ~$760/month
Savings: 70%For OpenClaw's heartbeat mechanism — the scheduled tasks that check email, monitor prices, send reminders — this is especially elegant. The heartbeat wakes up, does 10 seconds of work, and the microVM terminates. You pay for 10 seconds. Not 24 hours of Mac Mini uptime.
The scaling story.
One Mac Mini handles maybe 2-3 concurrent users before performance degrades. AgentCore scales horizontally by default. 10 users, 100 users, 1,000 users — each gets their own microVM, each gets the same performance. No capacity planning. No over-provisioning. Cost scales linearly with actual usage.
The Full Architecture: How It All Fits Together
Two components. One always-on, one serverless.
The Gateway (EC2, always-on) handles the messaging layer. It receives messages from WhatsApp, Telegram, Slack, Discord — whatever channels you've connected. It does almost no compute: just routing. A c7g.large Graviton ARM instance (~$35/month) is more than enough. No public ports are exposed — access is via SSM Session Manager only.
Why Graviton? AWS Graviton ARM instances cost 20-40% less than equivalent x86 instances and use 60% less energy. For a 24/7 gateway process, that's ~$180/year saved compared to an equivalent x86 instance. The c7g.large at $35/month vs the c5.large at $50/month — same specs, 30% cheaper.
AgentCore Runtime (serverless) handles the actual agent execution. This is where OpenClaw's agent logic runs — in isolated microVMs, with IAM-based Bedrock access, with per-session memory. You pay only when sessions are active.
AgentCore Memory bridges sessions. Short-term memory preserves context within a session. Long-term memory extracts and stores user preferences, learned facts, and conversation summaries that persist across sessions. This is how the agent "remembers" you even after a session terminates.
Real Scenario: A Team of 5 Using OpenClaw in Slack
Let's make this concrete. Here's what a typical morning looks like for a 5-person startup team using OpenClaw on AgentCore.
Notice what's happening here:
- Alice and Bob have completely separate microVMs. Bob's session starting doesn't affect Alice's session at all.
- Both sessions load from AgentCore Memory — so the agent knows Alice prefers bullet summaries and Bob prefers action items format, even though these are different sessions.
- When sessions go Idle, no compute is running. You're not paying for anything.
- Alice's session resumes warm when she sends a second message — no cold start, context preserved.
Now compare this to the Mac Mini model: one process, both users' requests queued, shared memory, shared GitHub credentials. If Alice's PR review crashes the agent, Bob's meeting summary never arrives.
Real Scenario: A Family of 4 — Where Permission Isolation Really Matters
This is the scenario I find most interesting, because it exposes something the Mac Mini model fundamentally can't solve.
With a Mac Mini, all four family members share one agent process. The agent that helps the kids with homework has the same file system access as the agent managing the family's bank account. The agent that reads Parent 1's work emails runs in the same process as the agent that knows the family's financial situation.
This isn't a security paranoia argument. It's a practical one: you can't give the kids' agent shell access without giving it to everyone. You can't restrict the homework agent from seeing financial data without building custom permission logic on top of OpenClaw's architecture.
With AgentCore, each family member's session has its own IAM role with explicitly scoped permissions. The kids' agent literally cannot access financial accounts — not because of application-level checks, but because the IAM role doesn't have those permissions. The microVM doesn't have those credentials. There's nothing to exploit.
This is what the AgentCore Identity
@requires_access_token pattern enables:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
from bedrock_agentcore.identity.auth import requires_access_token
# This function only runs if the session has authorized financial access
async def check_family_budget(*, access_token: str, month: str):
# Kids' sessions never reach this function
# Their IAM role doesn't have family-finance-provider access
...
# This function is available to all family members
async def help_with_homework(subject: str, question: str):
# No special permissions needed
# Safe for kids' sessions
...The permission model is structural, not procedural. You don't write code to check "is this user allowed to do this?" — the infrastructure enforces it before the code even runs.
The Memory Architecture: How the Agent Remembers Across Sessions
One of OpenClaw's core features is persistent memory — the agent remembers your preferences, your history, your context. In the local model, this is SQLite + a vector database on the Mac Mini. Simple, but fragile (what happens when the Mac Mini crashes?).
AgentCore Memory is a managed service that handles this properly.
The key insight: long-term memory extraction happens asynchronously. When you end a conversation, AgentCore Memory processes the session events in the background — extracting facts, preferences, summaries — without adding latency to your real-time interactions.
Next time you start a session, the agent loads your relevant memories before responding. It knows you prefer bullet points. It knows you don't like weekend meetings. It knows the context of the project you were working on last week. All of this survives session termination.
In code, this is what it looks like:
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
31
32
33
34
35
from bedrock_agentcore.memory import MemoryClient
memory_client = MemoryClient(region_name="us-east-1")
# Create memory store with long-term semantic extraction
memory = memory_client.create_memory_and_wait(
name="TeamAssistant",
description="Team member preferences and history",
strategies=[{
"semanticMemoryStrategy": {
"name": "userFacts",
"namespaces": ["/facts/{actorId}"] # Per-user namespace
}
}]
)
# Store a conversation turn
memory_client.create_event(
memory_id=memory.get("id"),
actor_id="alice-123", # Per-user isolation
session_id="session-456",
messages=[
("Can you review PR #234?", "USER"),
("Found 2 issues: SQL injection risk...", "ASSISTANT"),
]
)
# Next session: retrieve relevant memories
memories = memory_client.retrieve_memories(
memory_id=memory.get("id"),
namespace="/facts/alice-123",
query="code review preferences"
)
# Returns: "Alice prefers detailed explanations with line numbers"
# "Alice flags security issues as high priority"Notice the
actor_id — each user's memories are stored in their own namespace. Alice's memories never mix with Bob's. The semantic search only returns memories relevant to the current user's query.Model Economics: Matching the Right Model to the Right Task
One of the biggest advantages of the Bedrock deployment is model flexibility. On a Mac Mini, you're locked into whatever API key you configured. On AgentCore, you can route different tasks to different models based on complexity and cost.
For a team of 10 doing 50 conversations each per day, the model choice is the biggest cost lever:
| Scenario | Model | Daily cost | Monthly cost |
|---|---|---|---|
| All Claude Sonnet | Sonnet 4.5 | ~$83 | ~$2,500 |
| All Nova 2 Lite | Nova 2 Lite | ~$1.67 | ~$50 |
| Smart routing (80% Nova, 20% Sonnet) | Mixed | ~$18 | ~$540 |
| Recommended | Mixed | ~$18 | ~$540 |
The smart routing approach — Nova Lite for routine tasks, Sonnet for complex reasoning — gives you 90% of the quality at 22% of the all-Sonnet cost. The model is a one-parameter change in the CloudFormation deployment. No code changes, no container rebuild.
The Integration Code: Four Lines Is Not a Marketing Claim
The AWS blog says "deploy in four lines of code." I was skeptical. It's actually true.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Your existing OpenClaw agent code — unchanged
from strands import Agent, tool
# ... your tools, your logic, your prompts ...
agent = Agent(
model="us.amazon.nova-lite-v1:0",
system_prompt=SYSTEM_PROMPT,
tools=[your_tools_here]
)
# ↓ The four AgentCore lines ↓
from bedrock_agentcore.runtime import BedrockAgentCoreApp # Line 1: Import
app = BedrockAgentCoreApp() # Line 2: Initialize
# Line 3: Decorate
def invoke(payload):
user_message = payload.get("prompt", "")
response = agent(user_message)
return response.message['content'][0]['text']
if __name__ == "__main__":
app.run() # Line 4: RunEverything else — microVM provisioning, session management, IAM authentication, CloudTrail logging, auto-scaling, health checks — is handled by the runtime. You write agent logic. AWS handles infrastructure.
The deployment flow:
The Real Cost Comparison (With Honest Numbers)
Let me run the actual numbers for three scenarios. I'm including the hidden costs that never show up in the "Mac Mini is cheap" argument.
Scenario A: Solo developer, personal use
| Cost Item | Mac Mini | AgentCore |
|---|---|---|
| Hardware | $599 (amortized $200/yr) | $0 |
| Electricity | $30/yr | $0 |
| API fees (Claude Sonnet) | ~$600/yr | ~$60/yr (Nova Lite) |
| EC2 Gateway | — | ~$420/yr (t4g.small) |
| AgentCore Runtime | — | ~$60/yr (light use) |
| Setup time (3hrs @ $100/hr) | $300 | $150 (1.5hrs) |
| Monthly maintenance (1hr) | $1,200/yr | ~$0 |
| Year 1 total | ~$2,930 | ~$690 |
For solo use, the Mac Mini looks cheaper on paper until you count your own time. If you value your time at all, the cloud model wins from day one.
Scenario B: Team of 10, shared agent
| Cost Item | Mac Mini | AgentCore |
|---|---|---|
| Hardware | $599 | $0 |
| API fees (10 users, mixed models) | ~$2,500/mo | ~$540/mo |
| EC2 Gateway | — | $35/mo |
| AgentCore Runtime | — | $50/mo |
| Security setup + ongoing | $3,000/yr (est.) | $0 |
| Incident response (1 breach) | $5,000+ (est.) | $0 |
| Year 1 total | ~$38,000 | ~$8,700 |
The API fee difference alone is $23,520/year. The security incident estimate is conservative — the Asana MCP breach affected 1,000 organizations and required emergency remediation.
Scenario C: Family of 4
| Cost Item | Mac Mini | AgentCore |
|---|---|---|
| Hardware | $599 | $0 |
| API fees (4 users, light use) | ~$100/mo | ~$20/mo |
| EC2 Gateway | — | $12/mo (t4g.small) |
| AgentCore Runtime | — | $10/mo |
| Permission isolation | Not possible | Built-in |
| Monthly ongoing | ~$108 | ~$42 |
For a family, the cost difference is modest. The real difference is the permission model — which the Mac Mini simply cannot provide.
OpenClaw Will Find Its Balance: The Permission Evolution
Here's something worth saying directly, because most articles skip it: OpenClaw isn't done evolving.
The current version has a fundamental tension. Its power comes from broad capabilities — shell access, file system, browser control. Its security problem comes from the same place. The community knows this. The ZeroLeaks score of 2/100 isn't a permanent state. It's a snapshot of a project that prioritized capability and growth over security hardening. That was the right call for a weekend project that became a phenomenon. It's not the right call for production.
The interesting question is where OpenClaw finds its balance point. My read: toward explicitly scoped, user-authorized capabilities rather than globally available ones.
The
@requires_access_token pattern from AgentCore Identity is a preview of what principled capability scoping looks like: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
from bedrock_agentcore.identity.auth import requires_access_token
# GitHub access — only for users who've authorized it
async def review_pull_request(*, access_token: str, pr_url: str):
# This function is unreachable for sessions without GitHub auth
# The token is scoped to exactly repo:read — nothing more
...
# Shell access — only for developer-role sessions
async def run_build_command(*, access_token: str, command: str):
# Kids' sessions, PM sessions, designer sessions never reach here
...
# Available to everyone — no special auth needed
async def summarize_document(text: str) -> str:
# Safe for all users, all contexts
...This is the architecture that makes OpenClaw safe for teams and families. Not "we try hard to prevent misuse" — but "the infrastructure makes misuse structurally impossible."
The community is already moving in this direction. Cloudflare's Moltworker uses Zero Trust Access and Sandboxes. The AgentCore deployment adds microVM isolation and IAM-scoped credentials. These aren't competing approaches — they're the same insight at different layers. AgentCore just happens to be the most complete implementation of it today.
Getting Started: 10-15 Minutes to a Running Team Agent
The full CloudFormation templates and deployment guide are at aws-samples/sample-OpenClaw-on-AWS-with-Bedrock .
Prerequisites:
- AWS CLI configured (
aws configure) - Docker installed and running
- EC2 Key Pair in your target region
- Bedrock model access enabled in the console (request Nova 2 Lite + Claude Sonnet 4.5)
Step 1: Build and push the agent container
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Set your account ID
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=us-east-1
# Build the OpenClaw agent container
cd openclaw
docker build -f agent/Dockerfile -t openclaw-agentcore-agent:latest .
# Push to ECR
aws ecr get-login-password --region $REGION | \
docker login --username AWS --password-stdin \
${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com
docker tag openclaw-agentcore-agent:latest \
${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com/openclaw-agentcore-agent:latest
docker push \
${ACCOUNT_ID}.dkr.ecr.${REGION}.amazonaws.com/openclaw-agentcore-agent:latestStep 2: Deploy the full stack
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
aws cloudformation create-stack \
--stack-name openclaw-agentcore \
--template-body file://clawdbot-bedrock-agentcore.yaml \
--capabilities CAPABILITY_NAMED_IAM \
--region $REGION \
--parameters \
ParameterKey=KeyPairName,ParameterValue=your-key-pair \
ParameterKey=InstanceType,ParameterValue=c7g.large \
ParameterKey=OpenClawModel,ParameterValue=global.amazon.nova-2-lite-v1:0 \
ParameterKey=EnableAgentCore,ParameterValue=true \
ParameterKey=CreateVPCEndpoints,ParameterValue=true
# Wait for completion (~10 minutes)
aws cloudformation wait stack-create-complete \
--stack-name openclaw-agentcore --region $REGIONStep 3: Access via SSM (no public ports)
1
2
3
4
5
6
7
8
9
10
11
# Get instance ID from stack outputs
INSTANCE_ID=$(aws cloudformation describe-stacks \
--stack-name openclaw-agentcore \
--query 'Stacks[0].Outputs[?OutputKey==`InstanceId`].OutputValue' \
--output text --region $REGION)
# Start port forwarding tunnel
aws ssm start-session \
--target $INSTANCE_ID \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["18789"],"localPortNumber":["18789"]}'Open
http://localhost:18789 in your browser. Connect your messaging channels from the UI. Done.Step 4: Connect your team
From the Gateway UI, add each team member as a user with their own permission scope. Connect WhatsApp, Telegram, or Slack. Each user's sessions will run in isolated microVMs automatically — no additional configuration needed.
The Honest Tradeoffs
This isn't a "cloud always wins" argument. There are real reasons to keep running OpenClaw locally.
Local LLMs are a genuine advantage. The Mac Mini community running Llama or Qwen3 locally gets something AgentCore can't offer: inference with zero API costs and zero data leaving the device. For privacy-sensitive personal use cases where you want the model on-premises, local wins.
Full hardware access has legitimate uses. AgentCore's sandboxed execution is a security feature, but it's also a constraint. If your workflow requires deep OS-level access — managing hardware peripherals, accessing local network devices, running GUI applications — the cloud model adds friction.
Data sovereignty is real. If you're in healthcare, finance, or government with strict data residency requirements, even VPC-isolated cloud deployment may not satisfy compliance. Local deployment keeps data on-premises by definition.
The honest recommendation: use local deployment for personal, privacy-sensitive, or local-LLM use cases. Use AgentCore for team deployments, family deployments with mixed trust levels, and anything that needs to be reliable, secure, and maintainable without a home lab.
The Bottom Line
The Mac Mini moment proved something important: people want proactive AI agents badly enough to buy hardware and spend hours configuring Docker. That's a strong signal. The concept is right.
But the deployment model was always the bottleneck. One process, shared permissions, plaintext API keys, DIY security — this doesn't scale to teams, doesn't handle mixed trust levels in families, and doesn't survive contact with a motivated attacker.
AgentCore Runtime changes the architecture, not just the hosting. MicroVM isolation per session. IAM-scoped credentials per user. Pay-per-use economics that make team deployments affordable. A memory system that persists across sessions without requiring you to manage a database. A compliance story that enterprise security teams can actually accept.
OpenClaw will keep evolving. The capability set will grow. The permission model will get more sophisticated. The community will build more Skills, more integrations, more use cases. The infrastructure question — how do you run this safely, at scale, for multiple users with different trust levels — has an answer now.
The agent paradigm is right. The infrastructure is ready.
References
- aws-samples/sample-OpenClaw-on-AWS-with-Bedrock — CloudFormation templates and full deployment guide
- Introducing Amazon Bedrock AgentCore — AWS News Blog
- Securely launch and scale your agents on AgentCore Runtime — AWS ML Blog
- AgentCore Runtime Documentation
- Introducing Moltworker — Cloudflare Blog
- AWS Graviton pricing
- Amazon Bedrock Pricing
- r/ArtificialIntelligence: "unpopular opinion: you shouldn't need to buy a mac mini just to run a functional ai agent"
- r/aiagents: "The creator of Openclaw got hired by OpenAI. Here's why that's inspiring"
- Asana MCP cross-tenant incident, May 2025 — cited in AgentCore Runtime ML Blog
A Note of Thanks
This article wouldn't exist without the work of @Vivek0712 , who authored and tested the entire AgentCore deployment — the CloudFormation template, the containerized agent setup, the README, and every line of code you saw in this post. He validated it end-to-end on AWS, from Gateway configuration to AgentCore Runtime execution to messaging channel integration. That's the kind of contribution that turns a concept into something you can actually deploy in 15 minutes.
The PR is merged and live: aws-samples/sample-OpenClaw-on-AWS-with-Bedrock/pull/16 .
If this got you thinking — about new deployment scenarios, better permission models, additional messaging channels, cost optimizations, or anything else — the repo is open and contributions are very welcome. The AgentCore pattern is new territory for the OpenClaw community, and there's a lot of ground left to explore.
Open an issue, submit a PR, or just star the repo if you found it useful. The more people building on this, the better it gets.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article