Every new Cursor chat starts without what the last one tried. What’s worked for me, with or without any tool:
Keep a short per-task note: what was tried, what was decided, what’s still open. Three headings, a few lines each.
Start the next chat by handing Cursor that note, not the whole history.
At the end of a session, ask the agent to rewrite the note. The “decided” lines are the valuable part: they stop the agent re-trying a fix you already ruled out.
I got tired of doing that by hand, so I built it into Deiko, an open-source Mac app (MIT). You point at the problem on screen and talk; it files each brief into its task and keeps that note for you. Cursor can read and update it through a local MCP server (search_briefs, get_task, list_tasks, save_outcome).
Curious how others here keep context between Cursor sessions.
Security note: it asks for Accessibility, Screen Recording and Microphone access and captures only while a session runs (a red bar shows). Screenshots never leave your Mac. It isn’t notarized by Apple yet, so read the install script first: https://github.com/maddy30445r/deiko/blob/main/scripts/install.sh
Hey, great topic to discuss, thanks for sharing your approach. The habit of keeping a short per-task note with a “decided” section is a really solid way to stop the agent from retrying things you’ve already ruled out.
If anyone wants a tool-agnostic option right inside Cursor, you can get the same effect using project rules and an AGENTS.md file in the repo root. You put decisions and open questions there, and the agent will pick them up in every new session. Docs: Rules | Cursor Docs
On the “memory between sessions” topic, there were also a couple community projects posted recently that might be interesting to compare approaches:
Small note for anyone installing it. Like you said, the app isn’t notarized yet and it asks for Accessibility, Screen Recording, and Microphone permissions, it’s good that you linked the install script. Everyone trying it should read the script before running it.
that decided section is the part i’d keep even after the session ends.
when the agent opens a PR, the reviewer has the same problem the next chat has: they see the final diff but not the approaches that got tried and dropped, so they end up suggesting one of them again.
pasting the task note, or just the decided lines, into the PR description fixes that for free.
does save_outcome write anything to the PR side, or does the note stay on the Mac?
Thanks Dean, and agreed: AGENTS.md / project rules is where anything stable should live. “We use pnpm”, “never touch the generated client”, that sort of thing. I think of the per-task note as the other half: the in-flight stuff that’s true for this bug this week and would just be noise in a rules file once it’s fixed. If it graduates to “true for the whole repo”, it moves into AGENTS.md.
I’ll have a look at those two projects, thanks for the links. And yes, please read the install script; it’s short.
Good question, and it’s the weak spot of a per-task note. Right now:
A decision lives in the task it came from, and it rides along with every later brief on that task until an agent retires it.
When one outgrows its task (“prices are always computed server-side”), I pin it as a project rule. Every brief in that project then carries it, whichever task it lands in. There’s room for five, on purpose, so they stay rules and don’t turn into a second memory.
For everything in between, the agent can search across tasks (search_briefs), so it can find “we already tried X in the coupon task”, but only if it thinks to look.
So the honest answer is that moving a decision from one task up to the project is still a manual step. Linking memories to files, the way you do, catches the case I miss: a different task touching the same file the old decision was about. I can see that being the better trigger for “check before you edit”. Nice approach.
Good point. The reviewer is just another “next chat” without the history.
Today the note stays on the Mac: save_outcome writes it into that brief’s folder, and nothing goes to GitHub on its own. Two ways to get it into a PR now:
The board can hand a task off as Markdown, so you can copy the note straight into the PR description.
The agent can read the note itself through get_task. So a line in AGENTS.md like “when you open a PR for a Deiko task, call get_task and put its Decided lines under ‘Tried and ruled out’” does it without any copy-paste.
I like the idea of making that automatic, though. The “Decided” lines are exactly what a reviewer is missing. Noted.
Excellent discussion. I’m glad the thread evolved into a comparison of approaches. The split of “AGENTS.md for stable context, per-task note for in-flight context” came across as very precise.
@Recallium, your comments are useful and relevant, thank you. One small request: this is @Madhur_Mittal’s showcase thread about his project, so calls to sign up and signup links are better not posted in someone else’s thread. Under our community guidelines, that falls under self-promotion. If you’d like to share more about Recallium, please start a separate thread in the Built for Cursor category. That would be fully appropriate there, and users interested in memory-related tools will have an easier time finding the project. Comparing approaches in the discussion is totally fine. The only issue is solicitation.
@Madhur_Mittal, thanks for keeping the security aspect visible. The app isn’t notarized, it asks for Accessibility, Screen Recording, and Microphone permissions, and the install script is included. That’s the right tone for a showcase.