HHermes Explained

Automation

Event-Driven Agents

Agents that respond to changes rather than polling constantly.

Importance 4/52 backlinks1 source refs

Event-Driven Agents

What it is

Agents that respond to changes rather than polling constantly.

In plain terms

Think of the difference between physically walking outside every hour to see if a package has arrived, and a doorbell camera that pings your phone the instant someone actually sets a box on the step. Event-driven agents are the doorbell camera: instead of a scheduled check that usually finds nothing, Hermes wakes up only when a real signal arrives — a new message, a pushed commit, an incoming call — and acts on that one thing.

Why it matters

‘Check on a timer and hope something changed’ gives way to ‘get notified the instant something did’ — event-driven agents are triggered by a webhook firing, not a schedule tick. That avoids the structural waste of polling-based monitoring, where most checks find nothing new, and ties agent activity directly to real external events instead: a new message, a repo push, a form submission. Hermes’s plugin architecture is what makes this possible across many platforms without a custom integration per event source.

How it works

Hermes discovers plugins from four locations — bundled, user, project, and pip-installed packages — and calls each enabled plugin’s register(ctx) function exactly once when it loads (hermes_cli/plugins.py). A plugin can hook into named lifecycle points the agent core calls at fixed moments, or call ctx.register_platform() to add a whole new event source — an IRC or Viber adapter, say — into a shared registry the gateway consults instead of a hardcoded list (gateway/platform_registry.py). Every registered adapter subclasses the same base adapter and holds an open connection or listener; the moment a real message, webhook, or platform event arrives, it builds one MessageEvent and calls the shared handle_message() pipeline (gateway/platforms/base.py) — the same entrypoint regardless of whether the source was Telegram, Slack, or a custom plugin. Nothing runs until that call happens.

A concrete example

A team wants Hermes to react on their internal IRC server, which isn’t one of the built-in platforms. A plugin author writes an IRC adapter and calls register_platform() when Hermes starts. The gateway adds irc to its known platform list, checks the plugin’s dependencies, and opens a persistent connection instead of scheduling repeated checks. The moment a teammate sends a message mentioning Hermes, that one event builds a MessageEvent and runs the agent once. The reply goes back through that same IRC connection — no polling, no missed messages, no wasted cron ticks.

How it connects

This note belongs to the Automation family. Its closest neighboring concepts are: Webhooks, Monitoring Jobs, Agent Runtime, Personal OS.

Source evidence

  • vendor/hermes-agent/hermes_cli/plugins.py:1302-1313#PluginManager.discover_and_load — Verified Source Map evidence for PluginManager. The directory scanner forwards discovered plugin.yaml or plugin.yml files to _parse_manifest; PluginManager parses them with a safe YAML loader, normalizes the kind, and auto-loads bundled backend manifests through _load_plugin.

Workflows

  • No first-pass workflow mapping yet; this concept still appears in the vault graph through articles and source evidence.
  • Ten Hermes Workflows That Turn a Chatbot into a 24/7 Assistant