CoreMemory
Your context. Under your control.
A shared memory layer for AI tools, with people deciding what is saved, accessed, and shared.
- Platform
- Web App
- Scope
- Full-stack
- Team
- Solo
- Status
- Active
- Started
- Apr 1, 2026
Project context
As AI becomes more integrated into everyday workflows, users increasingly rely on multiple models and tools to accomplish different tasks.
Over time, context becomes fragmented across systems, forcing users to repeatedly synchronize information, explain project state, and trust individual platforms to manage increasingly personal data.
The challenge
- Context fragmented across AI tools
- Repeated setup and overly broad sharing
The approach
- Users review proposed memories
- Tools retrieve only permitted context
From intent to interaction
Connect a tool
Give an approved AI client a scoped path to your context.
Review its suggestions
Accept, edit, or reject proposed memories before they are saved.
Share with intent
Return relevant, approved context only when the requesting tool has access.
What it makes possible
Review before saving
Review and approve context proposed by connected AI tools.
Control access
Limit tool access and revoke permissions when needed.
Keep context portable
Share one curated context layer across approved AI tools.
How the pieces fit
Curation dashboard
Review proposals and organize shared context.
Next.jsProtected MCP service
Apply access rules across supported transports.
Shared policy runtimeGoverned storage
Store durable context within user boundaries.
PostgreSQLProposals before writes
Tools suggest memories. Users decide what becomes part of the record.
Policy before retrieval
Check scope and sensitivity before returning relevant context.
Engineering notebook
Explore the design, data flow, and implementation in more detail.
Curation dashboard
Review proposals and organize shared context.
Next.jsProtected MCP service
Apply access rules across supported transports.
Shared policy runtimeGoverned storage
Store durable context within user boundaries.
PostgreSQLCoreMemory explores a different approach to AI context management. Instead of allowing each model to maintain its own isolated understanding of a user, CoreMemory provides a centralized context authority owned and governed by the individual.
Users decide what information should be retained, who can access it, and when that information becomes relevant across the tools they use.
Implementation
CoreMemory implements a user-as-control-plane architecture where AI systems can request or propose context, but cannot directly own or mutate the user's source of truth.
The system separates model execution from context ownership. Connected tools interact with a centralized memory authority through scoped access paths, while retrieval, mutation, and visibility rules remain governed by user-controlled policy.
Connect a tool
Connect an approved tool with scoped memory access.
Review its suggestions
Review proposed context before it becomes memory.
Share with intent
Return only relevant context the tool may access.
Users begin by connecting an AI tool to CoreMemory. Rather than granting unrestricted access, connected systems can propose new context for review, allowing users to approve, reject, modify, or organize information before it becomes part of their shared context layer.
Over time, users build a curated source of truth that follows them across tools, reducing repetitive onboarding while maintaining control over what information is shared and with whom.
Implementation
A connected AI tool submits proposed memory updates into a review workflow instead of writing directly to storage. The user can approve, reject, edit, categorize, or restrict each proposal before it becomes part of the governed context layer.
When a tool later requests context, CoreMemory evaluates the requesting surface, credential scope, sensitivity rules, and semantic relevance before returning approved information. If the tool is not allowed to access a given category of context, the system returns nothing rather than exposing data by default.
One shared policy runtime
Share policy checks across web and MCP access.
Scope each credential
Limit and revoke credentials for connected tools.
Protect records at storage
Reinforce ownership with database access policies.
CoreMemory is built around four principles: ownership, governance, transparency, and portability.
Context belongs to the individual who creates it, not the systems that consume it. Access should be reviewable, revocable, and intentional. Information should remain visible to the user, while remaining portable across tools and platforms.
Together, these principles create a foundation for managing AI context as capable systems become increasingly autonomous.
Implementation
CoreMemory is structured as a pnpm monorepo with a Next.js curation dashboard, a protected MCP service, and PostgreSQL-backed storage. The dashboard gives users visibility into proposed and stored context, while the MCP layer gives approved AI tools a controlled path for retrieval and proposal submission.
A shared runtime layer handles policy enforcement across access paths. Whether a request enters through the web dashboard, protected HTTP, or stdio MCP transport, the same authorization, retrieval, and mutation rules are applied before any context is surfaced or changed.
Model Context Protocol access
Expose approved context through MCP without transferring ownership of the memory store.
Proposal-based writes
Queue model suggestions for review before accepted updates become durable memories.
Delegated credentialing
Give each connected tool scoped credentials that can be limited or revoked.
Policy-gated retrieval
Check relevance, scope, and sensitivity before returning any stored context.
RLS-backed storage boundaries
Use PostgreSQL row-level security to reinforce the ownership of stored records.
Connect AI tools
Allow approved AI systems to access shared context through a governed interface rather than maintaining isolated memory stores.
Review proposed updates
Maintain control over what information becomes part of your long-term context by reviewing model-generated suggestions before they are accepted.
Manage access and permissions
Control which tools can access specific categories of information, helping ensure context is shared only when necessary.
Build a shared source of truth
Reduce repetitive onboarding and context synchronization by maintaining one curated context layer across multiple AI systems.
Inspect and organize context
Review, categorize, and refine stored information so context remains accurate, relevant, and useful over time.
Implementation
Model Context Protocol access
CoreMemory exposes controlled memory access through MCP-compatible transports, allowing AI clients to retrieve approved context without owning the underlying memory store.
Proposal-based writes
Models submit structured memory suggestions into a review queue. The system records the proposal, waits for user action, and only promotes accepted updates into durable memory.
Delegated credentialing
Connected tools use scoped credentials tied to a specific surface, model, or access profile. Credentials can be limited, revoked, or adjusted without exposing the full memory layer.
Policy-gated retrieval
Retrieval combines relevance matching with permission checks. Context is only returned when the requesting tool is authorized to access that category, sensitivity level, or user-approved scope.
RLS-backed storage boundaries
PostgreSQL Row-Level Security reinforces user boundaries at the data layer, reducing reliance on application logic alone for enforcing ownership and access constraints.
Have a related challenge?
Let’s talk about it.
Bring an idea, a workflow to improve, or a technical question. We can work through what comes next.