Making Hermes proactive

Cron schedules and webhook endpoints

Hermes has two practical mechanisms for initiative right now.

The first is scheduled work. You can create cron-style tasks that run on a cadence and post results into Slack or another channel:

hermes cron create "every weekday at 9:00" \
  --prompt "Check for new Notion pages and post a summary in #agents" \
  --name "notion-digest"

The task runs without anyone in the loop. It uses the same agent loop as interactive sessions, so it has access to tools, memory, and connected platforms. You can also set up a weekly variant, a daily standup, or any cadence cron supports.

The second mechanism is webhooks. Hermes can expose endpoints at /webhooks/<name>. When an external system (Notion, GitHub, a custom script) POSTs to that endpoint, Hermes receives the payload and acts on it:

hermes webhook subscribe github-prs \
  --prompt "A new PR event came in. Summarize and post to #code-review"

Combined with the persistent gateway, which stays running in the background, this gives you a basic form of change-triggered behavior. A webhook arrives, the agent wakes up, and it takes action. Session memory carries across runs, so a scheduled task or webhook handler isn't completely stateless.

No listener, no durable state

These features are useful, but they don't form the three primitives that make an agent truly proactive.

Hermes has a clock. It has an inbox (Slack, CLI, webhooks). What it lacks is a strong listener for data changes and durable state that lives outside the conversation.

There is no built-in equivalent to watching a Notion database, a directory, or a set of files. You can approximate this with webhooks, but you have to wire the external system yourself. The agent doesn't maintain its own subscription to changes. It reacts to what someone else pushes to it, which is a meaningful difference from the listener primitive that normalizes change events across providers.

State is limited in a similar way. Memory exists between sessions, but it isn't the kind of live, queryable, conflict-aware substrate that lets an agent pick up exactly where it left off after days or weeks. Most of the context still lives in the prompt or in whatever the user remembers to include.

Webhooks themselves are basic. They receive a payload and can trigger a prompt, but there's no routing, replay, or dead-letter handling. If the gateway is down when the webhook fires, the event is lost unless you build retry logic in the sending system. The failure modes catalogued in where push architectures break apply directly here.