Home
Trilogy AI CoE
The Project Layer: Shared Workspaces Across Independent Agents
How two agents built something together without sharing a filesystem, a login, or a secret.
When Does Messaging Actually Matter?
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
The Setup
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.
What Happened Next
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.
"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:
1
A Unique ID
e.g., aicoe-expert-network or instacrew-collab — a stable identifier for the shared context.
2
A Membership List
Which gateways are admitted. Membership is explicit, checked on every query, and controlled by the project owner.
3
A Topic Vocabulary
Structured categories within the project — like property-data — that organize contributions semantically.
4
A Contribution Log
Timestamped, signed summaries from each participant. Stored locally on each member's gateway, not in a central server.
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, or ~.ogp/projects.json depending on which framework the daemon is running alongside.

This is federation, not centralization. A hub-and-spoke model is a convenient pattern, 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:
project.join
Request admission to a project. The project owner approves.
project.contribute
Add a structured summary to a project topic.
project.query
Ask what a peer (or the project) knows about a topic.
project.status
Get the current state of all topics in the project.
Here's what a contribution looks like on the wire — a signed, structured intent carrying a human-readable summary, typed metadata, and an identity snapshot:
{ "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. 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?
The Rule
OGP's answer is strict project isolation enforced at the Doorman layer. 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.
The Test
We validated this with a 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.
The Result
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.
The Invariant
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.

This is the difference between security through obscurity and security through enforcement. The AWS node knows the project exists — but knowing it exists and accessing its data are separated by an explicit membership check.
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?
The Problem
Key rotation changes a peer's gateway ID. Without a solution, contributions become orphaned — linked to a key that no longer exists, with no human context.
The Solution
OGP v0.6.0 introduces identity snapshots. When a peer contributes, their current humanName, agentName, organization, and tags are captured into the contribution record at write time.
The Fallback
The display layer uses a three-tier fallback: snapshot first → peer-registry lookup second → raw peer ID as last resort. In practice, contributions render as David Proctor (Junior) instead of an opaque 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.
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.
How Auto-Push Works
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.
What Shadow Receives
"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.
The Shared Database Problem
  • Requires both sides to have accounts, permissions, and access
  • Requires someone to manage the schema, hosting, and backups
  • Creates a single point of failure and a single point of control
  • If the platform changes pricing or shuts down, your collaboration graph dies
The OGP Project Layer
  • Each side keeps their data where it belongs
  • Share only what you choose to share, in a structured way
  • Explicit membership and signed provenance on every contribution
  • Revocation available at any time — no platform dependency
"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."
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.
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.
Schema Enforcement
Define expected metadata fields per topic, validate contributions at the Doorman layer before they enter the shared context.
Graph Relationships
Link contributions across topics — e.g., "this decision depends on that property-data finding" — enabling richer traversal queries.
Temporal Queries
"What changed in this project in the last week?" — time-scoped queries over the contribution log.
Cross-Project Search
"Which projects do I have with Stan that mention AWS?" — search across the full federation graph, not just a single project.

But the foundation is solid: shared context, explicit membership, signed contributions, local storage, federated queries. That's enough to build real collaboration on.
About
David Proctor
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.
Get Started
Install the OGP package globally and start federating your agents today:
npm install -g @dp-pcs/ogp
Further Reading
The AI CoE Expert Network deployment and the delegated-authority work referenced in this article are covered in the companion piece published earlier this week.
OGP
Federation
Agent Collaboration
Project Layer