A Shared Common Knowledge Pool for AI Agents

[merafiei80-star]

A Proposal for Extending OMP and MCP with a Public-Domain Memory Layer
Document Type: Technical Specification Proposal / Feature Request
Target Projects: Open Memory Protocol (OMP) & Model Context Protocol (MCP)
Date: July 20, 2026
Submitted by: Mohammad Ebrahim Rafiei
Version: 1.0

1. Executive Summary
   Current AI memory standards—namely the Model Context Protocol (MCP) and the Open Memory Protocol (OMP)—focus primarily on user-specific, private memory . While this approach successfully solves the "AI memory silo" problem for personal context, it overlooks a massive opportunity for optimization and reliability: public-domain knowledge.

We propose a structural extension to both protocols that introduces a Shared Common Knowledge Pool (SCKP)—a vendor-neutral, globally accessible repository for factual, non-proprietary information (mathematics, history, geography, language, literature, etc.). This layer would sit alongside existing private memory stores, enabling any OMP- or MCP-compliant agent to read from and contribute to a collectively maintained knowledge base.

This design reduces redundant computation, lowers energy costs, simplifies validation, and preserves competitive advantage for AI companies in specialized domains.

2. The Problem: Beyond the Private Memory Silo
   2.1. Current State
   Both MCP and OMP successfully address the "memory silo problem":

MCP provides a standardized framework for AI models to connect with external data sources and tools, enabling context persistence and sharing across agent interactions.

OMP offers a vendor-neutral specification for how AI tools store, retrieve, and share memory about users and their context.

However, both protocols currently operate on a private-by-default model. Every AI tool independently:

Computes and stores basic factual knowledge (e.g., "Paris is the capital of France")

Re-trains or re-indexes the same public information

Duplicates effort across thousands of instances

2.2. The Gap
Public-domain knowledge—facts that are not proprietary, not user-specific, and not subject to commercial competition—is treated identically to private user data. This creates:

Massive computational waste: The same facts are stored, embedded, and retrieved millions of times.

Validation fragmentation: Each system independently verifies the same information.

No shared authority: Disagreements on basic facts persist across tools without resolution.

3. Proposed Solution: The Shared Common Knowledge Pool (SCKP)
   3.1. Core Concept
   We propose a third memory layer to complement existing private memory architectures:

Layer Scope Accessibility Update Mechanism
Private Memory User-specific context, preferences, sessions Per-user, per-session User-driven
Shared Common Knowledge Pool (SCKP) Public-domain facts (math, history, geography, language, literature, etc.) Global, read-only for all agents Community-validated, curator-approved
Specialized/Proprietary Memory Domain-specific knowledge (medical, legal, engineering) Per-organization or per-agent Organization-driven
3.2. Key Principles
The SCKP would be designed on principles consistent with both MCP and OMP:

Vendor neutral — no single company controls the standard or the data

Self-hosted first — organizations may run their own mirrors or cache

Privacy by design — no personal or proprietary data enters the pool

Portable — full export/import capability

Auditable — full change history and source attribution

3.3. Architectural Integration with OMP
OMP already provides a robust foundation: a precise definition of memory objects, storage format, and HTTP API. The SCKP would extend this by introducing a new memory_type classification:

json
{
"content": "The speed of light in vacuum is approximately 299,792,458 m/s.",
"type": "semantic",
"scope": "public_knowledge", // NEW FIELD
"domain": "physics",
"verification_status": "verified",
"source": "CODATA 2018",
"confidence_score": 0.99
}
OMP Server Extensions Required:

A new /v1/public/search endpoint for querying the SCKP

A /v1/public/contribute endpoint for submitting validated facts

A public flag in the memory schema

A verification workflow for public contributions

3.4. Architectural Integration with MCP
MCP's architecture—built on JSON-RPC 2.0 with client-server lifecycle management—provides the perfect substrate for the SCKP. We propose:

New MCP Server Feature: public_knowledge

typescript
// Extended MCP server capabilities
{
"capabilities": {
"public_knowledge": {
"read": true,
"contribute": true,
"domains": ["mathematics", "history", "geography", "language", "literature"]
}
}
}
New MCP Message Types:

public_knowledge/query — Request a fact from the SCKP

public_knowledge/contribute — Submit a verified fact

public_knowledge/dispute — Flag a potential error or contradiction

Root Context Integration:
MCP's "root contexts" provide a persistent layer for maintaining shared state across multiple requests and sessions. The SCKP would serve as a global root context—available to all MCP clients and servers by default.

4. Detailed Design Specifications
   4.1. SCKP Data Model
   typescript
   interface PublicKnowledgeEntry {
   id: string;
   content: string; // The factual statement
   domain: string; // e.g., "mathematics", "history"
   subdomain?: string; // e.g., "calculus", "ancient_rome"
   verification_status: "pending" | "verified" | "disputed" | "superseded";
   confidence_score: number; // 0.0 - 1.0
   sources: Source[]; // Citations and references
   created_at: string;
   updated_at: string;
   superseded_by?: string; // Link to newer entry if applicable
   dispute_history?: Dispute[]; // Record of challenges and resolutions
   }

interface Source {
name: string; // e.g., "CODATA", "Encyclopedia Britannica"
url?: string;
publication_date?: string;
authority_score: number; // 0.0 - 1.0, determined by community consensus
}
4.2. Verification Workflow
To ensure quality and reliability, the SCKP would implement a multi-stage verification process:

Submission: Any OMP/MCP-compliant agent can submit a fact.

Automated Validation: Basic checks (format, source credibility, duplication).

Community Review: Open peer review by verified contributors.

Curator Approval: Designated domain experts make final decisions.

Publication: Approved facts enter the SCKP with full attribution.

Dispute Resolution: Any agent can flag errors; disputed entries are temporarily downgraded pending review.

This model aligns with MCP's existing governance structures, including the SEP (Specification Enhancement Proposal) process for major changes.

4.3. Conflict Resolution
Building on the sophisticated conflict resolution principles previously discussed, the SCKP would maintain versioned knowledge:

Historical facts are preserved with clear date markers.

Superseded facts are retained but flagged (e.g., "This was believed true until 2023").

Disputed facts show both sides with source attribution.

When an AI agent queries the SCKP, it receives:

The current consensus (if any)

Confidence score

Alternative viewpoints (if disputed)

Full source chain

5. Benefits and Rationale
   5.1. For the AI Ecosystem
   Eliminates redundant computation — facts computed once, used everywhere

Reduces energy consumption — aligns with global sustainability goals

Lowers barriers to entry — smaller AI companies benefit from shared knowledge

Accelerates innovation — teams focus on specialized problems, not basic facts

5.2. For Users
Consistent answers across all AI tools

Higher accuracy through collective validation

Transparent sourcing — know where facts come from

No vendor lock-in — switch tools without losing access to reliable knowledge

5.3. For AI Companies
Preserved competitive advantage — proprietary and specialized knowledge remains private

Reduced infrastructure costs — less need to store and compute public facts

Improved trust — users see commitment to open, verifiable knowledge

Network effects — contributions to the SCKP benefit the entire ecosystem, including their own models

5.4. Alignment with OMP and MCP Values
OMP Principle SCKP Alignment
Vendor-neutral specification SCKP is governed by open community, not any single company
Self-hosted first Organizations may run mirrors; data is exportable
Privacy by design Only public-domain facts enter the pool
Portable Full import/export of knowledge
MCP Capability SCKP Alignment
Context persistence Public facts are permanently available
Context sharing All agents share the same factual foundation
Standardized tool access SCKP is accessible via standard OMP/MCP interfaces
6. Implementation Roadmap
Phase 1: Specification Definition (Months 1-3)
Define SCKP data model and API extensions

Create OMP schema extensions for public memory type

Define MCP capability extensions for public_knowledge

Establish verification workflow and governance model

Phase 2: Reference Implementation (Months 4-8)
Extend OMP reference server with SCKP support

Create MCP server adapter for SCKP

Build initial curated knowledge base (seed data from public sources)

Develop validation and dispute resolution tools

Phase 3: Community Onboarding (Months 9-12)
Open SCKP for community contributions

Establish domain expert curators

Integrate with major AI tools (Claude, ChatGPT, Cursor, etc.)

Launch public API and documentation

Phase 4: Scaling and Optimization (Months 13-18)
Implement caching and mirroring for global performance

Develop advanced conflict resolution algorithms

Expand domain coverage

Create educational materials and best practices

7. Governance Model
   We propose a three-tier governance structure:

Technical Steering Committee — Maintains protocol specifications, approves major changes.

Domain Curators — Subject matter experts who validate and approve entries in their domain.

Community Contributors — Any OMP/MCP-compliant agent or human can submit facts, disputes, and improvements.

This model draws from successful open-source and open-data projects (Wikipedia, Creative Commons, IETF) and aligns with MCP's existing SEP process for specification changes.

8. Challenges and Mitigations
   Challenge Mitigation
   Defining "public knowledge" Clear criteria: facts that are (a) not proprietary, (b) not user-specific, (c) supported by consensus or authoritative sources
   Quality control Multi-stage verification; community oversight; clear dispute process
   Cultural/regional differences Allow for contextual flags (e.g., "This is the US historical perspective"); maintain multiple versions where appropriate
   Gaming the system Reputation-based contribution limits; proof-of-work for submissions; human oversight
   Cost of operation Distributed hosting model; optional mirrors; cost shared by participating organizations
   Competitive concerns Clear separation: SCKP contains only public facts; proprietary knowledge remains private
9. Conclusion
   The Shared Common Knowledge Pool (SCKP) represents a natural and necessary evolution of both the Open Memory Protocol (OMP) and the Model Context Protocol (MCP) . By extending these standards to include a public-domain memory layer, we can:

Eliminate redundant computation across the AI ecosystem

Improve accuracy through collective validation

Lower costs for all participants

Preserve competitive advantage in specialized domains

Build trust through transparency and open governance

This proposal does not replace existing private memory systems—it complements them. Just as the web has public websites and private intranets, the AI memory ecosystem should have public knowledge pools and private memory stores, connected through open protocols.

We respectfully submit this proposal for consideration by the OMP and MCP communities, and welcome discussion, feedback, and collaboration on its implementation.

Prepared by: Anonymous Contributor
In collaboration with: Community discussion (July 2026)

[SMJAI]

Thank you for this - a detailed proposal as the first issue on the repo is exactly the kind of engagement I was hoping for.

The three-tier architecture you describe is genuinely interesting. The separation of private memory, public facts, and domain knowledge is a clean model and I can see the logic of not recomputing the same facts across thousands of agents.

That said, I want to be honest about why SCKP feels out of scope for OMP specifically.

OMP's core premise is that user-specific context - preferences, decisions, conversations, projects - should travel with the user across tools without being owned by any single vendor. The problem it solves is personal and private: your AI tools forget you when you switch between them.

The public knowledge layer you are describing is a different problem, and arguably one that is already partially solved. LLMs have general factual knowledge baked in at training time. Structured public knowledge at scale already exists in the form of Wikidata, DBpedia, and similar projects. The gap is not that agents lack access to the fact that Paris is the capital of France - it is that they lack access to what YOU told them last Tuesday.

The verification and curation system you propose is also a substantial undertaking in its own right - multi-stage review, dispute resolution, versioned knowledge - that would make OMP responsible for problems well beyond memory portability.

What I would say is this: the three-tier model is worth keeping as a framing for the spec. OMP handles tier one today. Tier three (domain-specific knowledge) is something tool builders can implement on top of OMP. Tier two is out of scope for this project but would be a compelling standalone initiative if you want to drive it.

Would genuinely welcome you contributing to the core spec or building an adapter. What tool or framework are you working with?

[merafiei80-star]

Hi
Thank you for your interest in my idea. Where do you think is the best place to present it?

[SMJAI]

Great to hear you want to contribute to OMP directly.

The best place to present a spec proposal like this is as a GitHub Discussion rather than an issue. Issues are for bugs and concrete actionable items - a new architectural idea like SCKP benefits from open conversation first before it becomes a spec change.

Go to the Discussions tab on this repo, open a new discussion under the Ideas category, and lay out the three-tier model with as much detail as you have. Schema proposal, API additions, how it would extend the existing OMP memory object - the more concrete the better.

Once there is community agreement on the direction, the right next step would be a pull request against SPEC.md with the actual proposed changes.

Looking forward to seeing it fleshed out.