Home
Trilogy AI CoE
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:
Legal
A law firm's agent coordinating document review with a client's agent
Healthcare
A hospital's scheduling agent working with an insurance company's authorization agent
Construction
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. Two AI gateways — one running on Telegram, one on Slack — connected through OGP. Signed intents flow between them; neither gateway exposes its agent directly. At its core, OGP is four things:
1
Cryptographic identity per gateway
Every OGP gateway generates an Ed25519 keypair on first boot. The public key is published at /.well-known/ogp, alongside a capability manifest declaring what intents the gateway supports and the owner's identity.
2
Bilateral trust establishment
Before any agent can send requests to another gateway, both sides perform a handshake: an explicit, human-approved peering. Both sides sign and store each other's public keys. Neither side can be impersonated after trust is established; every subsequent message is signed and verified.
3
Signed intent messages
Requests between gateways are structured as intents (named operations with typed parameters: calendar-read, message, task-create). Each intent message is signed by the requesting gateway's private key. The receiving gateway verifies the signature before dispatching.
4
Controlled information boundaries
The OGP daemon sits in front of your main AI agent, not inside it. It enforces scope: if a peer is approved for calendar-read, they can't invoke message or task-create. Your agent only sees what the daemon passes through. No leakage of sensitive context, no runaway token usage from a peer's requests.
This is deliberately minimal. Enough structure to establish trust and exchange intent, without becoming a governance nightmare to implement. The entire protocol implementation is around 1,400 lines of TypeScript. The bilateral trust handshake: Gateway B sends a signed federation request, a human approves it, the callback confirms both sides. Every subsequent message is verified against stored public keys.
How OGP Relates to A2A
OGP
Federates the independent gateways that agents sit behind. Handles identity, trust, and scope enforcement — all at the gateway before any agent conversation starts.
OGP is the handshake.
A2A
Handles agent-to-agent conversation inside a shared enterprise platform. Structured requests, typed responses, defined semantics for what agents say to each other.
A2A is the conversation.
Start with the baseline: without OGP, your agents stay inside your gateway. Joe's agents stay inside his. Susan's stay inside hers. That isolation is intentional — it's the security model. Your agents never leave your perimeter. OGP federates the gateways. When you federate with Joe, you're not exposing your agent, you're opening a controlled interface that your gateway manages. You decide the scope: maybe Joe's gateway can query your calendar, but can't send messages to your agent directly. The agents don't cross boundaries. The gateways do, on your terms.
Once two gateways trust each other, the agents behind them can coordinate — and that's where A2A becomes relevant. They're not competing. They're sequential. OGP gets the gateways into a trusted relationship. A2A gives the agents a structured way to use that relationship. You need both, in that order.
OGP is to AI gateways what BGP is to internet routers — the protocol that lets independent networks announce their capabilities and establish trusted peering. Without BGP, you have isolated networks. Without OGP, you have isolated AI gateways.
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. The protocol should outlive any single implementation. So the name became "Open Gateway Protocol." Drop the Claw, keep the Open.
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.
But baking a protocol into a fork creates a maintenance problem. Every OpenClaw update becomes a merge conflict. So the protocol was extracted into a standalone package: @dp-pcs/ogp. The daemon runs alongside your existing OpenClaw installation on a separate port. 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 URL
ogp start --background
ogp expose --background   # creates a public tunnel via cloudflared or ngrok
ogp status                # shows your public federation URL
Share 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.
Approval UX
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
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 (ogp intent register) is scaffolded but not fully wired.
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
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.
Technically Clear
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.
Layered trust follows naturally. 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.
Genuinely Hard
Intent negotiation: when two gateways peer, they exchange a capability manifest, but they don't yet agree on payload schemas or version compatibility. The fix is a proper negotiation handshake where both sides agree on schemas before the first intent is sent.
Agentic reply chains: today, intents are one-shot. What's coming is multi-turn: your agent responds to my intent with a follow-up intent of its own. That's where the protocol starts to look less like an API and more like a conversation between peers.
Discovery is currently manual. 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 tempting assumption is that enterprises will build a centralized gateway: one front door for the whole company, routing intents to the right department. 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.
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)
What it isn't
  • Not a standard
  • Not an RFC
  • 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.
About the Author
David Proctor is VP of AI at Trilogy. He writes about AI infrastructure, enterprise automation, and what actually works in production.