I want an agent’s context to follow the task, not a fixed checklist of what to remember.
Here’s a made-up example. A team added a response cache, found that it served stale data, then disabled it while they investigated. The project memory still holds the service overview, the original decision, the incident and the decision to turn caching off.
Now give the agent three jobs:
Fix the cache bug. I want it to see the failing case and know that caching is currently off. The original design may help, but it isn’t permission to turn the cache back on.
Explain the service to a new teammate. I want the service overview and the current limitation. I don’t need the whole incident history in that explanation.
Explain why we turned caching off. Here I do want the history, including the old decision and the one that replaced it.
Nothing in the stored memory changed between those requests. What I need from it changed. Some context can stay the same, but the old decision should be available when I ask about the past without showing up as current advice.
In your Cursor setup, what decides which of those notes the agent sees when you switch tasks?
Disclosure: I co-founded Mnemoverse. I’m describing how I want this to work, not claiming a shipped feature.
I think this gets even more important once agents can take actions instead of just answering questions. Using outdated context to explain something is annoying. Using outdated context to deploy code or re-enable a feature could be a production incident. It feels like agents need a way to distinguish historical context from currently authorized state.
In plain Cursor, what decides it is the rule type you give each note, plus whatever you @-mention. Nothing re-selects notes per task on its own.
How I’d map your three jobs:
Service overview: AGENTS.md, or one rule with alwaysApply: true. Keep it to current state only (“response cache: currently off, see decisions”).
Decisions: one .mdc per decision, each with a description and a status line (current / superseded by X). With no globs and alwaysApply off, the agent pulls a rule in when its description matches the task. Give the “cache disabled” rule a glob on the cache code, so “caching is off, and the original design is not permission to turn it back on” comes along whenever those files are touched.
History: keep the incident and the old decision in a log that nothing auto-loads, and @-mention it when you ask “why did we turn caching off”.
The weak spot is that “superseded” is just text the model has to respect, so I’d add one always-on line: superseded entries are history, not current guidance.
I work on MemorySync, a hosted memory server that Cursor can use over MCP, so here’s the same setup there: the agent searches memory for the task at hand instead of loading a fixed set of notes, and memories have typed relationships, including contradictions, which the agent can follow when you ask about the past. It doesn’t make the “is this still current” call for you, so I’d keep the status line and that one rule either way.
I want the old decision to stay in memory, linked to the one that replaced it. For a task about the current system, I’d normally leave the old decision out of context; for ‘why did we change it?’, I’d want both. Does your search expose an explicit replacement link, or does the agent have to infer that from the status lines?
Short answer: there is an explicit replacement link, but search itself doesn’t hand it to you. I work on MemorySync, so here is what our docs actually say.
When a memory’s content is replaced, it gets marked as superseded, and its history shows a superseded entry that points at the memory that replaced it. You can also add typed relations between memories (like contradiction or references), and add your own relation types, such as a custom “supersedes”. The memory graph endpoint returns those edges. So for “why did we change it?”, you can follow the link from the old decision to the new one without guessing.
What the docs don’t say is whether a plain query result carries that link. The documented query response lists memories but no supersession field. Today I’d query first, then check history or the graph for the decisions it returns. Docs: Quickstart | MemorySync Docs
I don’t think the coding agent should be responsible for maintaining project memory. I’d keep it as a structured graph linking files to components, requirements and decisions. The agent can then follow the links relevant to its task, with current state kept separate from history. That’s the approach we’re taking with Reqode.
I want the same separation between stored project knowledge and the context for this task. In my cache example, fixing the bug and explaining why the cache was disabled should pull different parts of that graph, even though the stored history is unchanged. How does Reqode choose that slice for each request?
The coding agent still chooses what to retrieve through MCP. It can start from a file and follow links to the component and current specs. For “why was caching disabled?”, we’d start from the Change Request recording that decision and its rationale. We don’t automatically choose a graph slice from the prompt. I meant separating maintenance of project knowledge from retrieval for a task.