OpenClaw standing intents

Remembering a fact and remembering to act are different faculties, and the second one degrades fastest as a conversation grows. Standing intents take that job out of the model's hands: the intention becomes a row in a database with machine-checkable trigger fields, and the matching path never calls a model at all. Here is how they are created, matched and retired.

Choosing the tier

• The docs separate three kinds of intention: time-based ones such as a Friday reminder belong to scheduled tasks, event-based ones such as acting when a topic is mentioned belong to standing intents, and aspirations such as improving a checklist this quarter belong in markdown with an explicit review date.
• Creation is owner-directed: channel owners recognised by the command owner list can use the intent tool to create, list or cancel, other senders never receive the tool, and authenticated administrators and the local command line can inspect and cancel but not create, because creation requires an authenticated channel and sender identity.
• The agent supplies a description and trigger keywords, and can narrow the intent to one conversation or sender, set an expiry, change the fire budget or change the cooldown; the default scope is the current channel and sender, and even an explicit anywhere or anyone scope still requires the creating sender identity.
• Defaults are intentionally conservative: a 24 hour cooldown, a maximum of three fires and an expiry after 90 days, with at most three intents injected in any single turn.

Standing intents are prospective memory. They remember what to do when a trigger appears; they do not schedule work for a clock time.

How matching works

On an eligible user turn, OpenClaw runs a deterministic full-text keyword prefilter over armed intents. A candidate fires only when every term in at least one configured trigger entry appears in the turn, and the matcher rechecks channel scope, sender scope, expiry, cooldown and fire budget against the authoritative database rows inside one synchronous transaction. Matching scans at most 256 scoped candidates per turn so a noisy trigger set cannot stall the reply path, and no model call happens anywhere in that path. On a hit, the main reply receives a bounded hidden context block naming the intent and its creation date, the matcher increments the fire count, records the time and moves the row through its lifecycle. A prompt hook that times out while waiting for database admission cannot consume a fire with its late completion, and a host without the required hook capability skips matching entirely rather than silently spending an intent.

Lifecycle and storage

• The states are explicit: pending when stored but not yet armed, armed when eligible for matching, fired when matched and waiting out the cooldown, done when the fire budget is exhausted, cancelled when explicitly cancelled, and expired when the expiry passes.
• A fired intent becomes armed again only after its cooldown, expiry and cooldown maintenance piggyback on existing heartbeat and scheduled reply hooks rather than adding another timer subsystem, and the rows live in the agent's own database file while adding no configuration keys and creating no sidecar files.
• Cancellation is always explicit: asking the agent to cancel a specific intent moves the row to cancelled and it can no longer fire, and OpenClaw never infers cancellation from ordinary conversation, because proactive systems are documented to overact and to handle event cancellation poorly.

OpenClaw memory overview is the wider memory picture and OpenClaw automations the scheduler that owns clock-time work.

Why not just write it down

Storing an intention as prose in a memory file is the least reliable option available. Prospective recall decays sharply as context grows even while ordinary fact recall stays near perfect, and a model asked to track its own pending intentions drifts toward always reminding, which is its own failure. Compiling the intention into a row with keywords, scope, expiry, a fire budget and a cooldown makes recall independent of conversational length and makes false alarms bounded rather than unbounded. The same reasoning explains why cancellation is durable state rather than a judgment call, and why the injected block is capped at three intents per turn. The OpenClaw user model holds standing preferences rather than pending actions and OpenClaw memory architecture explains where prospective memory sits among the tiers.

On Diali

On Diali each assistant keeps its own database on a persistent volume, so an intent created today is still armed after the next release; daily snapshots and one-click restore are available through the Backups add-on (included on Max). Hosted OpenClaw on Diali describes the hosted assistant and Diali security the boundary around each runtime.

• An event trigger, not a clock: the scheduler owns times.
• Deterministic matching, no model call, at most 256 candidates.
• Cooldown, budget and expiry bound every intent by default.