Summary
OpenClaw currently serves its gateway protocol via WebSocket on port 18789. To deploy on Amazon Bedrock AgentCore Runtime, a separate HTTP adapter process is required as a sidecar because AgentCore expects:
POST /invoke → agent invocation (returns JSON or SSE stream)
GET /ping → health check returning {"status": "Healthy"}
- HTTP server on port
:8080
This feature request proposes a native AgentCore mode so OpenClaw can be deployed directly on AgentCore Runtime as a single process.
Proposed Solution
A new gateway mode that serves the AgentCore HTTP contract directly:
openclaw gateway --mode agentcore
# or
openclaw serve --agentcore-runtime
This would:
- Start a Fastify server on
:8080 (configurable) implementing the AgentCore Runtime protocol
- Expose
POST /invoke → runs an embedded agent turn with full tool/memory/MCP access
- Expose
GET /ping → returns {"status": "Healthy"}
- Optionally expose
GET /ws → WebSocket for streaming
- Use the local OpenClaw workspace, config, memory, and skills as context
- Single process, no sidecar gateway needed
Current Workaround
Today this requires a 2-process sidecar pattern:
- Process 1:
openclaw gateway (WebSocket on :18789)
- Process 2: Strands/custom HTTP handler on
:8080 using GatewayClient from openclaw/plugin-sdk/gateway-runtime to bridge
Sample implementation: https://github.com/wirjo/sample-strands-openclaw
Context
- AgentCore SDK:
bedrock-agentcore uses BedrockAgentCoreApp (Fastify-based) with invocationHandler.process()
- NemoClaw precedent: NVIDIA/NemoClaw already integrates OpenClaw as a binary with
openclaw gateway run + health probe — native AgentCore support would be the AWS-native complement
- Embedded engine exists:
runEmbeddedPiAgent from openclaw/extension-api can run agent turns in-process, but is deprecated/internal with no stability guarantees
- Strands SDK: The Strands Agents SDK is the primary TypeScript framework for AgentCore deployments
Alternative: Stable Embedded API
If a full HTTP mode is too heavy, a stable public API for in-process agent invocation would also solve this:
import { createAgent } from "openclaw/embedded"; // hypothetical stable API
const agent = await createAgent({ workspace: "/app/.openclaw" });
const result = await agent.invoke("Analyze this data");
// → { reply: "...", usage: {...}, sessionId: "..." }
This would let any HTTP framework (Fastify, Express, Strands) wrap OpenClaw without needing a running gateway daemon.
Environment
- OpenClaw version: 2026.4.15+
- AgentCore SDK: bedrock-agentcore@0.4.0
- Node.js: 22+
- Platform: Linux (AgentCore microVM)
Summary
OpenClaw currently serves its gateway protocol via WebSocket on port 18789. To deploy on Amazon Bedrock AgentCore Runtime, a separate HTTP adapter process is required as a sidecar because AgentCore expects:
POST /invoke→ agent invocation (returns JSON or SSE stream)GET /ping→ health check returning{"status": "Healthy"}:8080This feature request proposes a native AgentCore mode so OpenClaw can be deployed directly on AgentCore Runtime as a single process.
Proposed Solution
A new gateway mode that serves the AgentCore HTTP contract directly:
openclaw gateway --mode agentcore # or openclaw serve --agentcore-runtimeThis would:
:8080(configurable) implementing the AgentCore Runtime protocolPOST /invoke→ runs an embedded agent turn with full tool/memory/MCP accessGET /ping→ returns{"status": "Healthy"}GET /ws→ WebSocket for streamingCurrent Workaround
Today this requires a 2-process sidecar pattern:
openclaw gateway(WebSocket on:18789):8080usingGatewayClientfromopenclaw/plugin-sdk/gateway-runtimeto bridgeSample implementation: https://github.com/wirjo/sample-strands-openclaw
Context
bedrock-agentcoreusesBedrockAgentCoreApp(Fastify-based) withinvocationHandler.process()openclaw gateway run+ health probe — native AgentCore support would be the AWS-native complementrunEmbeddedPiAgentfromopenclaw/extension-apican run agent turns in-process, but is deprecated/internal with no stability guaranteesAlternative: Stable Embedded API
If a full HTTP mode is too heavy, a stable public API for in-process agent invocation would also solve this:
This would let any HTTP framework (Fastify, Express, Strands) wrap OpenClaw without needing a running gateway daemon.
Environment