agent-claw/compatibility-analysis.md

Component-by-Component Compatibility Analysis

🔴 Incompatible (fundamental architecture mismatch)

1. Gateway (Long-Lived Daemon)

OpenClaw: Single always-on process that multiplexes WS server + HTTP + channel connections. AgentCore: Container is invoked per-request/session, idle-killed at 15min, max 8hr. Verdict: 🔴 Cannot run as-is. The Gateway assumes it's a long-running daemon. AgentCore will kill it after 15 minutes of no inbound invocations. Even if you keep it warm with pings, the 8-hour max session kills any long-running process.

2. Channel Connections (WhatsApp, Discord, Telegram, etc.)

OpenClaw: Maintains persistent outbound WebSocket/polling connections to each messaging service. WhatsApp (Baileys) requires a persistent session with auth state. Discord uses a persistent gateway WebSocket. AgentCore: Ephemeral sessions. No persistent outbound connections survive session termination. Verdict: 🔴 Fundamentally incompatible. WhatsApp's Baileys library maintains a stateful WebSocket with auth keys that must persist. Discord.js maintains a real-time gateway connection. These cannot be started/stopped per request — they need to be always-on or you lose the connection and have to re-auth.

3. Filesystem Persistence (Session Transcripts, Config, Workspace)

OpenClaw: Stores everything on local filesystem — session JSONL files, config, WhatsApp auth state, pairing store, agent workspace (MEMORY.md, daily notes), secrets. AgentCore: Filesystem is ephemeral. Destroyed when session terminates. Verdict: 🔴 All persistent state must be externalized. Every file that OpenClaw writes and expects to read later would need to be backed by S3, DynamoDB, or AgentCore Memory.

4. Shell Exec / PTY (Agent Tool)

OpenClaw: The exec tool spawns real shell processes, supports PTY for interactive commands, runs coding agents (Codex, Claude Code) as child processes. AgentCore: Runs inside a container, so basic exec is possible, but:

• No host-level access
• Container filesystem is ephemeral
• PTY support depends on container config
• Long-running background processes die with session (15min idle / 8hr max) Verdict: 🟡 Partially possible. Basic shell commands work in containers. But coding agent subprocesses that run for extended periods will be killed. No access to host-level tools.

5. Heartbeat System

OpenClaw: Gateway-driven timer that fires periodic agent turns in the main session (default every 30m). Relies on the gateway being continuously running. AgentCore: No built-in periodic task scheduler. Container only runs when invoked. Verdict: 🔴 Must be offloaded. Would need EventBridge Scheduler or a Lambda cron to periodically invoke the agent. The heartbeat logic itself could run, but the trigger mechanism must be external.

6. Cron Jobs

OpenClaw: Built-in cron scheduler (croner library) that runs inside the gateway process. AgentCore: No built-in scheduler. Verdict: 🔴 Must be offloaded. Same as heartbeat — EventBridge Scheduler → InvokeAgentRuntime.

---

🟡 Partially Compatible (needs adaptation)

7. Agent Runtime (Pi-Mono)

OpenClaw: Embedded pi-mono agent runtime with RPC-based tool calling, streaming, and multi-turn sessions. AgentCore: Expects your container to implement /invocations (POST) and /ping (GET). Returns JSON or SSE. Verdict: 🟡 Core agent loop could work. The pi-mono agent runtime could be wrapped behind the AgentCore HTTP contract. The tool-calling loop would need to be adapted to the HTTP request/response pattern instead of internal RPC. The main challenge is the session model (see below).

8. Session Management

OpenClaw: Sessions are long-lived, stored as JSONL, persist indefinitely. The "main session" for a user is eternal and accumulates context over days/weeks. AgentCore: Sessions max 8 hours. State is ephemeral. Cross-session continuity requires AgentCore Memory or external storage. Verdict: 🟡 Needs redesign. Could use AgentCore Memory for cross-session context, but OpenClaw's JSONL-based session model (with compaction) would need to be completely rewritten to use AgentCore Memory or a database.

9. Browser Tool (Playwright)

OpenClaw: Launches a managed Chromium instance via Playwright, controls via CDP. AgentCore: Containers can run headless browsers, but:

• ARM64 container (Chromium ARM builds exist)
• Ephemeral — browser state lost on session end
• Network access needed for web browsing (VPC + NAT or default internet) Verdict: 🟡 Possible but fragile. Headless Chrome can run in containers, but you need the right base image, enough memory, and network egress. Browser sessions won't persist. AgentCore actually has a built-in Browser Tool you might use instead.

10. Web Search / Web Fetch

OpenClaw: Makes HTTP requests to Brave Search API, fetches web pages. AgentCore: Outbound HTTP works fine (with internet access via VPC+NAT or default). Verdict: 🟢 Compatible. Just needs outbound internet access.

11. TTS (Text-to-Speech)

OpenClaw: Calls external TTS APIs (ElevenLabs, Edge TTS, etc.) AgentCore: Outbound API calls work fine. Verdict: 🟢 Compatible.

12. LLM Provider Calls

OpenClaw: Calls Bedrock, Anthropic, OpenAI, etc. via HTTP APIs. AgentCore: Outbound API calls work. Bedrock calls can use IAM roles. Verdict: 🟢 Compatible, and potentially better. Bedrock calls from AgentCore can use the execution role directly — no API keys needed.

---

🟢 Compatible (works as-is or with minimal changes)

13. Model Provider Abstraction

The model routing/failover/selection logic is pure application code — works anywhere.

14. System Prompt Construction

Building system prompts from workspace files is pure logic — works anywhere (but workspace files need external storage).

15. Context Engine (Compaction, Pruning)

Session compaction/pruning logic is algorithmic — works in any runtime. But needs adapted storage backend.

---

Node / Platform Features (N/A for AgentCore)

These features are inherently tied to physical devices and cannot run on AgentCore:

• macOS app (menu bar, Voice Wake, Talk Mode)
• iOS/Android nodes (camera, screen, location, voice)
• iMessage (requires macOS + Messages.app)
• Signal (requires signal-cli subprocess)
• Canvas (visual workspace rendered on client device)
• Bonjour discovery (LAN-based device pairing)
• WhatsApp QR pairing (requires interactive QR scan flow)

These would remain on the user's device, connecting to an AgentCore-hosted agent via API.