What Grok Build and Claude Projects Reveal About Persistent Agent Memory

Imagine returning to a coding agent on Friday and asking it to ship a fix. On Tuesday, your team decided that integration tests must run with just test because the default command skips the test database. The agent should recall that decision, know which project it belongs to, and use a replacement command if the team changes the procedure today.

Persistent memory makes that continuity possible. Designing it means deciding what to keep, when to bring it back, and how to correct it. The test command is a useful example because remembering an outdated instruction can cause the same failure as forgetting the decision altogether.

A context window holds the current working material

A model's context window holds the material available for a request. The application decides which earlier messages, files, and retrieved memories to include. It also determines what survives between sessions and who can access it.

For the test command, repeatedly copying the full conversation into the prompt leaves the application carrying both the original instruction and its correction. A scoped record makes the accepted decision easier to identify and maintain. An illustrative application record might look like this:

fact: "Run integration tests with just test."
scope: project/orbit
source: conversation/2026-09-22/turn-18
status: confirmed
valid_from: 2026-09-22
supersedes: testing-rule-001
owner: engineering-team

This example is an application schema. Its fields capture the decision, its source, the project it applies to, and the instruction it replaces.

Four kinds of memory answer different questions

It helps to distinguish current working context from information retained for future tasks. The longer-term categories below follow the semantic, episodic, and procedural distinctions described in LangChain's memory overview.

One conversation may contribute to several categories. A failed test run is an episode; the accepted command becomes a project fact; the setup sequence becomes a procedure. Keeping those roles clear helps determine what to retrieve for the next task.

Products may organize these records differently. MemOS Cloud's memory categories include facts, preferences, profiles, events, skills, tool memories, and knowledge-base memories. For the coding example, an event can preserve what happened during the failed run, while a skill can capture reusable steps. The useful comparison is how each type supports the task and how it can be maintained.

The lifecycle is write, retrieve, update, and forget

Write. Capture information with a plausible future use, together with its source. Distinguish an explicit team decision from an agent's inference or a temporary workaround. In the example, a successful test run provides evidence that the command works; an authorized maintainer's confirmation establishes it as the project convention.

Retrieve. Restrict the search to authorized records before selecting relevant context. Account for freshness and source authority as well as semantic similarity. MemOS Cloud's time awareness is designed to distinguish current state from historical information. When importing older conversations, supplying chat_time anchors them to their original time instead of their ingestion time. Retrieved notes should remain subject to current instructions and application policy.

Update. A correction needs to change what the next task receives. MemOS Cloud provides two routes: Update Memory edits a known record by memory_id, while Add Feedback accepts a natural-language correction and locates relevant memories to update. A developer fixing a specific record can use the first; a user explaining that the test procedure has changed can use the second. Check the resulting retrieval after processing completes, including whether older information is still presented as current.

Forget. Expiry, correction, and deletion have different purposes. A temporary workaround may expire; a superseded rule may remain in an authorized history; a deletion request requires a defined removal process. MemOS Cloud's Delete Memory operation supports selected memory IDs, a user's memories, or an agent's independent memories within the API key's project. Agent-wide deletion requires independent agent memory to be enabled. This endpoint does not accept conversation or knowledge-base IDs; knowledge-base files have a separate deletion operation. The application's removal process also needs to cover any copies it keeps in caches, exports, logs, or backups under its retention policy.

Shared memory needs explicit boundaries

One agent's discovery can help another finish a task. Before sharing it, decide who should have access and who can approve changes. A practical application policy might use three scopes:

• Private: available to a specific user or agent.
• Project: available to authorized participants in the same project.
• Organization: available more broadly after review.

These are suggested application scopes. Assign an owner to shared records and log who promotes a private observation into a team rule, with its source and reason.

MemOS Cloud's isolation controls separate projects through API keys and personal memories through user_id. An agent_id can filter a user's memories; enabling independent agent memory creates a separate memory subject for the agent. A conversation_id provides retrieval context rather than an access-control boundary. The backend should map these identifiers to authenticated callers and their permissions.

For shared test procedures, MemOS Cloud knowledge bases allow project documents to be searched alongside personal memory. This lets an agent combine the maintained setup guide with context from a developer's earlier debugging session.

For a supported local agent host, MemOS Local Plugin connects memory capture and retrieval to the task lifecycle. It stores traces, skills, and logs locally, retrieves context before a task, and captures conversations, tool outcomes, and feedback afterward. Its viewer provides a way to inspect those records. This is a separate integration from MemOS Cloud, with its own storage and model configuration.

A small acceptance test for persistent memory

Before release, run one story across three sessions and two authorized agents:

1. Establish the rule. In Session A, a maintainer confirms the test command. Inspect the stored record, source, and scope.
2. Reuse it. In Session B, another authorized agent takes on a related task. Check the retrieved records, the context actually passed to the model, and the command it chooses.
3. Correct it. In Session C, the maintainer replaces the command. Repeat the task and check that the agent uses the updated procedure.
4. Test the boundary. Request the same information from an unauthorized user or project, including a request with altered identifiers.
5. Remove it. Delete the test record and repeat the relevant searches. Verify removal from the stores covered by the deletion policy.

Keep the record IDs, retrieval results, and executed commands with the test report. If the agent follows an obsolete rule, that evidence helps locate the failure in the stored memory, retrieval, prompt assembly, or the agent's use of the supplied context.