Documentation
Deep Dive
Framework Focus: Concurrency, Approvals, Memory, Ops

Framework Focus: Concurrency, Approvals, Memory, Ops

This section breaks key mechanisms into “replicable modules” that make OpenClaw reliable and controllable.

If you haven’t verified an observable baseline yet, do this first:

Suggested reading order

  1. Terminology
  2. Roadmap
  3. Gateway control plane
  4. Agent execution (run/attempt/fallback)
  5. Session concurrency (sessionKey/lane/queue)
  6. Tool policy + exec approvals
  7. Lifecycle + ops

Advanced modules (optional)

Implementation guides

These pages are more “build order + acceptance checks” for replicating the same mechanics:

1) Concurrency + isolation (lanes + global limits)

See:

Code entry points (optional):

  • src/process/command-queue.ts (lane + queue)
  • src/gateway/server-lanes.ts (gateway-level concurrency)
  • src/config/sessions/session-key.ts (stable session keys)

2) Tool safety layers (sandbox / tool policy / approvals)

See:

Code entry points (optional):

  • src/agents/tool-policy-pipeline.ts (policy pipeline)
  • src/infra/exec-approvals.ts, src/gateway/exec-approval-manager.ts (exec approvals state machine)

3) Memory + compaction (sustainable long conversations)

See:

4) Extensibility (hooks + plugins)

See:

5) Ops and reliability (logging, health, remote, repairs)

See:

Acceptance checks (make it verifiable)

If you want a minimal set of “hard checks” to validate your understanding:

  1. Explain why chat.send ACKs fast and results stream via events (see Control UI).
  2. Explain why a single sessionKey stays ordered while different sessions can run concurrently (see Queue + lanes).
  3. Explain the three safety layers (sandbox / policy / approvals) and what each layer owns (see Sandbox vs tool policy vs elevated).
  4. Use logs to trace a run from runId to tools and final output (see Logging).