Summary
We propose adding an External Memory Provider API to OpenClaw that enables zero-downtime context compaction by delegating memory management to an external system. This eliminates the current 30-60 second agent blackout during compaction — reducing it to <100ms with zero perceived downtime.
Problem
When an OpenClaw agent's context window fills up, the platform performs synchronous in-band compaction:
- Agent stops responding
- Entire context is sent to an LLM for summarization
- Summary replaces the original context
- Agent resumes with degraded memory
Impact: 30-60s blackout, information loss, no audit trail, unpredictable timing. For production use cases (customer support, financial services, healthcare) this is a dealbreaker.
Proposed Solution: Hot-Swap Context with External Memory Provider
┌──────────────────────────────────────────┐
│ OpenClaw Agent │
│ Context Slot A (active) ←→ Slot B │
│ ↕ ↕ │
│ ┌────────────────────────────────┐ │
│ │ Memory Provider Interface │ │
│ └──────────┬─────────────────────┘ │
└─────────────┼────────────────────────────┘
▼
┌─────────────────────────────┐
│ External Memory Provider │
│ • Continuous async sync │
│ • Background compression │
│ • Pre-built context ready │
│ • Full audit trail │
└─────────────────────────────┘
How It Works
- Continuous Sync — Every message written to memory provider async (fire-and-forget, local socket, ~1ms)
- Background Compression — Provider maintains compressed context summary, updated asynchronously (cheap local model)
- Atomic Swap — At capacity, OpenClaw reads pre-built context from provider (~50ms), swaps in inter-message gap
- On-Demand Recall — Agent queries provider for older details via tool call (~10-50ms)
Proposed API
interface MemoryProvider {
// Fire-and-forget after each message (async, not in critical path)
onMessage(sessionId: string, message: Message): Promise<void>;
// Returns pre-built compressed context (maxChars as model-agnostic approx)
getCompressedContext(sessionId: string, maxChars: number): Promise<CompressedContext>;
// On-demand recall tool
recall(sessionId: string, query: string, limit?: number): Promise<MemoryEntry[]>;
ping(): Promise<{ ok: boolean; latencyMs: number }>;
}
Lifecycle Hooks
interface SessionHooks {
'pre-compaction': (session: Session) => Promise<void>;
'post-compaction': (session: Session, newContext: CompressedContext) => Promise<void>;
'session-start': (session: Session) => Promise<CompressedContext | null>; // Cold-start recovery
'session-end': (session: Session) => Promise<void>;
}
Configuration
{
"memory": {
"provider": "uaml", // or "builtin" (default, backward compatible)
"endpoint": "http://localhost:8770",
"compaction": {
"strategy": "hot-swap", // "hot-swap" | "builtin"
"threshold": 0.85,
"targetSize": 0.40
}
}
}
Performance Comparison
| Metric |
Current (builtin) |
With Memory Provider |
| Compaction duration |
30-60s |
<100ms |
| Agent downtime |
30-60s |
0 (between messages) |
| Information loss |
Significant |
None (full DB) |
| Audit trail |
None |
Complete |
| Cost per compaction |
~$0.10-0.50 |
~$0.001 (async local) |
Edge Cases & Error Handling
- Message during swap: Swap occurs in inter-message gap; incoming messages queued during ~100ms swap
- Provider failure: Fallback to builtin compaction (graceful degradation, never block agent)
- Cold start:
session-start hook enables context reconstruction from historical data
Security
- Memory provider runs locally by default (localhost/Unix socket)
- Remote providers require TLS + auth token
- Provider must respect session/agent data isolation
Backward Compatibility
- Default behavior unchanged — builtin compaction remains default
- Memory provider is opt-in via configuration
- Existing sessions unaffected
Reference Implementation
We have a working memory system (UAML Memory) that provides sub-100ms local recall, temporal reasoning, provenance tracking, and MCP compatibility. We're ready to build the OpenClaw adapter once the Provider API is defined.
GitHub: github.com/uaml-memory/uaml
Proposed Phased Roadmap
| Phase |
What |
Est. Timeline |
| 1 |
pre/post-compaction hooks |
1-2 weeks |
| 2 |
Memory Provider Interface |
2-3 weeks |
| 3 |
Hot-swap compaction strategy |
3-4 weeks |
| 4 |
Background sync + config + docs |
2-3 weeks |
Phase 1 alone would already enable external memory integration and demonstrate value.
We're happy to contribute to the implementation. This could transform OpenClaw from a powerful hobby tool into an enterprise-grade agent platform.
Summary
We propose adding an External Memory Provider API to OpenClaw that enables zero-downtime context compaction by delegating memory management to an external system. This eliminates the current 30-60 second agent blackout during compaction — reducing it to <100ms with zero perceived downtime.
Problem
When an OpenClaw agent's context window fills up, the platform performs synchronous in-band compaction:
Impact: 30-60s blackout, information loss, no audit trail, unpredictable timing. For production use cases (customer support, financial services, healthcare) this is a dealbreaker.
Proposed Solution: Hot-Swap Context with External Memory Provider
How It Works
Proposed API
Lifecycle Hooks
Configuration
Performance Comparison
Edge Cases & Error Handling
session-starthook enables context reconstruction from historical dataSecurity
Backward Compatibility
Reference Implementation
We have a working memory system (UAML Memory) that provides sub-100ms local recall, temporal reasoning, provenance tracking, and MCP compatibility. We're ready to build the OpenClaw adapter once the Provider API is defined.
GitHub: github.com/uaml-memory/uaml
Proposed Phased Roadmap
pre/post-compactionhooksPhase 1 alone would already enable external memory integration and demonstrate value.
We're happy to contribute to the implementation. This could transform OpenClaw from a powerful hobby tool into an enterprise-grade agent platform.