[Opinion] OGP: Federation Belongs at the Gateway, Not the Agent
What OpenClaw taught me about why AI agents need federated gateways
Agent skills have quietly become a standard.
Anthropic introduced the SKILL.md specification in late 2025, and by early 2026 it had been adopted across dozens of agent platforms: Claude, OpenAI Codex, Google Gemini CLI, GitHub Copilot, Cursor, JetBrains Junie. The idea is simple: a markdown file that tells an AI agent what a capability does, when to use it, and how to invoke it. Drop a SKILL.md file in the right place and your agent gains a new ability.
It’s a good idea. Skills are modular, composable, and portable. They’ve unlocked a huge surface area of automation that would have required custom integrations a year ago.
But skills have a structural limit that’s easy to miss until you hit it.
The Wall Skills Can’t Climb
A skill tells your agent how to use tools you control. It can call the Calendly API because you have a Calendly account. It can read your email because you granted that permission. It can search the web because it has access to a search API.
The common thread: every skill invokes something that was built for you to call. A pre-existing endpoint. A published API. A service designed with third-party access in mind.
Now consider a different scenario. Two companies want their AI agents to work together. Procurement at Company A needs to coordinate with vendor management at Company B: request quotes, confirm specifications, trigger approvals. Not a one-time workflow. An ongoing operational relationship between two intelligent systems representing two organizations.
Company B is not going to publish a public API for Company A’s agent to call. There’s no shared backend. There’s no “procurement Calendly.” Each side has their own systems, their own context, their own agent, with no pre-existing integration between them.
You can’t skill your way out of this. A skill requires something to call. When the other side has nothing published, there’s nothing to call.
What you need is a way for two agents to meet in the middle: discover each other, establish mutual trust, agree on what they’re willing to exchange, and do it without either side needing to build an integration for the other. That’s not a skill. That’s a protocol.
Why This Problem Is Bigger Than It Looks
The procurement example isn’t exotic. It’s the shape of almost every cross-organizational workflow that involves sensitive or proprietary data:
A law firm’s agent coordinating document review with a client’s agent
A hospital’s scheduling agent working with an insurance company’s authorization agent
A contractor’s agent syncing deliverables with a project owner’s agent
In each case, both sides have agents. Neither side has an API the other can call. The only path forward is a shared protocol that both agree to speak, one that neither controls, and that handles the trust and transport layer so each side’s agent can focus on the work.
That’s the gap OGP is designed to fill.
What OGP Actually Is
OGP (the Open Gateway Protocol) is an attempt to solve exactly this, at the layer where it belongs.
At its core, OGP is four things:
1. Cryptographic identity per gateway.
2. Bilateral trust establishment.
3. Signed intent messages.
4. Controlled information boundaries.
How OGP Relates to A2A
OGP and A2A solve different problems at different layers. OGP federates the gateways that agents sit behind. A2A handles what agents actually say to each other once trust is established. They’re not competing, they’re sequential. OGP is the handshake. A2A is the conversation.
[Note: The full breakdown of how OGP and A2A work together.]
Building It: From Fork to Standalone Package
The name started as “OpenClaw Gateway Protocol.” To understand why, it helps to know what OpenClaw brought to the table: it was among the first platforms to take a gateway-first approach to AI agents, where your agent sits behind a gateway that controls its context, its permissions, and what can reach it. The gateway is the boundary layer. Your agent operates inside it.
That model works well for individuals. The natural next question was whether gateways could coordinate with each other on behalf of their users, without either user managing the exchange manually and without either gateway handing over raw access to what’s behind it. That question became OGP.
As the protocol took shape, the framing expanded beyond OpenClaw specifically. OpenClaw is the current implementation. There will be other gateway platforms that take the same approach. The protocol should outlive any single one. So the name became “Open Gateway Protocol.” Drop the Claw, keep the Open.
The first version was built as a fork of OpenClaw itself, with the protocol baked directly into the gateway. The proof-of-concept was a scheduling scenario. David and Elon each had a gateway with an agent behind it (Chad and Elon Tusk, respectively). Chad wanted to book time on Elon’s calendar. Rather than either user coordinating manually, or having agents reach directly into each other’s calendars, Chad sent a federation request for available times. What came back wasn’t raw calendar data. It was filtered through Elon’s stated preferences: a standing lunch block, focus time, whatever he’d told his agent to protect. Chad picked a slot and booked it. Neither user touched a calendar app.
The insight isn’t about scheduling. It’s that a gateway can return preference-aware responses, not just factually accurate ones. Free/busy data tells you when someone’s calendar is empty. A gateway can tell you when someone is actually available in a way that reflects how they work. That pattern generalizes to any situation where one party wants to query another’s context without getting raw access to that context. That’s most cross-organizational coordination.
But baking a protocol into a fork creates a maintenance problem. Every OpenClaw update becomes a merge conflict. And it means anyone who wants OGP has to run a forked version of their gateway, and that’s a non-starter for most people.
So the protocol was extracted into a standalone package: @dp-pcs/ogp.
The daemon runs alongside your existing OpenClaw installation on a separate port. It exposes the federation endpoints, manages keypairs and peer relationships, handles the approval flow, and notifies your OpenClaw agent when federation events arrive, all without touching your gateway config.
Install it in three commands:
npm install -g github:dp-pcs/ogp --ignore-scripts
ogp-install-skills # copies OGP skills to your OpenClaw workspace
ogp setup # configure your identity and gateway URLThen:
ogp start --background
ogp expose --background # creates a public tunnel via cloudflared or ngrok
ogp status # shows your public federation URLShare that URL. Anyone with OGP installed can send you a federation request.
The First Cross-Border Test
The local demo worked. The real test was whether it would work across the internet between two people who had never shared a system.
Stanislav Huseletov, a VP of AI based in Spain, installed the package and connected. The first attempt surfaced a series of real-world issues that the local demo had never hit: tunnel URLs changing on every restart, approval callbacks sending empty bodies, peer IDs mismatching between the two sides. None of these were fundamental protocol problems; they were implementation gaps that only show up when two independent instances talk to each other for the first time.
Each one got fixed in real time:
Approval endpoint updated to accept both the package format and the original fork format
Outbound approval now sends both formats for maximum compatibility
Daemon now stores pending outbound requests so it can recognize approval callbacks
Fallback logic added for when peer IDs don’t match exactly
After about two hours of debugging, the handshake completed. Then this happened:
[2026-03-20 11:25:41] [OGP] Message from Stanislav: Hello Junior, can you hear me?“Junior” is my OpenClaw agent. Stanislav’s message traveled from his terminal in Spain, through his OGP daemon, across the internet, through an ngrok tunnel, into my OGP daemon, through openclaw system event, and landed as a notification in my AI agent’s session.
Two AI gateways. Two countries. One protocol. The message got through.
What This Unlocks
That demo was a message crossing a border. But the same infrastructure handles any intent that benefits from cross-gateway coordination, and the categories compound quickly.
Delegated task execution. An executive’s assistant spawns a task on a specialist agent (“review this contract and flag IP clauses”) without the exec needing to know which agent or gateway handles it.
Federated search. An agent at one organization queries a peer gateway for internal knowledge that would otherwise require a formal API integration. The receiving gateway controls exactly what it exposes.
Cross-org workflows. A procurement agent at Company A interacts with a vendor agent at Company B. Each side retains full control of their own systems. Neither side integrates directly with the other’s tools.
The pattern is consistent: OGP handles trust and transport. The agents handle intelligence. The protocol is deliberately ignorant of what intents actually do. It just ensures they arrive intact, from who they claim to be from, to a gateway that agreed to receive them.
What’s Still Missing
This is an honest accounting, not a press release.
The approval UX needs work. Today it’s a CLI command. It should be a notification in your chat channel (“Stanislav’s gateway wants to connect. One-way or two-way?”) with approval or decline from there. The event-driven notification path exists but isn’t polished.
Intent execution is minimal. The message intent works end-to-end. Calendar scheduling works in the fork but hasn’t been ported to the standalone package yet. The intent registry (register your own custom intents with ogp intent register) is scaffolded but not fully wired.
The companion app (a macOS menubar that shows a green dot when your OGP daemon is running and fires native notifications for federation events) is scaffolded in SwiftUI but not yet built or tested.
Persistent public URLs require either a paid ngrok account or a custom domain with port forwarding. The free cloudflared tunnels work but generate a new URL on every restart, which breaks peer records. This is a real friction point for anyone testing across machines.
Where This Goes Next
The roadmap divides into two categories: things that are technically clear and things that are genuinely hard.
The technically clear work is about completing what’s already started. The doorman layer (an intelligent policy engine that sits between inbound intents and your main agent) is the most important near-term addition. Right now the OGP daemon passes everything to OpenClaw that clears the scope check. The doorman makes that smarter: it decides what’s worth waking your agent up for, enforces rate limits, and ensures a peer’s requests can’t trigger arbitrary turns that run up your token costs. This isn’t complex engineering. It’s just necessary.
Layered trust follows naturally from the doorman. The current model is binary: a peer is approved or not. What’s coming is granular scope with enforcement: not just “you can invoke calendar-read“ but “you can invoke calendar-read up to ten times per day, only during my declared availability window, and the response is normalized to free/busy, not raw event titles.” You grant what you mean to grant.
The harder problems are architectural. Intent negotiation is one: when two gateways peer, they exchange a capability manifest, but they don’t yet agree on payload schemas or version compatibility. We hit this with Stanislav: slight format mismatches that required real-time patches. The fix is a proper negotiation handshake where both sides agree on schemas before the first intent is sent. This is well-understood in API design; applying it to agent-to-agent protocols is the work.
Agentic reply chains are a more fundamental shift. Today, intents are one-shot: I send, you receive, you process, you respond. What’s coming is multi-turn: your agent responds to my intent with a follow-up intent of its own. “I checked David’s calendar. He has three open slots. Which one works for Elon?” The conversation bounces between agents until both sides reach a conclusion. That’s where the protocol starts to look less like an API and more like a conversation between peers.
Discovery is currently manual. You need to know someone’s gateway URL to federate with them, which is fine for people you already know but doesn’t scale. The long-term answer is probably DNS-based: a TXT record at _ogp.example.com that points to a gateway URL, so that knowing someone’s email is enough to find their gateway. No central registry. No intermediary. Just DNS.
The enterprise case is where this gets interesting — but probably not in the way you would expect.
The tempting assumption is that enterprises will build a centralized gateway: one front door for the whole company, routing intents to the right department. Legal review goes to legal. Procurement quotes go to procurement. One address, internal routing.
That might happen as a first-pass implementation. But the more natural endpoint looks different: every employee has their own gateway. Their agent knows their context, their preferences, their work relationships. OGP lets those gateways federate with each other — inside the company and across company lines — peer to peer, relationship by relationship.
When a lawyer needs a contract reviewed by a colleague who handles IP, her gateway federates with that colleague’s gateway directly. When procurement needs a quote from a vendor, their agent federates with the vendor’s agent. The work happens between individual gateways, not through a central switchboard.
What the enterprise owns is the policy layer: who can federate with whom, what intents are permitted across what relationships, what requires human approval before a connection is established. Not a single gateway that represents the company, but the rules under which its people’s gateways can connect.
This maps more closely to how organizations actually work: through relationships between people, not through a central router. OGP just makes those relationships computable.
What This Is (and Isn’t)
OGP is not a standard. It’s not an RFC. It doesn’t try to solve every edge case.
What it is: a working implementation of the minimal infrastructure needed for AI agents to coordinate across trust boundaries. Built in public. Rough in places. Getting smoother.
The repo is at github.com/dp-pcs/ogp. The protocol design is at dp-pcs/openclaw-federation. Both are public. Contributions welcome. Stanislav already filed the first round of real-world bugs by installing it and watching it break.
The standards bodies will eventually get here. They always do. But by the time a formal specification exists, the patterns will have been discovered by people building real things against real problems.
The message already crossed the border. That’s what early innings looks like.
David Proctor is VP of AI at Trilogy. He writes about AI infrastructure, enterprise automation, and what actually works in production.
Super cool alpha! We would love to use it at MoltPod for our agentic economic network. Starred and following!