Mission Control Memory Architecture: Runtime Sessions, Routing Intelligence, Knowledge Graph, and Self-Healing

[0xNyk]

Wanted to share a deeper technical breakdown of Mission Control’s memory system and where the hard problems are.

Mission Control memory is designed as a layered system:

1. Runtime session memory (short-term, live)

• Source: OpenClaw session stores ($OPENCLAW_STATE_DIR/agents/*/sessions/sessions.json)
• Optional merge: local Claude/Codex/Hermes session scanners
• API: /api/sessions
• Responsibilities:
  • discover active sessions
  • dedupe overlapping session records
  • classify active/idle/offline windows
• Why it matters: this is the “truth” for who is actually live right now

2. Routing/control memory (operational metadata)

• Source: Mission Control SQLite (agents, settings, notifications/chat state)
• Key fields:
  • agents.session_key
  • agents.config.openclawId
  • agents.config.isDefault
  • settings.chat.coordinator_target_agent
• Responsibilities:
  • map UI identities to runtime identities
  • resolve coordinator delivery target
  • maintain deterministic routing behavior
• Recent hardening:
  • dynamic coordinator resolution chain:
    configured target -> default agent -> live :main session -> fallback
  • this reduces gateway_send_failed when no literal “coordinator” runtime exists

3. Durable knowledge memory (long-term context)

• Source A: filesystem memory workspace (config.memoryDir) via /api/memory
  • tree/content/search
  • create/save/delete (RBAC + rate limits)
  • wiki-link extraction + schema validation
• Source B: OpenClaw memory SQLite files ($OPENCLAW_STATE_DIR/memory/*.sqlite) via /api/memory/graph
• Higher-level knowledge endpoints:
  • /api/memory/links (backlinks + graph)
  • /api/memory/health (multi-category quality scoring)
  • /api/memory/context (session-start context payload)
  • /api/memory/process (reflect, reweave, generate-moc)
• Why it matters: durable retrieval + structure quality over time

4. Integrity and self-healing (operability)

• OpenClaw doctor integration via /api/openclaw/doctor
• Classifies config/state/security issues
• Can run fix workflows + orphan transcript cleanup
• Parser hardened for ANSI/box-drawing output formats

Core challenge
The real challenge is cross-layer consistency:

• UI alias != DB identity != live runtime session in many deployments
• If these drift, delivery and recall degrade quietly
• Most reliability work is making those mappings explicit, resilient, and observable

Design guardrails currently in place

• Security: role-gated APIs, mutation/read rate limiting, path containment checks, symlink protections
• Performance: depth/file-size caps, bounded scans, lightweight aggregation for graph views
• Reliability: idempotent forwarding patterns, accepted-run handling, explicit status feedback on routing failures

Open to feedback
If useful, I can follow up with:

• sequence diagram (message send path with coordinator resolution)
• failure mode matrix (identity drift, stale sessions, split state dirs, orphan transcripts)
• observability checklist for production deployments