Skip to content

Conversation Summary for Next Session

User intent

  • Learn OpenClaw from a technical architecture perspective.
  • Wants concise, precise answers with diagrams/examples only when useful.
  • Prefers understanding of processing chain, component handoffs, state handling, memory, and context limits.

Key topics discussed

  • OpenClaw end-to-end flow: external inputs -> Gateway -> channel parsing -> access control -> session resolution -> context assembly -> LLM call -> tool execution -> response.
  • Clarified that "incoming events" can come from channels, webhooks, cron, and MCP triggers.
  • Gateway vs Channel Adapter:
  • Gateway routes raw events to the correct adapter.
  • Channel Adapter normalizes platform-specific payloads into internal event schema and enriches metadata.
  • Event-driven loop details:
  • Access control checks sender/channel permissions.
  • Session resolution computes session ID and loads per-session state.
  • Context assembly builds prompt from recent messages, memory, and files.
  • LLM may emit tool calls; tools run; results can feed back into LLM.
  • Disk state handling:
  • Session logs are append-only JSONL transcripts containing user messages, assistant messages, tool calls, tool results.
  • Memory is separate, stored as Markdown files like MEMORY.md and memory/YYYY-MM-DD.md.
  • Summaries can be written back to session logs because they are assistant turns and part of the transcript.
  • Context window limits:
  • OpenClaw manages prompt size using token budgeting and compaction.
  • Large histories/files are summarized or truncated before model call.
  • Vector search / memory retrieval:
  • Memory files are chunked and embedded automatically.
  • Semantic search injects only relevant snippets into prompt.
  • Session logs are not vectorized by default.

Useful mental models

  • External flow:
  • User/system event -> Gateway -> adapter -> normalized event -> policy -> session -> prompt -> model -> tools -> response.
  • State model:
  • Session log = full replayable event history.
  • Memory = curated long-term notes.
  • Vector index = derived retrieval layer over memory files.
  • Retrieval model:
  • File source of truth -> chunking -> embeddings -> vector search -> top-K snippets -> prompt.

Open questions / likely next topics

  • How tool execution is sandboxed and secured.
  • How session lane queues prevent concurrent runs per session.
  • How compaction and memory updates are triggered in practice.
  • How to customize memory search / embedding provider / chunk sizes.
  • How to build a custom RAG layer over session logs if needed.