Why Can Every Chat Tool Already Talk to a Hermes Agent, But Not to an OpenClaw One?

Dan
Why Can Every Chat Tool Already Talk to a Hermes Agent, But Not to an OpenClaw One?

Point any tool that already speaks the OpenAI API — Open WebUI, LangChain, a five-year-old curl script — at a Hermes agent, and it works immediately. Point that same tool at an OpenClaw agent, and it fails outright: wrong endpoints, wrong auth scheme, wrong request shape. Nothing is broken. Both gateways work exactly as designed. So why does one framework make itself reachable by literally everything, while the other makes itself reachable by nothing until someone writes an adapter?

The answer comes down to a single decision each project made early on: whether to invent a protocol, or borrow one that already existed.

OpenClaw invented its own contract

An OpenClaw gateway exposes a small, custom set of endpoints under a "hooks" namespace:

POST {gateway_url}/hooks/agent    # send the agent a message
POST {gateway_url}/hooks/wake     # nudge it awake outside a conversation
POST {gateway_url}/hooks/config   # push config / secret updates
POST {gateway_url}/tools/invoke   # trigger a tool call directly
GET  {gateway_url}/healthz        # liveness check

This is a perfectly reasonable API. It's also one that has never existed anywhere else before OpenClaw defined it. No client library, chat UI, or eval harness on Earth was built to call /hooks/agent, because until OpenClaw shipped it, that endpoint had no meaning. Every caller — including Clawployees, which drives OpenClaw agents through exactly this API — has to be written specifically to understand it.

Hermes borrowed one that already existed

A Hermes gateway's API server exposes this instead:

POST {gateway_url}/v1/chat/completions
Authorization: Bearer {api_server_key}

That single endpoint is the OpenAI Chat Completions format — the same request and response shape that every major model provider, every eval framework, and most of the LLM tooling ecosystem has already implemented a client for. Hermes' own documentation states the intent plainly: the API server exists so you can "connect any frontend that speaks the OpenAI format — Open WebUI, LobeChat, LibreChat, and more." Hermes didn't have to convince anyone to build support for it. That support already existed, years before Hermes did.

So here's the actual answer

A Hermes agent is reachable by everything on day one because Hermes chose to speak a language the rest of the industry already spoke. An OpenClaw agent is reachable by nothing until an adapter is written because OpenClaw chose to speak a language only it understands. That's the entire mechanism — not a missing feature, not an oversight, a direct consequence of which of the two decisions each project made.

And that's the firm takeaway: if reachability is what you're optimizing for, adopting an existing standard beats inventing a better bespoke one almost every time. The value isn't the protocol itself — it's the years of client code, tooling, and habit that come attached to it for free. A custom API can be cleaner, more expressive, more tailored to exactly what your platform needs. None of that matters to a caller who has to write a translation layer before they can send their first request. Design the API you control. But know that every proprietary choice you make is a toll booth for the next integration — and every standard one you adopt is a bridge someone else already built.

Related Articles