Architecting a Shared Cognitive Memory Layer
for Enterprise AI Infrastructure

Part I — Foundation

1. The Enterprise Memory Problem

1.1 The Statelessness Gap

Large language models are stateless. Each inference call begins with a blank slate, bounded by a finite context window. This creates a fundamental disconnect between the growing ambitions of AI agents—which must sustain coherent behavior over hours, days, and weeks of interaction—and their inability to remember, learn, or adapt from past experience.

In enterprise settings, the consequences are severe:

• Agents forget everything between sessions. A coding agent that learns a team's deployment conventions today starts cold tomorrow.
• No organizational learning. When fifty engineers teach their agents the same lesson, nobody benefits from collective learning. Each agent is an island.
• Compliance exposure. There is no way to audit what an agent "knew" when it took an action, making forensic reconstruction impossible for regulated industries.
• Token waste and context limits. Injecting everything into the prompt wastes tokens; injecting nothing causes amnesia.

1.2 The Patchwork Anti-Pattern

Today, every team building a production AI agent assembles the same ad-hoc architecture: a vector database for embeddings, Redis for session state, PostgreSQL for user profiles, and custom glue code to stitch them together. This patchwork—replicated across thousands of organizations—fails at precisely the capabilities agents need most:

• Multi-session reasoning. The vector store doesn't know about the session store.
• Temporal understanding. PostgreSQL rows have timestamps but no temporal graph.
• Cross-channel identity. Chat memory doesn't talk to phone memory.
• Learning from experience. Nothing stores what worked or what failed.

1.3 The Enterprise Brain Concept

The industry has begun to converge on a solution: a shared layer of memory and governance that sits beneath all of a company's AI agents, so that what one agent learns is available to every other one instead of disappearing when the session ends. This "enterprise AI brain" is not a better model—it is a brain.

However, this rapid evolution outpaces governance, raising critical concerns about data ownership, security risks such as context poisoning, and the ethical implications of employee data. Experts urge companies to audit AI memory, assign context-layer ownership, and establish clear policies.

2. Architectural Foundations

2.1 Memory Taxonomy

A shared cognitive memory layer must support multiple memory types, each with distinct purposes, access patterns, and lifecycles.

Personalized memory tracks stable information about particular users, teams, or environments: preferences, habits, recurring constraints, and prior interactions. This state must not be collapsed into the agent's general self-improvement store, because user-specific traces obey different retention, retrieval, and privacy rules.

2.2 Architectural Paradigms

Current memory systems can be read as four broad architectural paradigms, progressing from simple to sophisticated:

1. Monolithic Context. All relevant history remains directly in the prompt. Transparent but capacity-limited; state disappears with the session.
2. Context with Retrieval Storage. Near-term working state stays in context while longer-horizon traces are stored externally and retrieved on demand. This is the dominant pattern in production copilots and assistants.
3. Hierarchical Memory and Orchestration. Once flat retrieval proves insufficient, systems introduce memory hierarchies with explicit policies for what gets written, promoted, retrieved, compressed, or forgotten.
4. Adaptive Memory Systems. The most advanced paradigm, where memory operations (ADD, UPDATE, DELETE, NOOP) are learned through reinforcement learning, enabling the system to optimize its own memory management.

The enterprise architecture proposed in this paper operates at the Hierarchical Memory and Orchestration level, with provisions for adaptive optimization.

3. The Multi-Scope Memory Model

3.1 Scope Definitions

The core innovation of this architecture is its explicit, multi-dimensional scoping model. Every memory record is scoped along multiple axes, ensuring that information flows correctly between different organizational levels while maintaining strict boundaries.

3.1.1 Personal Memory (User-Scoped)

Personal memory belongs exclusively to a single user-agent pairing. It functions as a private workspace containing communication preferences and working style, personal priorities and follow-ups, individual constraints and recurring preferences, and private notes and decision context. These memories are invisible to other users' agents and are subject to the strictest retention and privacy rules.

3.1.2 Team Memory (Group-Scoped)

Team memory is shared across a defined group—a project team, department, or functional unit. It contains business facts and domain knowledge relevant to the team, shared workflows and operational procedures, team-specific conventions and standards, and collective decisions and their rationale. Team memory is the primary mechanism for organizational learning at the group level. Teams follow the organization's role and reporting hierarchy (a team can contain sub-teams); projects (3.1.5) cut across teams.

3.1.3 Agent Memory (Agent-Scoped)

Agent memory allows individual AI agents to build self-knowledge across sessions. This includes what approaches worked and which failed, which tools were most effective for specific task types, strategies that produced the best outcomes, and agent-specific performance patterns. Agent-scoped memory enables agents to improve their own performance over time without requiring human intervention or explicit retraining. Two kinds of agent are covered: agents a person is using, which act with that person's rights, and independent AI bots with their own work identities (for example a Jira account), which take assigned jobs like a team member and always have a named human sponsor.

3.1.4 Organizational Memory (Enterprise-Scoped)

Organizational memory represents the highest level of collective knowledge. It contains company-wide policies and procedures, strategic context and business objectives, cross-team patterns and best practices, and institutional knowledge derived from aggregated experience. Organizational memory is the foundation of the "enterprise brain" concept—a layer that allows all AI agents to learn collectively.

3.1.5 Project Memory (Cross-Team)

Project memory holds requirements, decisions, timelines and deliverables for one initiative. Its members come from many teams, and one or more project leads decide what enters it. Project members read it; project leads write it.

3.1.6 User Memory (Person-Scoped)

User memory holds one person's profile, preferences and history across every AI tool they use, so each of their agents respects the same preferences. It is separate from Personal memory: User memory is shared with the person's delegated agents and can contribute to promotion by rule, while Personal memory stays private.

3.1.7 Client Memory (Client-Scoped)

Client memory holds facts about one client the organization works for: contacts, agreements, preferences and history across that client's projects. Only the people assigned to the client and the members of its linked projects can read it, and it is walled off from every other client. It is restricted by default, can be deleted in one step when the work for that client ends, and client-specific details are removed before any lesson moves beyond it.

3.1.8 The Account Level

Above the organization sits the Account: the customer of the memory platform. One account can own and manage several organizations; its administrators can set account-wide guidance and settings, and see every scope in their organizations except Personal memory, which requires a logged emergency access with a stated reason and notice to the person.

3.2 The Promotion Pipeline

The critical mechanism connecting these scopes is the promotion pipeline—the process by which memories move from lower scopes to higher scopes:

User / Agent → Team → Project → Organizational

Personal memory is never promoted.

Promotion criteria include:

• Frequency. The same insight independently discovered by multiple users or agents.
• Confidence. The memory's confidence score exceeds a defined threshold.
• Reinforcement. The pattern has been validated across multiple contexts.
• Policy fit. The memory aligns with organizational policies and does not contain sensitive data.

When a memory is promoted, it is anonymized to remove user-specific identifying information while preserving the operational insight. For example, "User A prefers tabs over spaces" might be promoted to "The team's codebase convention uses tabs for indentation."

Promotion from User or Agent to Team can happen automatically when at least three independent sources agree, confidence is high and no personal data is found. Promotion to Project or Organizational memory always needs approval by the project lead or organizational governance.

3.3 Inheritance, Synthesis and Downward Sync

• Inheritance. When someone works in a project or team, their AI automatically receives the applicable Account, Organizational, Project, Client and Team memory. Items marked mandatory at a higher scope always win; otherwise the more specific scope wins.
• Downward sync. Every scope carries a version number. When a higher scope changes, every affected user's AI receives the change on its next request; unchanged memory stays cached, and users can force a refresh.
• Lateral synthesis. A background job drafts shared facts from several team memories into project memory, or from several projects into organizational memory. Drafts always need approval.
• Change requests. Any user or bot can ask a higher scope to correct, add or remove a memory; the scope's approver decides. Higher levels can switch these features on or off for each organization, project, team, user or bot.

4. Multi-Tenant Isolation Architecture

4.1 Tenant Boundary Enforcement

In multi-tenant environments, every memory record must carry a tenant boundary so that one account's agents, users, facts, and deletion requests never affect another account. In this architecture the tenant is the Account, which can own several organizations. Tenant isolation should be enforced by the database layer, not just application code.

The architecture enforces this through:

• Row-level security (RLS). Every durable memory row includes a tenant_id column protected by database-level row-level security. Queries cannot accidentally leak across tenants.
• Namespace isolation. Multi-tenancy namespaces are required with no default—an accidentally shared namespace is a data leak, so it must be an explicit decision.
• Storage-level partitioning. Hash-partitioned storage by tenant ensures physical isolation, with HNSW indexes per partition for fast similarity search.

4.2 Scope Hierarchy Within Tenants

Within a single tenant (organization), memory scopes form a hierarchy:

Each memory record carries metadata identifying its scope, and retrieval queries automatically filter based on the requesting user's authenticated scope permissions.

4.3 Cross-Entity Reuse Prevention

A conventional enterprise AI platform may promise that client data is isolated, but the technical architecture may still rely on ordinary database separation, access-control lists, tenant labels, or post-hoc audit logs. These mechanisms do not necessarily prevent a downstream AI workflow from reusing data across entities.

This architecture prevents cross-entity reuse through:

• Authorization continuity. Source restrictions remain effective throughout source-to-memory and memory-to-memory derivation and reuse.
• Transitive lineage. Every memory carries a complete provenance chain linking it to its original source, enabling policy enforcement at every derivation step.
• Policy composition. When memories are combined or derived, their source policies are composed, and the most restrictive policy applies.
• Client walls. Memory about one client is never available to people, agents or bots working for another client, and client details are stripped before any lesson is promoted beyond the client.

Part II — Authorization and Access Control

5. Authorization and Access Control for Multi-Scope Memory

5.1 Hybrid Model Recap

5.1.1 What each layer handles

5.1.2 Why pure approaches are insufficient

• Pure RBAC is too coarse. It cannot express "user can read this specific team memory because they belong to that team" without exploding roles. It also cannot handle nested sharing or delegated agent access.
• Pure ReBAC is strong for relationships but weak for system-level governance. It struggles with global rules such as "only auditors can export memory" or "service agents cannot delete organizational memory."
• Pure ABAC is extremely flexible but complex to author, test, and reason about. Without relationships, every policy must encode membership and ownership manually, leading to policy sprawl.

5.1.3 How the layers interact in a single request

A request passes through three gates in order:

1. RBAC gate. Does the subject have the coarse permission to perform this action on this resource type?
2. ReBAC gate. Does the subject have the required relationship to this specific memory scope?
3. ABAC gate. Given the relationship and role, do dynamic context rules allow the action?

Only if all three pass is the request allowed. This is a deny-by-default pipeline.

5.2 Why Pure Approaches Fail for UGC and Multi-Scope Memory

User-generated content platforms with multi-scope memory combine three properties that no single model handles well:

• Nested and shared content. Memories live in personal, team, agent, and organizational scopes, and may be shared, promoted, or delegated. This is inherently a relationship graph.
• System-level governance. Tenants, roles, service accounts, and administrative functions require coarse, stable, auditable permissions.
• Dynamic context. Sensitivity labels, data residency, purpose limitation, and time-based restrictions require runtime evaluation that neither roles nor relationships can express alone.

The hybrid model is not a preference—it is a necessity. Each layer covers the blind spots of the others:

5.3 Mapping to the Codebase

5.3.1 Where each authorization layer lives

5.3.2 Which entities, tables, services, and modules are involved

The memory object table should include scope and ownership metadata. The following sketch is consistent with the schema in Part I and adds authorization-relevant fields:

memory_objects (
  id UUID,
  tenant_id UUID,
  scope_type ENUM('personal','user','agent','team','project','client','org','account'),
  scope_id UUID,
  owner_id UUID,
  sensitivity_label TEXT,
  policy_tags JSONB,
  content TEXT,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

A relationship table supports the ReBAC layer:

relationships (
  id UUID,
  tenant_id UUID,
  subject_type ENUM('user','agent','bot','team','org'),
  subject_id UUID,
  relation TEXT,          -- e.g. 'member_of', 'owner_of', 'delegated_to'
  object_type ENUM('team','project','client','memory','agent','org','account'),
  object_id UUID,
  created_at TIMESTAMP
)

RBAC tables support coarse governance:

roles (id, tenant_id, name)
permissions (id, name, resource_type, action)
role_permissions (role_id, permission_id)
user_roles (user_id, role_id, tenant_id)

5.3.3 What checks happen at each layer, and in what order

1. Authenticate → resolve user_id, tenant_id, agent_id if present.
2. RBAC check → e.g. can(user, 'memory:read', 'team_memory').
3. ReBAC check → e.g. has_relation(user, 'member_of', team_id).
4. ABAC check → e.g. sensitivity == 'internal' AND purpose == 'support' AND time within business_hours.
5. Enforce → allow or deny; log the decision.

5.3.4 Changes needed to data models, APIs, or middleware

• Add scope_type, scope_id, owner_id, sensitivity_label, policy_tags to memory records.
• Add a relationships table or graph store.
• Add an authorization middleware that injects an AuthzContext into every request.
• Add a POST /authorize internal endpoint or SDK for the memory service to call.
• Add audit fields to every memory operation: authz_decision_id, policy_version.

5.4 Data Models and Entities

The authorization model touches four categories of entities. Each is summarized below with its role in the hybrid pipeline.

5.4.1 Subject model

Subjects may be human users or autonomous agents. Both must be first-class principals with stable identifiers. Agents should carry a delegation relationship to their owning user or team, which the ReBAC layer uses to resolve access.

Every principal has a type: human, delegated_agent (acts for a person, never with more rights than that person), bot (independent, with its own identity and a human sponsor) or service. Each request also carries a caller context: the verified identity, type, the person being acted for and the client application, plus declared values such as the model name, current project, purpose and token budget. Only verified values decide access; declared values can narrow access and shape the response, and all of them are recorded in the audit trail.

5.4.2 Resource model

Memories are the primary protected resource. Teams and organizations are also resources for membership and administrative actions. Each memory carries its scope metadata, which determines which relationship and policy checks apply.

5.4.3 Relationship model

Relationships form a directed graph. The most important relations for the multi-scope memory architecture are:

• member_of — user or agent to team
• owner_of — user or agent to memory
• delegated_by — agent to user
• parent_of — team to sub-team
• auditor_of — user to tenant

5.4.4 Context model

The context object is assembled per request and passed to the ABAC evaluator. It should include only the attributes needed for policy evaluation, and it should be treated as untrusted input unless cryptographically attested.

5.5 Request Decision Flow

5.5.1 Step-by-step flow from authentication to final allow/deny

1. Request arrives at API gateway.
2. Authentication middleware validates token/session.
3. Authz middleware builds AuthzContext:
   - subject: user_id, agent_id, roles
   - resource: memory_id, scope_type, scope_id, owner_id
   - action: read | write | delete | share | promote
   - environment: time, IP, purpose, device, data_residency
4. RBAC gate: coarse permission check.
5. ReBAC gate: relationship path check.
6. ABAC gate: policy evaluation.
7. Decision: allow or deny.
8. If allow, memory service executes.
9. Audit log records decision, reason, policy version, relation path.

5.5.2 Pseudo-code

def authorize(ctx: AuthzContext) -> Decision:
    # 1. RBAC
    if not rbac.check(ctx.subject, ctx.action, ctx.resource_type):
        return Deny("RBAC: missing coarse permission")

    # 2. ReBAC
    relation_path = rebac.find_path(
        subject=ctx.subject,
        relation=ctx.required_relation,
        object=ctx.resource_scope
    )
    if not relation_path:
        return Deny("ReBAC: no relationship to resource")

    # 3. ABAC
    abac_decision = abac.evaluate(
        subject=ctx.subject,
        resource=ctx.resource,
        action=ctx.action,
        environment=ctx.environment,
        relation_path=relation_path
    )
    if not abac_decision.allowed:
        return Deny(f"ABAC: {abac_decision.reason}")

    return Allow(relation_path=relation_path, policy_version=abac_decision.version)

5.5.3 Caching, consistency, and failure modes

• RBAC cache. Five-minute TTL; invalidate on role change.
• ReBAC cache. One-minute TTL; invalidate on relationship write.
• ABAC cache. Thirty-second TTL; include policy version in the cache key.
• Consistency. Strong consistency for writes on the same memory; eventual consistency is acceptable for read authorization.
• Failure mode. Fail closed. If the policy engine is unavailable, deny writes; allow only owner-only reads as a degraded mode.
• Stale permission risk. Use short TTLs and publish invalidation events.

5.5.4 Sequence diagram (text)

Client → Gateway: request(memory_id, action)
Gateway → AuthN: validate(token)
AuthN → Gateway: subject, tenant, agent
Gateway → AuthZ: build AuthzContext
AuthZ → RBAC: check(subject, action, resource_type)
RBAC → AuthZ: allow/deny
AuthZ → ReBAC: find_path(subject, relation, scope)
ReBAC → AuthZ: path or empty
AuthZ → ABAC: evaluate(context, path)
ABAC → AuthZ: allow/deny + version
AuthZ → Gateway: final decision
Gateway → MemoryService: execute (if allow)
MemoryService → Audit: log decision
MemoryService → Gateway: result
Gateway → Client: response

5.6 Implementation Considerations

5.6.1 Policy engine vs. custom logic

• RBAC. Custom logic is usually fine. It is simple and stable.
• ReBAC. Use a dedicated relationship store or library. Do not hand-roll recursive graph queries in application code unless the scale is tiny.
• ABAC. Use a policy engine such as Open Policy Agent (OPA) or Cedar. Policies are easier to test, version, and audit.

5.6.2 Relationship store: graph database vs. relational tables

• Relational tables. Good for small to medium scale. Use recursive CTEs for path queries. Simple to operate.
• Graph database or dedicated ReBAC service. Better for large, nested, high-query-volume relationships. Examples include SpiceDB, OpenFGA, and Neo4j.
• Recommendation. Start with relational tables. Migrate to a dedicated ReBAC store when relationship queries become a bottleneck.

5.6.3 Audit logging, testing, and migration

• Audit logging. Log every decision with subject, resource, action, decision, reason, policy version, relation path, and timestamp.
• Testing. Unit tests for each gate. Integration tests for the full pipeline. Negative tests for cross-tenant and cross-scope leakage. Property-based tests for policy invariants.
• Migration. Backfill relationships from existing team memberships, ownership fields, and delegation records. Run in shadow mode: compare new decisions with old logic before enforcing.

5.6.4 Performance and scalability

• Cache aggressively but safely.
• Use batch authorization for list endpoints.
• Precompute common relationship paths.
• Partition by tenant.
• Monitor p95 latency for authorization calls. Target under fifty milliseconds for cached decisions.

5.7 Risks and Trade-offs

5.7.1 Common pitfalls in hybrid authorization

• Inconsistent caching. Different TTLs can cause one layer to allow while another denies.
• Relationship explosion. Too many fine-grained relationships can slow queries.
• Policy conflicts. ABAC rules may contradict RBAC or ReBAC outcomes.
• Over-engineering. Building a full policy engine for a simple personal and team memory system.

5.7.2 Where this design could become over-engineered

• If the platform only has personal and team memory, ABAC may not be needed at all.
• If all teams are flat and non-nested, ReBAC can be replaced with simple team_id checks.
• If there are fewer than ten roles, RBAC can be hardcoded.

5.7.3 What to simplify

• Start with RBAC plus simple ReBAC (team membership, ownership).
• Add ABAC only when dynamic rules such as sensitivity, data residency, or time-based access are required.
• Use a single authorization service with a clear interface, rather than embedding checks everywhere.

5.8 Next Steps

5.8.1 Concrete implementation order

1. Define scopes and actions: personal, agent, team, org; read, write, delete, share, promote.
2. Implement RBAC tables and coarse checks.
3. Implement ReBAC relationship table and basic path queries.
4. Add authorization middleware and enforce in the memory service.
5. Add audit logging.
6. Add ABAC policies for sensitivity and residency.
7. Add caching and invalidation.

5.8.2 Open questions to resolve before coding

• How are agents identified and authenticated?
• Can users delegate memory access to agents? For how long?
• Are teams hierarchical? Can a team contain sub-teams?
• What is the tenant isolation model? Shared database with RLS, or separate databases?
• What retention and deletion rules apply per scope?
• Who can promote personal memory to team or organizational memory?

5.8.3 Suggested milestones or proof-of-concept scope

• Milestone 1. Personal memory only. RBAC plus owner check. Audit logging.
• Milestone 2. Team memory. ReBAC for team membership. Read and write checks.
• Milestone 3. Agent memory. Delegation relationships. Agent-scoped access.
• Milestone 4. Organizational memory. Promotion workflow. ABAC for sensitivity.
• Milestone 5. Full hybrid pipeline with caching, policy engine, and migration.

Part III — Operations and Governance

6. Security, Governance, and Compliance

6.1 Governed Memory Lifecycle

Memory governance ensures that shared memory remains subject to organizational policies throughout its lifecycle. This includes:

• Policy-driven retention. Different memory types have different retention periods, configurable per scope.
• Automated pruning. TTL-based expiration removes stale memories automatically, preventing the "infinite log" problem.
• Supersession tracking. When a memory is updated, the previous version is retained for audit but marked as superseded, enabling temporal queries such as "What did the agent believe on March 15th?"

6.2 Audit and Forensics

For regulated industries, the ability to reconstruct what an agent knew at any point in time is essential. The architecture provides:

• Complete audit trails. Every memory operation (creation, update, deletion, retrieval) is logged with timestamp, actor, and scope.
• Cryptographic attestation. Memory integrity is verifiable through cryptographic hashing, ensuring that audit records have not been tampered with.
• Forensic reconstruction. Security investigators can reconstruct exactly what an agent believed at any point in time, answering questions such as whether a data leak was the user's intent or the agent's mistake.

6.3 Regulatory Compliance

The architecture is designed to address major regulatory frameworks:

• GDPR. Right-to-erasure requests trigger cascading deletion across all scopes and derivations. User access requests can generate comprehensive memory reports.
• EU AI Act. Articles 12–14 establish record-keeping, transparency, and human-oversight requirements for high-risk AI systems. The architecture provides the audit trails and transparency mechanisms required.
• HIPAA. PHI detection and redaction, with configurable retention policies that ensure medical data is not retained beyond regulatory limits.
• SOC 2. Access controls, audit logging, and data isolation mechanisms align with SOC 2 trust service criteria.

6.4 Memory Poisoning Prevention

Memory poisoning attacks represent a distinct threat category (OWASP ASI06). These attacks attempt to inject false or misleading memories that degrade agent performance or cause harmful actions. The architecture defends against this through:

• Input validation. All memory writes are validated against schema and policy rules.
• Confidence scoring. Memories carry confidence scores that increase with reinforcement and decrease with contradiction.
• Quality gates. Every incoming memory is validated, deduplicated, and rated before it earns a row.
• Scope isolation. Poisoned memories in one scope cannot propagate to other scopes without passing promotion criteria.

7. Memory Retrieval and Context Assembly

7.1 Hybrid Retrieval

Effective memory retrieval requires more than simple semantic similarity. The architecture employs multi-channel retrieval, combining:

• Dense semantic search. Vector embeddings for conceptual similarity.
• BM25 lexical search. Keyword matching for precise term recall.
• Temporal retrieval. Time-based filtering and recency boosting.
• Graph traversal. Relationship-based retrieval through entity and concept links.

Candidates from each channel are fused using reciprocal rank fusion, producing a ranked list that balances precision and recall.

7.2 Context Assembly

When an agent needs to generate a response, the system assembles a context package containing:

1. Working memory. The current session's recent turns.
2. Relevant episodic memories. Similar past interactions.
3. Applicable semantic knowledge. Facts and relationships relevant to the query.
4. Procedural guidance. Learned workflows applicable to the task.
5. Personal preferences. User-specific constraints and habits.

The assembly process is token-aware, ensuring the context package fits within the model's context window while maximizing relevance.

Memory enters the system through explicit saves by people or their AI, end-of-session summaries the person confirms, optional client hooks, and connectors that import existing knowledge (for example Jira) to seed project and organizational memory. Nothing from a person's conversations reaches a shared scope without an approval step.

7.3 Role-Aware Routing

In multi-agent systems, different agents may have different access permissions and responsibilities. The retrieval layer implements role-aware routing, ensuring that:

• A client-facing agent retrieves that client's memories plus memories labelled for external use.
• An internal agent retrieves team and organizational memories.
• A personal assistant agent retrieves user-specific memories.

This prevents agents from accessing memories outside their authorized scope, even when operating within the same tenant.

Every memory also carries an audience label: internal, restricted or external_ok. An agent or bot replying to someone outside the organization receives only external_ok memories. Memory derived by promotion or synthesis takes the strictest label of its sources. All models receive the same facts; only the size and format of the response is adapted to each model and application.

8. Technical Implementation Considerations

8.1 Storage Backend

The architecture supports multiple storage backends to accommodate different deployment scenarios:

• SQLite. For single-node, local-first deployments with minimal infrastructure requirements.
• PostgreSQL with pgvector. For production deployments requiring scalability and vector search.
• Specialized vector databases. Qdrant, Weaviate, or Milvus for high-performance similarity search at scale.

The storage layer abstracts these backends behind a unified interface, allowing organizations to start with SQLite and migrate to PostgreSQL as their needs grow.

8.2 Embedding Models

The choice of embedding model significantly impacts retrieval quality. The architecture supports:

• Local models. Ollama-hosted models (for example, nomic-embed-text, bge-m3) for air-gapped or privacy-sensitive deployments.
• Cloud models. OpenAI, Cohere, or Voyage embeddings for organizations with cloud connectivity.
• Custom models. Domain-specific embeddings fine-tuned on organizational data.

Embedding model selection is configurable per tenant, allowing organizations to optimize for their specific vocabulary and use cases.

8.3 Latency Budget

Enterprise deployments demand predictable latency. The architecture targets:

These targets are achievable through in-memory caching, efficient indexing, and parallel retrieval across channels.

8.4 Deployment Topologies

The architecture supports multiple deployment topologies:

• Fully local. All components run on-premises, with no external API calls. Suitable for classified or air-gapped environments.
• Hybrid. Memory storage and retrieval are local, while embedding generation may use cloud APIs. Suitable for organizations with data residency requirements.
• Cloud-native. All components run in the organization's cloud environment, with horizontal scaling for high availability.

8.5 The Memory Worker (Internal LLM)

An internal worker, separate from the models people chat with, turns what people and AIs write into clean shared memory: it extracts short facts, keeps one neutral writing style whichever model sent the input, detects duplicates and contradictions, anonymizes content for promotion, drafts syntheses and flags suspicious text. It runs in the background and is never in the request path, so the system still works in a reduced form without it. It uses one model-agnostic interface: a small local model to start, with a cloud model or GPU as later options.

9. Organizational Learning and Knowledge Compounding

9.1 The Learning Flywheel

The ultimate value of a shared memory layer is the compounding of organizational knowledge. When agents and users contribute memories, and those memories are promoted and refined, the entire organization becomes smarter over time. This creates a positive feedback loop:

1. Individual agents discover patterns through task execution.
2. Patterns are validated through repetition and reinforced with confidence scores.
3. Validated patterns are promoted to team scope, benefiting all team members.
4. Team patterns that prove broadly applicable are promoted to organizational scope.
5. New team members and new agents bootstrap from accumulated organizational knowledge.

9.2 The Memory Operating System Metaphor

This architecture can be understood as a memory operating system for AI agents—a unified context layer that replaces the fragile patchwork of vector databases, session stores, and custom glue code. Like an operating system manages hardware resources, this layer manages memory resources:

• Allocation. Determining where memories are stored and how they are scoped.
• Protection. Enforcing access controls and preventing cross-scope leakage.
• Persistence. Managing durable storage and retrieval.
• Garbage collection. Pruning stale or superseded memories.
• Scheduling. Prioritizing retrieval and context assembly.

9.3 From Tool to Teammate

The fundamental shift enabled by shared memory is the transformation of AI from tool to teammate. Tools are stateless—they perform a function and return a result. Teammates learn, adapt, and build shared understanding over time. This transformation has profound implications for how organizations deploy and manage AI:

• Onboarding. New agents inherit organizational knowledge from day one, rather than starting cold.
• Continuity. Work can span sessions, days, and team members without loss of context.
• Accountability. Every memory is auditable, enabling organizations to understand and govern AI behavior.
• Compound value. Each interaction makes the system more valuable for future interactions.

10. Conclusion

The enterprise AI landscape is at an inflection point. Organizations have deployed AI agents across business functions, but the majority of these deployments are not delivering expected ROI—not because the models are inadequate, but because the infrastructure lacks persistent, shared memory.

This paper has presented a comprehensive architecture for a shared cognitive memory layer that addresses this gap. The architecture provides:

• Multi-scope memory across personal, team, agent, and organizational levels.
• Strict tenant isolation enforced at the database layer.
• Enterprise-grade governance with audit trails, policy enforcement, and regulatory compliance.
• A hybrid authorization model combining RBAC, ReBAC, and ABAC to cover coarse governance, fine-grained relationships, and dynamic context.
• Hybrid retrieval that balances semantic, lexical, temporal, and graph-based search.
• A promotion pipeline that compounds individual learning into organizational knowledge.

The transition from stateless tools to stateful teammates is not merely a technical upgrade—it is an architectural shift that redefines how organizations deploy, manage, and derive value from AI. The organizations that build this shared memory layer today will be the ones that unlock the full potential of their AI investments tomorrow.

Appendix A: Memory Object Schema

MemoryObject {
  id: UUID
  tenant_id: UUID (RLS-enforced)
  scope: ENUM(personal, user, agent, team, project, client, org, account)
  scope_id: UUID (user_id, agent_id, team_id, etc.)
  memory_type: ENUM(episodic, semantic, procedural, working)

  content: TEXT (encrypted at rest)
  embedding: VECTOR(1536)

  confidence: FLOAT [0.0, 1.0]
  importance: FLOAT [0.0, 1.0]
  occurrence_count: INTEGER

  source_lineage: JSONB (provenance chain)
  policy_composition: JSONB

  sensitivity_label: TEXT
  policy_tags: JSONB

  created_at: TIMESTAMP
  updated_at: TIMESTAMP
  expires_at: TIMESTAMP (TTL)
  superseded_by: UUID (nullable)

  is_current: BOOLEAN
  version: INTEGER
}

Appendix B: Example Relationship Tuples

Appendix C: Glossary

Appendix D: Reference implementation (cMCP)

cMCP is the reference implementation of this architecture. Phase 1 (stages 1a to 1f: core memory, projects and sync, grants and bots, account and client levels with promotion, web UI and admin console, integration hub; then, in stages 1g to 1t, automatic capture from AI apps, a space registry, collective and organizational memory, space knowledge, device keys, a bot library, digital workers and guarded risk switches) is built and tested on a pilot server, with relaxed security, and moves to IT-Labs hardware next. Phase 2 (security hardening, compliance, multi-tenant product) is planned and is described in this paper as future development.

Planned for Phase 2 (not built): ABAC context rules with a policy engine such as Cedar or OPA, a dedicated relationship store such as SpiceDB or OpenFGA if relationship queries become a bottleneck, hash-chained audit, PII detection (Presidio), per-tenant encryption keys, SCIM, a cloud model or GPU for extraction, multi-tenant hosting, Helm and an air-gapped bundle, and the compliance and penetration-test work.