Your Agent, My Agent
What federated AI actually looks like when it stops being a demo and starts being a workday
If you haven’t read the OGP piece, start there - icing without the cake doesn’t work. You need the foundation. This article is the “so what.”
Here’s the so what: earlier today, Stanislav Huseletov - a fellow VP of AI - and I built something together. Named it. Bought the domain. Got a landing page live. Created a GitHub repo with brand assets. Iterated on design. Gave and received feedback. Got revisions deployed.
We never messaged each other once.
The backstory is quick. OGP is my latest brainchild - a protocol for letting AI agents communicate across gateway boundaries. Stan has been a genuinely valuable guinea pig and sounding board throughout. He asks the right skeptical questions and is willing to be first in line when something might not work yet. That’s not nothing. But when we both had a joint idea we wanted to flesh out, we made a deliberate choice: instead of scheduling a call and setting up a shared repo beforehand, we wanted to see how much we could offload naturally - just by working as we normally would.
The point wasn’t to “let the agents run.” It was to keep working as we normally do while the agents handled the coordination layer. What happened next is the result of that.
I had ended a meeting. Had a couple hours before the next one. Stepped away to do some chores instead of grinding out async work like I’d been trying to do for the past week. Not a formal collaboration session. Not blocked time. Just a window.
In that window, Stan was tasking his agent, Shadow, with questions about the joint idea we’d been kicking around. Shadow reached across the federation to Junior. Junior surfaced decisions to me when they needed direction - a Telegram message here, a quick confirmation there. I was doing chores. I was responding in between.
Domain purchased. Repo created - unplanned, but it made sense, so it got created. Landing page deployed. The deliverables weren’t the product of a structured session. They were the product of two people working as they normally would while their agents handled the coordination layer in between.
In two hours, we made more progress on this idea than in the past week combined.
The moment that crystallized it for me happened when I was at the grocery store.
Junior sent me a notification: federation was up, but the project wasn’t joined. I typed a quick message - tell Shadow’s agent how to join - and kept walking through the store. A few seconds later, Shadow joined and started building. I didn’t stop. I didn’t get on a call. I didn’t open a laptop. I sent one message to my agent from the cereal aisle and the work started.
That’s the unlock. Not the technology. The fact that the work didn’t require me to stop being somewhere else.
Before someone asks: no, the agents weren’t just running loose.
Agent-comms in OGP is intent-based, topic-scoped, and user-approved. I approved the federation. I set the scope. The communication happened within those bounds, on that topic, with that counterpart. Junior and Shadow didn’t spontaneously decide to start collaborating on whatever they felt like, they operated within a channel I opened and authorized. If I hadn’t approved the federation, nothing would have happened.
This matters more than it might seem. The “runaway agents” worry is real and worth taking seriously. The design answer is guardrails built in from the start, not bolted on later. Scoped comms, explicit approval, defined intent. You’re not handing your agent a phone and saying “figure it out.” You’re giving it a walkie-talkie tuned to one frequency, for one conversation, with one person’s agent you already know.
The coordination model itself is worth describing, because “agents talked to each other” undersells what was actually happening.
Stan was tasking Shadow. Shadow was coordinating with Junior. Junior was relaying to me, sometimes with its own layer of review added on top of my raw feedback before it went back across the wire. When I gave Junior a rough reaction to something Shadow had produced, I’d sometimes ask Junior to add its own critique before sending, not because I was lazy, but because two passes of judgment in one message is better than one. The agents weren’t replacing judgment. They were multiplying it.
Neither of us was ever waiting on the other. Stan didn’t know when I’d respond. I didn’t know when Stan would be back at his desk. It didn’t matter. The agents held the thread between us, kept context warm, and moved when either of us moved. The humans weren’t bottlenecks. We were signal sources. The agents were the bandwidth.
We were both working. We were both involved. We just weren’t waiting on each other.
I’ll be honest about where the protocol is still rough.
OGP also has a project intent layer - a shared project record both agents can read and write, logging decisions, progress, open questions. In theory, that’s what makes this more than a fancy chat protocol. Shared memory, not just shared messages.
In practice, during this session, it was thin. One contribution logged. The peer sync had some rough edges - a join handshake that didn’t fully complete, auto-push that didn’t fire. The heavier lifting happened through agent-comms, not through the shared project record. The agents were coordinating in real time because they were talking, not because they both knew the full history.
That’s the honest version. And it points at the next article: what this session looks like when shared project memory is fully working. When Shadow doesn’t need Junior to relay every decision because Shadow already has the project context. When the agents need fewer messages because they share state, not just a channel. That version is a different, better collaboration - and it’s where the protocol is headed.
What we built today was real. Not a test scenario. Not a sandbox with fake data and no stakes. A named thing, with a domain, a landing page, and a repo that didn’t exist this morning.
Neither of us attended the build meeting. Our agents did.
Try It
If you want to run OGP yourself, it’s open source and takes about five minutes to get running.
Install:
npm install -g @dp-pcs/ogp
ogp-install-skills
Configure and start:
ogp setup # interactive wizard — sets port, OpenClaw URL, your API token, display name
ogp start --background
ogp expose --background # starts a cloudflared tunnel, gives you a public URL
Federate with a peer:
ogp federation request https://their-gateway-url.com
Once they approve, you’re peered. That’s the foundation. But federation alone isn’t what drove this article — agent-comms is.
Enabling Agent-Comms
Agent-comms is the layer that lets your agent and a peer’s agent have an actual conversation — not just a one-way message, but a scoped, topic-routed exchange your agents can initiate without you being in the loop.
When you approve a peer, include agent-comms in the scope grant:
ogp federation approve peer-stan --intents message,agent-comms --topics general,project-updates
Then configure how your agent responds to incoming agent-comms from that peer:
# See current policies
ogp agent-comms policies
# Set a global default
ogp agent-comms default summary
# Open up specific topics more freely for a trusted peer
ogp agent-comms configure stan --topics general,project-updates --level full
What the response levels actually mean
This is the part worth understanding before you turn it on:
Level What happens full Your agent responds openly and shares details — treat this like a trusted colleague summary Your agent gives high-level responses only — good default for most peers escalate Your agent asks you before responding — useful for sensitive topics deny Your agent politely declines to discuss that topic off Default-deny: sends a signed rejection and doesn’t process the message at all
The default out of the box is summary for approved topics. That’s a reasonable starting point — your agent will engage but won’t overshare.
If you want a tighter posture, set off as your global default and explicitly allow only the topics you’ve thought about:
ogp agent-comms default off
ogp agent-comms configure --global --topics "general,project-updates" --level summary
When a topic hits off, the daemon sends a cryptographically signed rejection back to the sender rather than silently dropping the message. The peer knows it was rejected — they don’t just wonder if something broke.
What to expect when it works
Your agent will start receiving agent-comms messages from the peer’s agent. Depending on your OpenClaw setup, you’ll see them surface as notifications — Telegram messages, system events, whatever your delivery channel is. Your agent handles them according to the policies you set, and replies go back across the federation automatically.
The session in this article — Stan’s Shadow reaching Junior with project questions, Junior surfacing decisions to me — that’s what this looks like in practice. You stay in the loop on what matters. The rest moves without you.
GitHub: github.com/dp-pcs/ogp
Protocol spec: github.com/dp-pcs/openclaw-federation
npm: @dp-pcs/ogp
David Proctor is a Vice President of AI for Trilogy. OGP (Open Gateway Protocol) is an open standard for federated agent communication across AI gateway deployments.