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.
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.
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.
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.
Not the technology. The fact that the work didn't require me to stop being somewhere else.
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.
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.
"Agents talked to each other" undersells what was actually happening.
Stan was directing his agent with questions and goals around the joint idea.
Shadow reached across the federation to Junior, passing along tasks and context.
When I gave Junior a rough reaction to something Shadow had produced, I'd sometimes ask Junior to add its own critique before sending — because two passes of judgment in one message is better than one.
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.
The agents weren't replacing judgment. They were multiplying it. 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.
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.
If you want to run OGP yourself, it's open source and takes about five minutes to get running.
npm install -g @dp-pcs/ogp ogp-install-skillsogp 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 URLogp federation request https://their-gateway-url.comOnce they approve, you're peered. That's the foundation. But federation alone isn't what drove this article — agent-comms is.
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-updatesThen 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 fullThis is the part worth understanding before you turn it on:
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 summaryYour 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.
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.
Your Agent, My Agent