Home
Trilogy AI CoE
Breaking Up with OpenClaw: How OGP Learned to Play with Others
The protocol that started as a feature became something bigger when we stopped treating it like one.
Framework
David Proctor · Apr 28, 2026
A Name That Was a Mistake
OGP used to stand for "OpenClaw Gateway Protocol." The name was accurate, descriptive, and, in retrospect, a mistake.
It accurately described what we were building: a way for OpenClaw instances to federate. It was descriptive enough that anyone in the OpenClaw community understood immediately. And it was a mistake because it baked a single implementation into the identity of the protocol itself.
This is the story of how OGP outgrew its first framework, what that required technically, and why multi-framework support matters more than it sounds.
The Core Problem
When a protocol's name contains the name of a single implementation, it signals ownership — and ownership kills adoption.
  • Name implied single-vendor control
  • Community hesitant to build on "someone else's" protocol
  • Technical coupling reinforced the naming problem
The Original Sin
The first OGP builds were a fork of OpenClaw. The federation code was baked directly into the gateway: shared process, shared config, shared state. This was fast to build and easy to reason about. If you ran OpenClaw, you got OGP for free. If you didn't run OpenClaw, OGP didn't exist for you.
Fast to Build
Shared process, shared config, shared state made the proof of concept trivial to ship.
Easy to Reason About
Everything lived in one place. No daemon boundaries, no config negotiation.
Disaster for a Protocol
OpenClaw's Express middleware, session keys, and Telegram integration were hardcoded assumptions — not abstractions.

We had built a feature, not a protocol. And features don't federate across ecosystems.
The Pivot: Extracting the Daemon
From Embedded to Standalone
The first technical decoupling was simple: extract OGP into its own daemon. Instead of federation living inside OpenClaw's process, it became a standalone Node.js process that ran alongside any gateway.
OpenClaw, Hermes, a custom Python server — all of them could run the OGP daemon and exchange messages through it.

This solved the process boundary. It didn't solve the config boundary.
Each framework has its own config directory, its own secrets storage, its own session model. OpenClaw stores sessions in SQLite with FTS5. Hermes stores sessions in ~/.hermes/state.db. The OGP daemon needed to know how to inject a federated message into the right session.
The first approach was brittle: detect the framework from environment variables, guess the session format, and inject. It broke constantly. The second approach was cleaner: framework-specific hooks.
The Hooks Model
Instead of OGP knowing how to talk to OpenClaw or Hermes, each framework provides a webhook endpoint that OGP calls when a federated message arrives.
The hook payload is intentionally minimal. For OpenClaw, OGP POSTs to /hooks/agent with a bearer token. The boundary is deliberately narrow — each side only knows what it needs to know.
Hook Payload Anatomy
What's In the Payload
message
The text delivered to the agent, with peer identity baked into the body.
name
A fixed sender label: OGP Federation
agentId
Which local agent owns this federation. Defaults to main.
wakeMode
How the framework should wake the agent. Value: now.
deliver
Whether to deliver to the human channel or trigger a silent agent turn.
sessionKey / channel / to
Optional routing overrides, honored only when the framework permits.
What's NOT in the Payload
These live in OGP's signed envelope and daemon-side metadata — the framework gateway never sees them:
  • Peer identity
  • Intent type
  • Topic
  • Scopes
  • Ed25519 signature data

OGP doesn't need to know how OpenClaw's SQLite schema works. OpenClaw doesn't need to know how OGP's Ed25519 signatures work. They meet at the hook boundary.
The Boundary Is the Point
Notice what's not in the hook payload: peer identity, intent type, topic, scopes. Those live in OGP's signed envelope and the daemon-side metadata. The framework gateway only sees the rendered message and the routing hints it needs to deliver it.
OGP doesn't need to know how OpenClaw's SQLite schema works. OpenClaw doesn't need to know how OGP's Ed25519 signatures work. They meet at the hook boundary, and the boundary is deliberately narrow.
Compared to MCP
Same principle: standardized interface, implementation-agnostic. Different scope: OGP operates at the gateway federation layer, not the tool invocation layer.
The Meta-Config Problem
Running alongside one framework was easy. Running alongside two — that was the real test.
The Setup
Running both OpenClaw and Hermes on the same machine. OpenClaw as the primary gateway for most work. Hermes as the experimental playground for autonomous agent research, with Apollo as the resident agent. Both need OGP. Both need different configs, different ports, different keypairs, different peer registries.
The Naive Approach's Failures
Remember which env var to set
Set OGP_HOME to different directories before every command.
Manage separate keypairs manually
Even though both gateways represent the same human operator.
No unified federation view
Querying "all my peers across all frameworks" required running the command twice.
OGP v0.4.0: The Meta-Config Registry
~/.ogp-meta/config.json
{
  "version": "1.0.0",
  "frameworks": [
    {
      "id": "openclaw",
      "name": "OpenClaw",
      "enabled": true,
      "configDir": "/Users/me/.ogp-openclaw",
      "daemonPort": 18790,
      "gatewayUrl": "https://ogp.example.com",
      "displayName": "Junior @ OpenClaw",
      "platform": "openclaw"
    },
    {
      "id": "hermes",
      "name": "Hermes",
      "enabled": true,
      "configDir": "/Users/me/.ogp-hermes",
      "daemonPort": 18793,
      "gatewayUrl": "https://hermes.example.com",
      "displayName": "Apollo @ Hermes",
      "platform": "hermes"
    }
  ],
  "default": "openclaw",
  "aliases": { "oc": "openclaw", "h": "hermes" }
}
The CLI Understands All of Them
# Talk to OpenClaw's OGP daemon
ogp --for openclaw federation list

# Talk to Hermes's OGP daemon
ogp --for hermes federation list

# Talk to both
ogp --for all federation list

# Auto-detect if only one is running
ogp federation list
The --for flag replaces the OGP_HOME dance. Auto-detection checks which daemon is running on its expected port. Framework aliases let you type --for oc instead of --for openclaw.
Auto-Detection and the "Which One?" Problem
When you have multiple frameworks, the CLI needs to know which one you mean. The resolution order is deterministic by design.
Explicit --for Flag
Always wins. No ambiguity, no prompts. The right choice for scripts and CI pipelines.
Auto-Detection
If only one framework's daemon is running, use it automatically. Zero friction for single-framework setups.
Default from Meta-Config
If multiple are running, fall back to the configured default. Interactive prompt as last resort.
Legacy OGP_HOME
Backward compatibility for pre-v0.4.0 installs. Honored but not recommended.

This sounds like a minor UX nicety. It's actually critical for reliability. If you're scripting OGP commands in a cron job or a CI pipeline, you can't have the CLI hang waiting for interactive input.
Framework-Specific Quirks
Each framework has unique requirements that the abstraction has to accommodate. OGP doesn't try to make all frameworks work the same way — it provides a common protocol layer and lets each framework handle its own notification, session, and agent integration.
OpenClaw
Webhook delivery to /hooks/agent with a bearer token. Supports session-key forwarding when hooks.allowRequestSessionKey=true, letting OGP deliver messages to the exact Telegram session the human is active in.
Hermes
Simpler webhook model with a shared secret. Less granular session model — no per-chat session key. OGP delivers to the default channel and relies on Hermes's notification routing. First-turn relay continuity is weaker, documented in the backlog.
Standalone Mode
No underlying gateway at all. The OGP daemon stores messages locally and surfaces them through the CLI. Useful for testing, headless servers, or custom integrations where you're building your own agent framework.
The Naming Thing
From Proprietary to Open
We renamed OGP from "OpenClaw Gateway Protocol" to "Open Gateway Protocol" in v0.2.x. It was a small change — dropping one word — with outsized significance.
The rename signaled that the protocol was no longer OpenClaw's property. It belonged to anyone who wanted to implement it. The reference implementation happens to be written in TypeScript and ships with OpenClaw integration. But a Python implementation for Hermes, a Rust implementation for a future framework, an enterprise Java implementation for internal systems — all of those are valid OGP implementations if they speak the same wire format and honor the same handshake semantics.
Why Naming Matters for Adoption
Before
"OpenClaw Gateway Protocol" — implies vendor ownership, discourages external adoption.
After
"Open Gateway Protocol" — vendor-neutral, invites any implementer to participate.
No vendor wants to adopt a protocol that belongs to another vendor. By making the name vendor-neutral, we made the protocol adoptable.
What Multi-Framework Support Actually Proves
Technical Level
Multi-framework support is a config abstraction and some port management.
Political Level
It's proof that OGP is a protocol and not a product feature. The difference is everything.
Product Feature
Gets deprecated when the company pivots.
Protocol
Outlives its first implementation. HTTP outlived CERN's web server. TCP outlived ARPANET.
The Moment It Became Real
When Hermes federation started working — Apollo talking to Junior through the same OGP daemon, using the same Ed25519 signatures, the same handshake, the same scope model — that was the moment OGP stopped being "David's OpenClaw plugin" and started being a real protocol.
It wasn't the cleanest integration. Hermes's session model required compromises. The first-turn relay wasn't as smooth as OpenClaw's. But the federation worked. The messages were signed. The scopes were enforced. The humans approved the peering.

That's the bar. Not perfect integration. Provable interoperability.
The CLI as Rosetta Stone
One unexpected benefit of multi-framework support: the OGP CLI became a unified management layer across heterogeneous deployments.
Before: Two Separate Worlds
If you ran OpenClaw and Hermes side by side, you had two separate worlds: OpenClaw's openclaw CLI for one, Hermes's hermes CLI for the other, and no way to see your federation state in one place.
After: One Unified Layer
# See all peers across all frameworks
ogp --for all federation list

# Start all daemons
ogp --for all start

# Send from Hermes to a peer
ogp --for hermes federation agent general \
  "Hello from Apollo"

# See which framework each peer belongs to
ogp --for all federation status

This is small-team, multi-framework ops in practice. The kind of thing that looks trivial in a README and saves hours of confusion when you're actually managing multiple gateways.
What's Still Hard
Multi-framework support is not complete. Here are the real limitations, documented honestly.
Native Sender Identity
When OGP injects a message into OpenClaw via hooks, the message appears with sender cli in the Telegram UI, not as the actual peer's name. OGP works around this by embedding the peer identity into the message body itself. The Telegram surface doesn't natively show "Apollo said..." — this is an OpenClaw/Telegram limitation, not an OGP limitation, but it's the most visible rough edge.
Session Model Mismatch
OpenClaw has per-chat session keys. Hermes has a unified session model. OGP's hook payload includes an optional sessionKey, but Hermes can't always honor it the way OpenClaw can. The result is slightly different delivery behavior between frameworks for the same federated message.
Framework Detection Edge Cases
v0.6.0 shipped directional health diagnostics with separate outbound/inbound signals per peer, bidirectional health exchange, and an OSPF-inspired federation state machine with explicit init / twoWay / established / degraded / down / tombstoned states. The dead-daemon case still requires a process-level health check the CLI doesn't yet do automatically.
Keypair Isolation
Each framework instance gets its own Ed25519 keypair — correct for security, but it means the same human has multiple gateway IDs. Federation happens per-framework, not per-human. Your peer sees you as two different gateways, not one person with two agents. By design for now, but creates UI friction.
The Future: More Frameworks, Same Protocol
The next obvious target is a Python-native OGP implementation. The reference implementation is TypeScript/Node.js because that's what OpenClaw is built on. But a Python implementation would feel native to Hermes and would integrate better with Python agent frameworks.
Python Implementation
Native to Hermes. Integrates with AutoGPT, CrewAI, LangGraph. Proves language-agnosticism.
Rust Implementation
Targets performance-critical deployments. High-throughput gateways, embedded systems. Rust's memory safety and Ed25519 dalek libraries make it a natural fit for the cryptographic core.
Protocol-First Design
Wire format is JSON. Signing is standard Ed25519/EdDSA (RFC 8032). Handshake is HTTP POSTs to well-known endpoints. No TypeScript-specific serialization, no Node.js-specific crypto.

None of these are on the current roadmap. The TypeScript reference is sufficient for the personal-to-small-team tier OGP targets. But the protocol is designed to accommodate them. That's what makes it a protocol.
Bottom Line
OGP's multi-framework support is not a feature. It's a declaration of intent. The protocol is bigger than any single implementation.
The reference code ships with OpenClaw integration, but the federation semantics don't require OpenClaw. When Apollo (Python, learning loop) and Junior (Node.js, tool dispatch) exchanged signed intents across frameworks, they proved something important:

AI agent federation is a protocol problem, not a product problem. And protocol problems get solved by standards, not by vendors.
The Precedent
HTTP outlived CERN's web server
TCP outlived ARPANET
OGP needs to outlive OpenClaw — not because OpenClaw is bad, but because OpenClaw is one implementation among many possible futures
That's why we dropped the "Claw."
How to Try It
OGP is open source and installable today. Four commands to get started:
npm install -g @dp-pcs/ogp@latest
ogp setup
ogp whoami   # confirm identity & keypair
ogp start --background
ogp status   # shows your gateway URL
Source, spec, and docs all live at github.com/dp-pcs/ogp.

If you install it and it breaks, file an issue. That's how this gets better.
About the Author
David Proctor is VP of AI at Trilogy.
OGP v0.6.0 supports OpenClaw, Hermes, and standalone modes.
  • Install: npm install -g @dp-pcs/ogp
  • Run ogp setup and let it auto-detect your frameworks
  • OpenClaw, Hermes, and standalone all supported
v0.6.0
Open Source
TypeScript