Hooks for event-driven behavior
Hooks are for reacting to command, session, agent, gateway, or message events. They work best when the goal is small, deterministic glue rather than long autonomous loops.
The discussion has moved beyond “can OpenClaw reply in chat?” to “can it run useful work on a schedule, react to events, and post the result back into the right channel?” That is where hooks, cron, and webhooks matter.
Examples for scheduled summaries, reminders, and low-noise background jobs.
A distinction between hooks, cron, heartbeat, and external webhooks.
Recipes that keep automations observable and cheap instead of silently burning tokens.
Hooks are for reacting to command, session, agent, gateway, or message events. They work best when the goal is small, deterministic glue rather than long autonomous loops.
Cron is for reminders, daily summaries, recurring maintenance, and background reporting. The big practical question is whether the job should run in the main session, an isolated session, or post to a webhook.
Webhooks are the cleanest bridge when another system should trigger OpenClaw or receive a finished result. This is the right pattern for Gmail, dashboards, internal tools, or external notifications.
Automation should not default to the most expensive model. A strong guide shows when to use cheaper models, when to keep lightweight context, and how to keep failed runs visible.