Key takeaways
- Start with recall needs: Start with the information an agent needs to retain and the questions it must answer after a restart or client change.
- Separate responsibilities: Separate storage, retrieval and communication. MCP provides an interface; persistence and memory behavior depend on the server and application.
- Test portability: Evaluate portability through an actual export and client-switch test. A surviving database does not by itself establish compatible or useful recall.
- Check control and ownership: Treat version history, access control and operational ownership as separate requirements.
- Review licensing: Check the license and commercial terms of the exact implementation and release before choosing a deployment.
An agent's active context, durable knowledge, and workflow execution state serve distinct roles:
- Active context: Transient interaction window for the current prompt or session.
- Durable knowledge: Persistent facts, documents, and preferences stored across sessions and clients.
- Workflow execution state: Task execution history, pending actions, and side-effect checkpoints.
The session boundary problem
Start with a specific failure the team wants to prevent. A coding assistant may need to recover the reason behind an architectural decision. A support agent may need the current procedure rather than a superseded version. A custom workflow may need to resume a task after its process restarts. These requirements imply different records and acceptance tests.
Built-in client features may persist data beyond a single session, but their scope remains product-specific. Recovering a decision record after a restart does not restore task execution state, pending actions, or side-effect history. Identify the data that should survive, where it is stored, and who owns its update and deletion.
Compare architectural responsibilities
Several approaches are worth evaluating. The categories below describe ways to divide responsibilities; they are not verified feature rankings of every product in a category.
Data table · Scroll horizontally to see all columns. Arrow keys work when focused.
| Approach | Main evaluation question | What to inspect |
|---|---|---|
| Built-in client or provider features | Does this feature retain the right information for the intended workflow? | Persistence scope, update controls, export options and behavior when changing clients |
| Dedicated memory service or runtime | Does its memory workflow fit the surrounding application? | Integration requirements, stored records, retrieval behavior and operational ownership |
| Application-owned database or file store | Can the team implement and maintain the required memory behavior? | Data model, retrieval logic, permissions, backups and migration procedures |
| MCP-accessible knowledge store | Can the intended clients use shared knowledge through the exposed tools? | Client compatibility, authentication, server persistence and evidence returned with answers |
An MCP server can sit in front of a database, files or another service. A dedicated memory service may also expose standard interfaces. These categories can overlap, so compare a concrete implementation and configuration rather than selecting from labels alone.
The MCP architecture documentation describes the protocol's role in exchanging context and exposing capabilities. It does not prescribe how an application uses its model or manages that context. The application and server must still provide the behavior the team needs.
An agent-oriented knowledge store: AKB
Dnotitia's AKB provides organizational knowledge and memory to agents through MCP. Its public documentation describes Git-backed versioned knowledge, documents, tables and files, hybrid semantic and keyword retrieval, and explicit relationships. Claude Code, Cursor and custom agents are among the documented clients. Self-hosting is documented. AKB repository
These capabilities make AKB a candidate for a shared project-knowledge pilot. For example, a team could evaluate whether two coding clients can recover the same decision record and recognize when it has been superseded.
The distinction between the core knowledge store and surrounding client tools or optional plugins matters. The documented core is a read/write store. While optional plugins such as akb-claude-code provide client lifecycle integration, do not infer automatic capture or consolidation guarantees from standard MCP tools. Verify the availability, configuration and operating rules of any optional collection or curation service separately from AKB Core. AKB plugins
Test cross-client recall
If a team uses more than one agent client, run a controlled interoperability test:
- Connect the intended clients to the knowledge service using supported configurations, logging client, server, and plugin versions along with identity context. Use harmless test data.
- Add a harmless test record through an authorized workflow, recording the record ID and source revision. Separate acknowledged writes from measured retrieval visibility to account for indexing latency.
- Retrieve the record from a secondary client to evaluate returned evidence, snippets, and answer grounding.
- Update the record, then repeat the query across existing client connections and after explicit client/service restarts.
- Test access revocation using a separate retained fixture (not a deleted record): confirm initial permitted read for a test identity, revoke access via an authorized admin, then test retrieval in existing connections and fresh sessions. Verify future read/snippet denial for that identity while a control identity retains access. Revocation stops future authorized retrieval but cannot retract context already disclosed in prior responses.
- Test deletion on a different test record: confirm deletion across clients, inspect for stale search results or cached snippets, and record indexing retrieval lag and expected archival/retention policies.
This tests more than whether a connection succeeds. It exposes differences in tool use, retrieval latency, permissions, and source updates that a protocol compatibility label cannot resolve.
For a model migration, test the same questions with the replacement model and client configuration. Existing records may remain available while their use changes. Assess answer grounding and missing qualifications separately from whether the data survived.
Compare storage, history and control
Storage choices affect operations, but no substrate by itself establishes a complete security or compliance outcome.
Data table · Scroll horizontally to see all columns. Arrow keys work when focused.
| Requirement | Evidence to request |
|---|---|
| Restart survival | A record retrieved after the relevant service or client restarts |
| Version history | An inspectable change history and a demonstrated restore procedure |
| Access boundaries | Tests showing which identities can read, write and administer records |
| Backup and recovery | A restoration test with the required data and configuration |
| Portability | A usable export and migration test covering content, metadata, relationships, and re-import behavior |
| Operational ownership | Named responsibilities for updates, failures and recovery |
Git history can make changes reviewable. It should not be described as an immutable audit log without separately verified controls. Likewise, self-hosting gives a team deployment responsibilities; it does not automatically establish residency, isolation or regulatory compliance for the complete workflow.
Check where inference, embedding and other connected services run as part of the same review.
Evaluate retrieval with questions the team can judge
A feature list may mention semantic search, keyword retrieval or relationships. The useful question is whether the implementation finds the evidence needed for the team's actual task.
Use several kinds of question: an exact identifier, a paraphrased concept, a decision linked to another record, and an issue the collection cannot answer. Include an obsolete record beside its replacement.
For AKB, hybrid semantic and keyword retrieval and explicit relationships are documented capabilities. Their usefulness still needs evaluation against the team's material. Save the retrieved evidence and the final answer so reviewers can distinguish a retrieval miss from an unsupported interpretation. AKB repository
Do not transfer features between similarly named reference servers or community implementations. Record the exact package, release and configuration being tested.
Choose an operating model the team can sustain
Before expanding a pilot, establish who can add knowledge, who corrects obsolete sources, and how a failed update is detected. Decide which changes require review and how an agent should respond when the available evidence is insufficient.
Then test a change. Replace a procedure or revise an architectural decision and observe what needs updating. The effort required to keep answers current belongs in the evaluation alongside initial setup and retrieval results.
Check licensing separately against the exact release. AKB's core uses Business Source License 1.1 (BSL 1.1). Its conditional production-use grant applies below 100 Named Seats, counted in aggregate 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 release being deployed for the exact definitions and conditions. The sources were checked on 22 September 2026. AKB LICENSE
Match architecture to workload needs
Select an approach based on specific workload requirements rather than universal product rankings:
- Single-session interactions: Active model context may be sufficient when information does not need to persist beyond the current conversation.
- Single-client preferences: Consider documented built-in features if supported and validated for persistent user or client preferences.
- Cross-client shared knowledge: Test an external shared store (such as an MCP-accessible knowledge base) when multiple clients or agents must access common decision records and documents.
- Task resumption across restarts: Verify execution/checkpoint and side-effect handling. Recovering decision records or persistent state alone does not guarantee exact workflow resumption.
FAQ
Does using MCP make memory portable?
MCP supplies a communication interface. Portability also depends on the stored representation, available export, permissions and the replacement client's behavior. Do not assume an export preserves every attribute. Verify the destination's permission mappings and credentials, and determine whether search indexes must be rebuilt.
Can two coding assistants share project knowledge?
They can be evaluated against a shared service when both clients support its interface and configuration. Check that they retrieve the expected records, observe updates and respect the intended access boundaries. AKB documents Claude Code and Cursor among its clients. AKB documentation
Is a database enough to provide agent memory?
A database provides storage capabilities. The complete application still needs decisions about what to retain, how to retrieve it, how to update it and how to use it in an answer.
What should justify a wider rollout?
Use an evaluation record containing representative questions, supporting sources, observed failures, recovery results and maintenance ownership. A narrow pilot that produces traceable answers is a stronger basis for expansion than an architectural label alone.
This comparison provides an evaluation framework with an attributed AKB example. The sources were checked on 22 September 2026. It does not report an independent product test or measured advantage.