[Framework] How Two Agents Collaborated Without Sharing a Repo, Login, or Secret
OGP’s Project Layer creates shared workspaces across independent agents without breaking local boundaries.
The most common question I get about OGP is some variant of: "Okay, so your agents can send messages. Big deal. When do they actually do something together?"
Fair question. Messaging is table stakes. The interesting problem is shared state: two agents, two humans, two machines, two organizations, working on the same thing without either side giving up control of their boundary.
This is what the Project Intent Layer was built for. And last month, it got its first real production workout.
The Scenario
Stan and I were both researching property valuation APIs for a proof of concept project. We live in different countries, run different agent frameworks, and have never shared a repo or a login.
I started first. I found Attom's API, got a free trial key, tested it against two addresses, and started sketching a valuation tool. I told my agent, Junior: "Log what I've done so far. Attom free trial, 2 addresses tested, tool in progress."
Junior structured that into a contribution and posted it to the `instacrew-collab` project under the `property-data` topic.
Stan's agent, Shadow, was already a member of that project. Without Stan asking, Shadow queried the project before starting its own research: "Does anyone in this project have work on property-data?"
The answer came back: "David started this three days ago. Attom free trial key (not shared, just noted that it exists). Two addresses tested. Valuation tool 70% done. Relevant note: Attom free tier doesn't include comps."
Stan told Shadow to build on that instead of starting from scratch. No message to me. No shared Google Doc. No Slack thread. Two agents prevented duplicate work across two countries using a shared, structured, federated workspace.
That's the Project Layer in one paragraph.
What It Is, Precisely
A project in OGP is a named shared context with four components:
A unique ID — e.g., `aicoe-expert-network` or `instacrew-collab`
A membership list — which gateways are admitted
A topic vocabulary — structured categories within the project
A contribution log — timestamped, signed summaries from each participant
The key architectural decision: project data lives on every member's gateway, not in a central server. When you contribute, your agent stores it locally in your gateway's config directory
`~.ogp-openclaw/projects.json``/.ogp-hermes/projects.json``~.ogp/projects.json` depending on which framework the daemon is running alongside. When another member queries, their agent asks your gateway for relevant contributions via OGP's signed intent protocol. There's no central database to compromise, no shared cloud account to manage, no single point of failure.
This is federation, not centralization. A hub-and-spoke model — like the AICOE Expert Network deployment that runs alongside the delegated-authority work I wrote about earlier this week — is a convenient pattern where a central gateway aggregates and serves queries. But the protocol doesn't require a hub. You could run a full mesh where every member talks directly to every other member. The hub is just one topology choice among many.
The Four Project Intents
OGP defines four intents for project collaboration:
1. project.join — Request admission to a project. The project owner approves.
2. project.contribute — Add a structured summary to a project topic.
3. project.query — Ask what a peer (or the project) knows about a topic.
4. project.status — Get the current state of all topics in the project.
Here’s what a contribution looks like on the wire:
{
"protocolVersion": "0.2.0",
"intentId": "550e8400-e29b-41d4-a716-446655440000",
"type": "project.contribute",
"from": "302a300506032b65...",
"to": "1a2b3c4d5e6f7890...",
"payload": {
"projectId": "instacrew-collab",
"topic": "property-data",
"entryType": "progress",
"summary": "Attom API free trial, 2 addresses tested, valuation tool 70% done. Free tier doesn't include comps.",
"authorIdentity": {
"humanName": "David Proctor",
"agentName": "Junior",
"organization": "Trilogy"
},
"metadata": {
"api": "Attom",
"tier": "free",
"addressesTested": 2,
"toolProgress": 0.7,
"blocker": "Free tier lacks comps"
}
},
"timestamp": "2026-04-16T14:32:00Z",
"nonce": "a1b2c3d4",
"signature": "base64url-ed25519-sig"
}The package version is `0.6.0`, but the wire protocol intentionally moves slower `0.2.0` is the current handshake/intent version, deliberately stable so peers running different package versions can still federate. The payload includes a `summary` (human-readable), structured `metadata`, and an `authorIdentity` snapshot (more on that in a moment). The receiving agent can use any of these. A query like "What APIs have we tested for property data?" matches the `topic` context. A query like "What's the blocker on David's valuation tool?" matches the summary text or the `blocker` metadata.
Isolation, Not Just Sharing
The hardest problem in shared workspaces isn't sharing, it's not sharing. When you have multiple federation relationships, how do you ensure that Project A's data doesn't leak to a peer who is only in Project B?
OGP's answer is strict project isolation enforced at the Doorman layer. The rule is simple: a gateway will only return project contributions to peers who are explicit members of that project. Membership is checked on every query. There is no implicit access through other federation relationships.
We validated this with the three-node test: Synapse (Colorado), Starbridge (Spain), and an AWS ECS node in us-east-1. Synapse and Starbridge shared a project. The AWS node was federated with Synapse but not in the project. When the AWS node queried Synapse for project data, the Doorman returned `403 Forbidden, You are not a member of this project`. Not silent empty results, not a generic "permission denied" a structured rejection at the membership-check layer that tells the calling agent exactly why it failed and gives the human on the other side something actionable to surface.
This is the difference between security through obscurity and security through enforcement. The AWS node knows the project exists (because Synapse's capabilities advertise `project.query`). But knowing it exists and accessing its data are separated by an explicit membership check.
Is this formally provable? Not yet, we don't have a TLA+ model or ProVerif script. But the isolation property is straightforward to argue: the Doorman checks `project.members.includes(peerId)` before any project data leaves the gateway. If the peer isn't in the set, no data flows. The set is controlled by the project owner. Therefore, the owner controls the isolation boundary. It's a simple invariant, but one that many collaboration tools violate by accident through over-eager sharing defaults.
Identity Snapshots
One subtlety: what happens when a peer's identity changes? If Stan rotates his keypair, his gateway ID changes. But he's still Stan. Should all his contributions become orphaned?
OGP v0.6.0 solves this with identity snapshots. When a peer contributes to a project, their current `humanName`, `agentName`, `organization`, and tags are snapshot into the contribution record at write time. Even if the peer later rotates keys or changes aliases, the contribution retains the identity context from when it was created.
The display layer uses a three-tier fallback when rendering authorship: snapshot first (the identity captured at contribution time), peer-registry lookup second (the peer's current identity if no snapshot exists), and the raw peer ID as a last resort. In practice, contributions render as `David Proctor (Junior)` human name first, agent name parenthesized instead of an opaque `302a300506032b65...` fingerprint.
This sounds like a small detail until you're auditing a decision six months later and need to know who contributed a piece of information, not just which key signed it. Two companion commands shipped alongside: `ogp whoami` shows your current identity and which keypair the daemon will sign with, and `ogp federation update-identity <peer>` actively pushes your refreshed `humanName` / `agentName` / `organization` to an already-approved peer over a signed endpoint, so you can rebrand without re-federating.
Auto-Push and Proactive Awareness
The most interesting behavior is what happens when you're not asking questions.
When I contribute a new property-data finding, my agent doesn't wait for Stan to query. It iterates the set of approved peers who are also members of this project and sends each one a signed `project.contribute` intent directly, no broker, no queue, no fan-out service. The intent carries the same payload that just got written to my local store, so Stan's gateway ends up with a copy of my contribution as if Shadow had queried for it. Shadow receives a signed notification: "David contributed to instacrew-collab/property-data: Attom API free trial, 2 addresses tested, tool 70% done. Blocker: free tier lacks comps."
Shadow can ignore it, summarize it for Stan, or proactively integrate it into recommendations. The default is `summary` Stan gets a brief digest, not a full dump of every contribution.
This creates ambient awareness without ambient noise. Both agents know what's happening in the shared context. Both humans stay informed at a level they configured. Nobody is surprised by duplicate work, and nobody is drowning in notifications.
Why Not Just Use a Shared Database?
The obvious alternative is a central Notion, a shared GitHub repo, a Slack channel, or a traditional database. All of those work. None of them solve the actual problem.
A shared database requires both sides to have accounts, permissions, and access. It requires someone to manage the schema, the hosting, the backups. It creates a single point of failure and a single point of control. If the company that owns the platform changes its pricing or shuts down the feature, your collaboration graph dies.
More importantly: a shared database violates the boundary preservation principle that OGP is built on. I don't want Stan to have access to my local files, my API keys, or my personal notes. I want to contribute structured summaries of my knowledge into a shared context, on terms I control, with revocation available at any time.
The Project Layer is not "let's all put our stuff in one place." It's "let's each keep our stuff where it belongs, and share only what we choose to share, in a structured way, with explicit membership and signed provenance."
That's a different thing entirely.
What's Next
The current project system is intentionally minimal. Topics are freeform strings. Metadata is JSON-shaped but not schema-enforced. Query is full-text search over summaries, not a graph traversal.
Future directions:
Schema enforcement: Define expected metadata fields per topic, validate contributions at the Doorman layer
Graph relationships: Link contributions across topics ("this decision depends on that property-data finding")
Temporal queries: "What changed in this project in the last week?"
Cross-project search: "Which projects do I have with Stan that mention AWS?"
But the foundation is solid: shared context, explicit membership, signed contributions, local storage, federated queries. That's enough to build real collaboration on.
David Proctor is VP of AI at Trilogy. Project collaboration ships with every OGP installation. The AI CoE Expert Network referenced above is one of the running projects from earlier this week's article on delegated authority. Install: `npm install -g @dp-pcs/ogp`