Where policy permits, client built-in features are a reasonable initial option for one developer’s conventions and recurring context, though they are not a universal recommendation for confidential team data. Consider a shared local service when several tools on one machine need the same records, and a governed shared service when multiple people need organizational knowledge. The right location depends on who must retrieve, update, and recover those records.
Key takeaways
- Separate client instructions from client memory: Static project rules, saved conversation history and automatically maintained memory have different update and retention behavior. Inspect the selected client's configuration before deciding that it needs an external store.
- MCP supplies an interface to a store: A shared Model Context Protocol service can let compatible clients reach the same records, but persistence, authorization and recall depend on the implementation.
- Storage survival is a deployment property: Check mounted volumes, backup coverage, startup configuration and the identity used to address records. A process restart and a move to another device are different tests.
- Team sharing needs enforced permissions: A record's
user_id, project tag or bank identifier does not by itself establish that an unauthorized caller cannot access it. - Location changes the work required: Client-local files, a local server and a shared hosted service have different update, recovery and network dependencies. Choose from observed workflow requirements rather than a promise of universal portability.
The memory lifespan problem in AI coding workflows
A coding workflow can hold information in several places at once: active context, a saved conversation, project instruction files, client-maintained memory and an external knowledge service. A context reset may discard some working information while leaving saved records or a summary available. Do not treat every reset as the loss of all memory.
Identify which boundary matters for the intended workflow:
- A new conversation: Does the client load the relevant instruction or saved memory, and can it distinguish an obsolete record from its replacement?
- A process or host restart: Does the backing store survive, and does the service restart with the same configuration?
- A different client or device: Can the new client reach the same records with appropriate credentials, and does it use them correctly?
For example, a developer may want a resolved build failure to remain available on their laptop, while an engineering team needs an approved deployment procedure shared across multiple tools. The first need may fit a client feature; the second introduces shared ownership, updates and access controls. Test those needs separately.
Client-bound memory: instructions, saved history and automatic memory
Project files such as CLAUDE.md supply durable guidance when the client loads them. A file does not update itself, but a client can support workflows that write learned information to files. Claude Code documents both instructions and automatic memory; their behavior should not be collapsed into a single static-file category. Claude Code memory documentation
Operational characteristics
- Instructions: Useful for reviewed conventions, architectural constraints and project setup. Confirm which paths and precedence rules the client uses.
- Saved conversation history: May preserve a past interaction without making every fact automatically available to the next one. Test how the client retrieves or resumes it.
- Automatic memory: Can retain selected information across sessions according to the client's implementation and settings. Inspect what is written, how it can be corrected and whether it is appropriate to share.
- Cross-client use: Another tool may read the same files, but that does not establish matching update rules, retrieval behavior or access controls.
Before adding infrastructure, run the actual client through a restart and an outdated-memory correction. An external store becomes useful when the required sharing, retrieval or governance behavior exceeds what that configuration provides.
Decoupling memory via the Model Context Protocol
When client features do not meet the sharing requirement, an MCP-accessible service can expose a common set of memory operations to compatible tools. The Model Context Protocol (MCP) provides a common way for compatible clients to discover and invoke tools. The server defines the available memory operations; the protocol does not itself prescribe retention, retrieval or update behavior.
Under this architecture, multiple client environments—such as Claude Code, Cursor, and custom agent runtimes—communicate over stdio or HTTP using the standard Model Context Protocol to query and update an MCP-accessible store. Verify that the chosen transport and server configuration actually share the same persistent backend; separate local processes may otherwise use separate files.
Local MCP servers and memory banks
Standalone memory services can expose operations that fit a developer workflow:
- Hindsight: Documents memory-bank operations such as retain, recall and reflect. Its installation documentation provides the starting point for choosing the database and deployment configuration. Test that a restart uses the same persistent storage and bank. Its cross-tool guide describes connecting tools to a shared service; confirm the authorization boundary separately.
- Embedded stores: A SQLite-backed MCP implementation can keep records in a local file. Inspect the exact package and version for its schema, model dependencies and startup behavior. A persistent file does not automatically configure the service to resume after a host reboot.
For either option, document the storage path, backup method and service owner. Test an update through one client and retrieve it through another before treating the setup as shared memory.
Compare the four storage options
The deployment models listed below are illustrative, overlapping deployment choices rather than mutually exclusive categories or an exhaustive market taxonomy. When agent memory outgrows basic local files, teams evaluate combinations of local client features, embedded stores, shared memory services, and structured knowledge stores depending on their access and governance requirements.
TABLE / Scroll horizontally for all columns →
| Architectural dimension | Client-local features | Embedded store | Shared memory service | AKB knowledge store |
|---|---|---|---|---|
| Records to inspect | Instructions, history and automatic memory supported by the client | The selected implementation's database records | Memory records, identifiers and update operations | Documents, tables, files and explicit relations |
| Restart test | Open a new session after restarting the client | Reopen the same persistent file | Reconnect to the intended service and record scope | Restart the selected deployment and retrieve a known record |
| Cross-client test | Confirm what another client can read and update | Confirm clients use the same store | Configure both clients against the same endpoint and scope | Test supported MCP clients against the same authorized vault |
| Access test | Check file and client access | Check local access plus service authorization | Verify caller permissions, not just a user or bank identifier | Test permitted and denied vault operations |
| Recovery test | Restore required files and configuration | Restore database and schema together | Exercise the offering's export or backup procedure | Restore canonical data and history, then rebuild derived indexes if needed |
| Operational owner | Developer or managed-client administrator | Local service owner | Vendor and customer responsibilities for the selected deployment | Customer hosting and integration owners for a self-hosted setup |
The table is a test plan, not a ranking of guaranteed vendor capabilities. A cloud edition and a self-hosted edition of the same product can divide responsibilities differently.
Dedicated vector and graph memory: Mem0
Mem0 provides memory infrastructure for applications. Its user-memory guide describes organizing records around user and application context, with operations to update and delete stored information.
A stable identifier can help an application address the same records from different devices. It is not an authorization mechanism on its own: establish who supplies the identifier and where the application verifies that the caller may access it. Compare the hosted and self-hosted configurations separately for authentication, persistence, export and operational ownership.
For a migration test, save known records, replace the intended client or model, and inspect both retrieval and the generated answer. Record survival is only one part of useful continuity.
Versioned organizational knowledge: Dnotitia AKB
Dnotitia approaches agent memory through AKB (Agent Knowledge Base), a knowledge store designed for versioned organizational knowledge, documents, tables, files, explicit relations, and granular permissions for shared human and agent use.
AKB stores canonical text and metadata in PostgreSQL alongside a derived, configurable vector index. The default pgvector configuration is one part of the deployment; it should not be mistaken for the entire storage stack. Git integration is a documented implementation detail for tracking file-level history and changes, rather than the core product identity or an immutable-audit guarantee. AKB repository
Use the documented akb-mcp proxy or supported service connection for the intended client. The core is a read/write knowledge store. Repository-shipped plugins and separately configured automation must be distinguished from the core; do not assume that installing a storage service automatically collects sessions or maintains knowledge. Validate each chosen integration's trigger, records and failure handling.
Versioned changes can be inspected through history and diffs. The optional MCP audit facility needs explicit configuration and a retention plan; hash chaining alone does not make an audit record immutable. Test authorization for permitted and denied vault operations rather than inferring complete isolation from a storage layout.
AKB's core uses Business Source License 1.1. Its conditional production-use grant applies below 100 Named Seats, aggregated across the related entities and deployments defined in the license. Production use at 100 or more aggregated Named Seats, or offering AKB to third parties as a hosted, embedded or rebranded service at any seat count, requires a separate commercial license. The client proxy has separate MIT licensing. Review the LICENSE shipped with the chosen release for exact definitions and conditions. AKB LICENSE
Data sovereignty, privacy, and migration safety
Where memory is hosted directly affects operational overhead, network security boundaries, and data governance.
TABLE / Scroll horizontally for all columns →
| Storage location | What the location establishes | What still needs checking |
|---|---|---|
| Client-local files or database | The records reside on a local device | Whether the client sends their contents to remote models, tools or telemetry services |
| Self-hosted service | The team chooses where the service and its storage run | Parsing, embedding, inference, authentication, update and backup dependencies |
| Managed service | A vendor operates the contracted service components | Data flows, regional scope, retention, export and the customer's remaining responsibilities |
Self-hosting versus cloud-managed endpoints
- Offline execution: Trace every component, including the consuming agent. Keeping a database local does not make remote inference local. Configure and test the complete workflow with the required network restrictions before describing it as offline.
- Configuration dependencies: Installation options can use different database and embedding services. Follow the selected release's instructions and inventory credentials, endpoints and model artifacts rather than treating a product name as a deployment boundary.
- Local file security: Define who can access records, logs and backups through operating-system permissions and service credentials. Verify these on the actual host platform.
- Migration portability: An export may preserve text while omitting permissions, relationships or application-specific state. Test the destination's ability to use the exported records, and budget for rebuilding embeddings or translating metadata when required.
Technical decision framework: choosing your memory location
Choose a location from the workflow that must survive a change:
- One developer's conventions and recurring context: Where policy permits, evaluate the client's instruction and memory features first. Check the chosen configuration's data flows, sharing and retention controls against the sensitivity of the records, and test correction and restart behavior before adding another service.
- Several clients on one machine: Test a shared local service if client-local features do not provide the required common record. Establish one storage location and clear startup ownership.
- Shared organizational knowledge: Evaluate a service with explicit access control, ownership and source-update processes. AKB is one candidate when versioned organizational knowledge and MCP access fit the workflow; a memory API may fit a different record model.
Step 1: Assess the type of knowledge
Distinguish reviewed project rules, personal preferences, task state and authoritative company procedures. They can have different owners and retention rules. Do not automatically share a developer's private session memory with the whole organization.
Step 2: Determine operational boundaries
Identify the clients, users and environments that must retrieve each record. Test a new conversation, a service restart and a second client separately. Include an unauthorized caller and an update to a superseded procedure. A team service should enforce permissions even when a caller changes a record identifier or namespace parameter.
Illustrative acceptance test example
To validate recall across operational changes, teams can run a compact baseline matrix. This example is explicitly hypothetical and illustrative, not a minimum sample size or product benchmark:
- Baseline suite: 3 scenarios (new session, service restart, second client) across 4 representative records yield 12 baseline checks.
- Boundary tests: Run separate tests for denied-user access and retrieval of updated or superseded records.
- Metrics to track: Track correct authorized retrieval counts and latency for each scenario, not only record survival.
Step 3: Establish audit and rollback policies
Decide which changes need human-reviewable diffs, which operations need audit records, and how long each must be retained. Restore a representative record and confirm which source version the agent receives. Version history, operation logging and recovery each require their own test; none substitutes for the others.
Frequently asked questions
How can I share memory between Claude Code and Cursor?
Connecting tools to a common MCP endpoint is one deployment option, but direct APIs or SDKs can also serve a shared backend. Simply connecting a client to an endpoint does not automatically synchronize internal conversation history or retain every session. For tools to share memory, compatible clients must explicitly invoke supported read and write operations against the same authorized store and scope. Where supported by the client and transport configuration, endpoints such as Hindsight, Mem0's MCP server, or the Dnotitia AKB MCP proxy can expose those shared operations.
Will my agent's stored memory survive switching model providers?
Changing the model need not delete an external store, but useful recall is a separate question. Test access to the same records, the replacement model's tool use and the qualifications retained in its answers. If the embedding model changes, the retrieval pipeline may require re-embedding and re-indexing. Do not treat a standard protocol or export format as a universal migration guarantee.
Can I run persistent agent memory entirely on my own machine?
You can choose local storage or a self-hosted service, but complete local execution also depends on inference, embeddings, tools and other connected services. Configure and test all of them before making an offline claim. For AKB, evaluate the documented self-hosted deployment together with the consuming agent and the applicable license conditions described above. AKB repository
How do I scale agent memory when moving from solo development to a team?
Start by separating personal records from shared organizational knowledge. Choose a service whose authentication and authorization can enforce the intended readers and writers, then test denied cross-user requests as well as successful sharing. A user_id, project tag or bank name organizes records; it does not alone prove caller isolation. Assign someone to maintain sources, revoke access and test backups.