Plugins vs. Native: One Difference Between OpenClaw and Hermes
On Clawployees, every managed agent runs on one of two engines: OpenClaw or Hermes. They can both live on the same server, run the same skills, answer on the same channels, and serve the same conversations. From the outside they often look interchangeable.
But the two were designed around different instincts. There are several places you can see this, and trying to cover all of them at once turns into a spec sheet nobody reads. So this post does one thing: it looks at a single difference, the one that quietly shapes the rest.
When an agent needs to reach the outside world, does it load a plugin, or does the runtime already know how?
OpenClaw: the framework you extend
OpenClaw treats the outside world as something you bolt on. The core is a lean agent loop, and capabilities arrive as plugins. Integrations live in an extensions directory, get listed in an allowlist, and announce themselves at startup. On Clawployees, the bridge back to the platform is itself a plugin: clawployees-hub, injected into every OpenClaw agent. It is the piece that syncs skills, sends heartbeats, and pulls down config changes.
This is a classic framework posture. The engine stays small and opinion-free; the interesting behavior is composed from parts. It is flexible and very hackable. The cost is that the parts have to be present, trusted, and kept in step. If the hub plugin is missing from the allowlist, or its files drift out of date, the agent still boots, channels still work, but the platform features quietly stop. The capability was never part of the engine. It was a guest.
Hermes: the runtime that already knows
Hermes makes the opposite bet. The things an agent commonly needs, memory, sessions, scheduled jobs, an API surface to talk to, are native concepts baked into the runtime rather than features you assemble. There is no equivalent of the hub plugin to inject. Hermes exposes an OpenAI-compatible API server and is driven by a connector and native config; the platform talks to capabilities the runtime already provides instead of installing them.
This is a batteries-included posture. There is less to forget, less to keep in sync, and fewer ways for an agent to be technically running yet functionally hollow. The trade is the mirror image of OpenClaw's: when a capability is native, you extend it on the runtime's terms, not by dropping in your own module. You get fewer moving parts and, with them, fewer places to wedge something unusual.
Why this one difference matters
It would be easy to file this under configuration trivia, but it is really a difference in where responsibility lives. OpenClaw pushes capability outward, into plugins you own and maintain. Hermes pulls capability inward, into a runtime that owns and maintains it for you.
That single decision ripples outward into how each engine is configured, how secrets are handled, how it is kept healthy, and what breaks when something goes wrong. Neither instinct is correct in the abstract. A platform that wants maximum hackability leans toward the plugin model. A platform that wants the fewest possible failure modes for unattended agents leans toward the native one.
On Clawployees you do not have to pick a side permanently. A managed agent can be converted between the two runtimes in place, keeping its skills, channels, memory, and history. The plugin-versus-native question is not a fork in the road. It is a dial you can turn.
