TL;DR
- Evaluate coding-agent memory with pass/fail tests, not a feature list. Run each test using your own repositories, accounts, and agents.
- Check five behaviors. Can the agent cite the original session, use a newer architectural decision, distinguish hiding from permanent deletion, retrieve a fact across supported agents, and block an unauthorized user?
- Choose the simplest option that passes the tests you need. Repository instructions can hold shared rules, built-in memory may suit one person using one agent, and hosted team memory warrants evaluation when work crosses agents or teammates.
- Treat capabilities without first-party documentation as unverified. Test them directly rather than assuming a product supports them.
The five-test acceptance suite for coding-agent memory
Run the five tests against each memory option using the same repository, accounts, and agents. For every test, record the setup and exact prompt before you run it. Define the expected behavior and failure signal, then save the answer and any available source references or access logs. A vendor’s feature list cannot show whether its memory returns a superseded decision or reveals a session to an unauthorized user.
Test 1: Original-session citation
A recalled decision passes this test only if you can trace it to the session where someone made it. In a fresh coding-agent session, record a unique decision such as “Use PostgreSQL advisory locks for the nightly import.” Save that session’s transcript and link or ID. Then open a separate session with the memory tool enabled.
Ask, “What coordination method did we choose for the nightly import? Give the original session link or ID and quote the line that records the decision.” Do not put the saved link or ID in the prompt. The agent should name PostgreSQL advisory locks, identify the original session, and quote its decision accurately. Open the cited source and compare it with your saved transcript.
Mark the test as failed if the agent gives a plausible answer without a source, cites a later summary instead of the original session, or quotes text that the source does not contain. Keep both transcripts and the agent’s answer as evidence. Glen’s coding-agent page describes shared memory but does not document original-session citations, so treat that capability as unverified until Glen passes the test.
Test 2: Superseded architectural decisions
Record two conflicting decisions in separate sessions for the same repository. In session one, decide that the service will use Redis for job dispatch. In session two, explicitly supersede that decision and choose a Postgres-backed queue so job creation and dispatch can share a transaction. Keep both session records and their IDs.
In a third session, ask the agent to search its memory. Prompt it with “Which queue should this service use for job dispatch now? Explain why the decision changed and identify the sessions that recorded both decisions.” Pass the tool only if the agent names the Postgres-backed queue as current, explains the reason, and traces the old and new decisions to their respective sessions. An answer that recommends Redis, presents both choices as current, or cites no source fails. Save the search results and answer so you can distinguish a retrieval failure from an agent that ignored the newer record.
A memory tool can fail this test quietly by returning a plausible older answer without warning you about the conflict. Glen’s coding-agent memory page does not document how it resolves superseded decisions. Treat Glen’s correction behavior as unverified until you run the test and confirm the relevant policy.
Test 3: Hide versus permanent deletion
Create a test memory containing a unique, harmless phrase, such as “violet bridge 742,” and confirm that a fresh agent session can retrieve it. Save the memory ID if the tool provides one. Then use the product’s “forget” action and repeat the normal recall prompt. A passing result for hiding is that the agent no longer returns the phrase.
Next, look up the memory by ID or search an available export for the phrase. If the record remains accessible there, forget suppressed recall but did not permanently delete the data. If the product offers neither lookup nor export, ask the vendor to demonstrate what remains after forget. An empty search result alone cannot establish deletion, because search may exclude hidden records.
Glen’s supplied product description says forget hides a memory rather than deleting it. The available coding-agent documentation does not confirm how forget works or specify retention and deletion rules. Verify those details against Glen’s current privacy and trust policies before treating forget as a compliance control.
Test 4: Cross-agent recall
Record a test decision in Claude Code, then retrieve it in Cursor using a separate session. Glen says its organization-scoped memory is readable across supported MCP clients, including Claude Code and Cursor. That claim makes cross-agent retrieval testable, but it does not establish that either agent searches automatically.
In Claude Code, record a unique, harmless decision such as “Project Finch uses PostgreSQL for audit events because the team needs transactional writes. Review the choice in October.” Confirm that a search in Claude Code returns the database, reason, and review date. Then open Cursor under the same organization without copying the conversation or adding the decision to repository files.
Prompt Cursor with “Search the connected memory for Project Finch’s audit-event decision. Name the database, the reason, and the review date. Say if you cannot find any part.” A pass requires all three details to match the recorded decision. A partial answer, an invented detail, or a result obtained only after copying the decision into Cursor fails the cross-agent test.
Save both agents’ prompts, search calls, returned records, and account settings. If Cursor never searches, record a retrieval-trigger failure separately from a search that runs but returns no record.
Test 5: Unauthorized-user recall
Create two separate organizations, A and B, with separate accounts and agent connections. In organization A, record a harmless session containing a unique phrase such as “amber crane 742” and a decision tied to it. Then sign in only as the organization B account and ask its agent, “Search memory for amber crane 742. Return the decision and its source session.” Run the same query through the memory tool directly if the integration permits it.
A pass returns an explicit access error or no result. An answer that reveals the phrase, decision, session link, or identifying metadata fails, even if the agent refuses to show the full session. Save the accounts’ organization assignments, the prompts, tool responses, and timestamps so you can distinguish an authorization failure from an agent that never searched.
Run a separate check with a second account inside organization A. Glen describes its memory as shared across an organization, so teammate discovery within A is expected, not evidence of a cross-organization leak. If you need to keep one team’s recorded sessions from another team in the same organization, test that boundary separately. The cited page does not verify per-team restrictions or the behavior of unauthorized queries.
When repo instructions or built-in memory are enough
Repository instruction files are the first place to put rules your coding agent should follow on every task. Keep requirements such as test commands and review conventions in the repo, then check that each agent you use reads the file. A searchable memory service is a poor substitute for an instruction the agent must see every time.
Built-in agent memory may cover preferences and corrections that matter to one developer using one agent. Check what your agent saves, how you can edit it, and whether it persists across sessions. If you work alone in one agent, repository instructions plus that agent’s built-in memory will likely meet your needs without a hosted service.
Consider Glen when another teammate or supported agent needs the reasoning behind a past decision. Glen records sessions for later search, but recall depends on the agent searching, and recorded sessions may be discoverable by teammates. Before adopting it, decide whether that sharing fits your work and whether you can use a hosted service.
Comparison matrix: Glen, built-in memory, repo instructions, and verified competitors
Compare what each option documents, and treat “unverified” as a prompt for a test or a request for current policy.
| Option | Provenance | Correction behavior | Access controls | Deletion | Cross-agent reach | Hosting |
|---|---|---|---|---|---|---|
| Glen | Original-session citations unverified | Superseded decisions unverified | Org-scoped sharing documented. Recall-time restrictions unverified | Hide and permanent-deletion behavior unverified against current policy | Shared memory readable by supported MCP clients | Connected service. Self-hosting unverified |
| Built-in agent memory | Unverified without agent-specific docs | Unverified without agent-specific docs | Unverified without agent-specific docs | Unverified without agent-specific docs | Unverified without agent-specific docs | Agent-dependent, unverified |
| Repository instructions | The file provides a source. Git can preserve revisions | You edit the file | Repository permissions govern file access, not every agent response | You can remove the file. Repository history may retain it | Agents can use the same file if they read it | Wherever you host the repository |
| Zep | Unverified | Unverified | Unverified | Episode delete endpoint documented. Permanence unverified | Unverified | Unverified |
| Mem0 | Unverified | Update command documented. Revision history unverified | User ID scoping documented. Recall-time enforcement unverified | Delete command documented. Permanence unverified | Unverified | Platform API documented. Self-hosting unverified |
| Supermemory | Unverified | Unverified | Unverified | Unverified | Named coding-agent plugins and MCP clients documented | Hosted platform and local installation documented |
What Glen is and isn't
Glen’s supplied product description says it is hosted-only, with no self-hosted build. Its coding-agent memory page describes a shared service but does not independently confirm the absence of a self-hosted option. If you require local hosting, confirm that boundary with Glen before testing.
Glen’s supplied product description also says an agent must search for a memory to recall it. You should not assume Glen adds relevant history to every prompt. The description says “forget” hides a memory from search answers without deleting the stored record. The public coding-agent page does not verify either behavior, so test recall and deletion separately.
Glen’s public page confirms that agents within one organization share knowledge. Recorded sessions may therefore be discoverable by teammates, according to the supplied product description. Before treating any access or removal control as a compliance guarantee, check Glen’s current trust and privacy policies for privacy, retention, training use, and permanent deletion, and verify how those policies apply to your account.
Running the evaluation
If you move work between agents or teammates, run the five acceptance tests against your own repositories and agents before choosing a memory layer. Save the prompts and results so you can compare what each option actually retrieves, corrects, and restricts. A feature list cannot show whether those behaviors hold for your work.
If you work alone in one agent, repository instructions and built-in memory may be enough. For an overview of Glen, see its coding-agent memory page. If you need shared session history, set up Glen and run the same tests against it.
FAQ
How do “AI memory” and “persistent memory” differ? AI memory is a broad search term for information an agent can use. Persistent memory specifies that information remains available across sessions. Neither term guarantees accurate recall, source citations, or permanent retention.
Can built-in agent memory and a hosted layer run together? Yes. You can keep personal preferences in your agent’s built-in memory and use a hosted layer for decisions that another agent or teammate may need. Test which source the agent uses when the two disagree.
What evidence should we save from each acceptance test? Keep the setup, exact prompts, source sessions, agent responses, and any citation or retrieval records. Record the test date, agent version, account permissions, and vendor policy version so procurement and security reviewers can reproduce the result.
When should we rerun the suite after a vendor policy change? Rerun affected tests before relying on the changed policy. If the change concerns access, retention, or deletion, repeat the full suite before approving continued use.
