The 'lane-aware FIFO queue with one active run per session' detail is what I've been missing. I've been hitting concurrency issues in my own setup - multiple triggers, unclear which session owns the current state.
The JSONL transcript approach for state persistence makes sense. Disk-based durability beats keeping everything in memory when agents restart unexpectedly (which they do, often, for reasons you won't predict in advance).
One thing I'm curious about: how does the Gateway handle priority? If a higher-priority event comes in while a session is mid-run, does it queue and wait, or is there preemption? The docs I've seen are silent on this.
That was my read too: I don’t see a first-class priority scheduler in the docs.
What OpenClaw does document is per-session single-writer lanes, a global lane, and queue modes. So if something arrives for the same session while a run is active, the default behavior is usually wait (collect / followup), or steer at the next tool boundary if queue mode is steer. There’s also a legacy interrupt mode that aborts the active run for that session.
Separate lanes like cron and subagent let some categories run in parallel without blocking inbound replies, but that’s different from a general “higher-priority event jumps the queue” mechanism.
So my current read is: lane isolation + mode-based preemption, not true priority scheduling. If I find a doc/code path that says otherwise, I’ll update the post.
The reason why people feel that it's alive, is because those heartbeats run and find unfinished business inside the memory stored in local files. A long-term memory file and a file for each day. So the agent comes up with things from your past interactions and triggers you - instead of being triggered by you.
Thanks, this is super useful stuff! And I finally get what the OpenClaw hype is all about!
Though I find it funny that people jump to anthropomorphise it, when it's just a heartbeat , and a bunch of other triggers that makes it do stuff!
The 'lane-aware FIFO queue with one active run per session' detail is what I've been missing. I've been hitting concurrency issues in my own setup - multiple triggers, unclear which session owns the current state.
The JSONL transcript approach for state persistence makes sense. Disk-based durability beats keeping everything in memory when agents restart unexpectedly (which they do, often, for reasons you won't predict in advance).
One thing I'm curious about: how does the Gateway handle priority? If a higher-priority event comes in while a session is mid-run, does it queue and wait, or is there preemption? The docs I've seen are silent on this.
That was my read too: I don’t see a first-class priority scheduler in the docs.
What OpenClaw does document is per-session single-writer lanes, a global lane, and queue modes. So if something arrives for the same session while a run is active, the default behavior is usually wait (collect / followup), or steer at the next tool boundary if queue mode is steer. There’s also a legacy interrupt mode that aborts the active run for that session.
Separate lanes like cron and subagent let some categories run in parallel without blocking inbound replies, but that’s different from a general “higher-priority event jumps the queue” mechanism.
So my current read is: lane isolation + mode-based preemption, not true priority scheduling. If I find a doc/code path that says otherwise, I’ll update the post.
Great
Congratz for the article!
Full of content, well written and right on point!
Ive been researching about AI Drifts, non-determininsm.. Looks like its a nice place to get more answers! :)
The reason why people feel that it's alive, is because those heartbeats run and find unfinished business inside the memory stored in local files. A long-term memory file and a file for each day. So the agent comes up with things from your past interactions and triggers you - instead of being triggered by you.
Thanks for demystifying the architecture. Most newbies feel that it is alive somehow.