Standing Intents: Event-Triggered Memory for Agents
Learn how standing intents let agents remember event-conditioned future actions without long conversational context. This page covers their purpose, how they work, and how they compare to time-based tasks and aspirations.
Read this when
- You want the agent to act when a future event appears
- You are choosing between a scheduled task and an event trigger
- You want to inspect or cancel a standing intent
A standing intent is an instruction tied to an event, for example "when the release candidate is mentioned, remind me to verify rollback ownership." OpenClaw keeps it in the SQLite database of the agent that owns it and evaluates it before any eligible interactive reply.
These intents function as prospective memory. They capture what action to take once a trigger shows up, rather than scheduling work at a specific clock time.
Choose the right intention tier
| Intention | Use | Example |
|---|---|---|
| Time-based | Scheduled tasks | "Remind me Friday at 9 AM" |
| Event-based | Standing intent | "When Alice mentions the launch, ask about rollback" |
| Aspiration | Markdown with a review date | "Improve the release checklist this quarter" |
Place aspirations in MEMORY.md, a project note, or another maintained Markdown file that carries an explicit review date. They operate as neither clock jobs nor event triggers.
Create an event-based intent
Standing intents are memory directed by the owner. Channel owners that commands.ownerAllowFrom recognizes can employ the intent tool to create, list, or cancel them; other senders are not given that tool. Authenticated Gateway/Control UI administrators, along with the local CLI, may inspect and cancel existing intents, but creation demands an authenticated channel and sender identity. When either of those is absent, OpenClaw blocks creation and instructs the operator to retry from an authenticated channel conversation.
Have the agent set up the intent and clearly specify the event:
When someone mentions the launch checklist, remind me to confirm the rollback owner.
The agent relies on the intent tool, supplying a description and trigger keywords. It can further restrict the intent to a single conversation channel identifier or sender identifier, assign an expiry, adjust the fire budget up or down, or modify the cooldown.
By default, the scope covers the current channel and sender. Even with an explicit anywhere or anyone scope, the creating sender identity remains necessary: the matching hook cannot safely enforce a senderless owner principal on subsequent channel turns.
The defaults lean conservative on purpose:
- cooldown: 24 hours
- maximum fires: 3
- expiry: 90 days
For a clock time, the agent should follow the existing scheduled-task path rather than establishing a standing intent.
How matching works
On an eligible user turn, OpenClaw runs a deterministic FTS keyword prefilter across armed intents. A candidate fires only when every term in at least one configured trigger entry appears in the turn. OpenClaw also verifies channel scope, sender scope, expiry, cooldown, and fire budget against the authoritative SQLite rows within a single synchronous transaction. Matching examines at most 256 scoped FTS candidates per turn, so a noisy trigger set cannot hold up the reply path.
No model call happens during matching. On a hit, the main reply receives a bounded hidden context block:
Standing intent (created 2026-07-27): Confirm the rollback owner.
The matcher increments fire_count, records last_fired_at, and pushes the intent through its explicit lifecycle. After firing, an intent becomes armed again only once its cooldown passes. It turns done when the fire budget runs out and expired when the expiry elapses. Expiry and cooldown maintenance also ride along on existing heartbeat and cron reply hooks; OpenClaw does not introduce another timer subsystem.
TriggerBench indicates that prospective recall weakens as context lengthens and can slip into an always-remind heuristic (arXiv:2606.23459). Structural matching and fire budgets keep recall independent of conversational context while limiting false alarms.
List and cancel
Ask the agent to list standing intents when you need to check their status, scope, expiry, or fire count.
Cancellation is always explicit. Ask the agent to cancel a particular intent; the stored row shifts to cancelled and can no longer fire. OpenClaw never deduces cancellation from ordinary conversation. ProEvent reports that proactive systems frequently overact and have trouble with event cancellation (arXiv:2607.17701), so cancellation is durable state rather than a model judgment.
Lifecycle states
| State | Meaning |
|---|---|
pending | Stored but not yet armed |
armed | Eligible for matching |
fired | Matched and waiting for cooldown |
done | Fire budget exhausted |
cancelled | Explicitly cancelled |
expired | Expiry reached |
Standing intents reside in agents/<agentId>/agent/openclaw-agent.sqlite. They add no configuration keys and generate no sidecar files.