Your agents forget everything.
This is where they stop.
A persistent, shared knowledge base your AI coding agents write themselves while they work. Decisions, architecture, pitfalls and conventions survive the session, the restart and the machine.
Close a session and the context window is gone. Project Memory is the part that stays: a long-term memory for AI agents, stored per project, read back by every agent and every teammate who opens that repo. No note-taking app on the side, no copy-paste, no re-explaining your codebase every morning.
Every AI coding agent has the same hole in it. It reads your codebase, works out why the auth module is built that way, hits the migration trap that cost you a weekend last year, and then the session ends and all of it evaporates. Tomorrow it starts from zero and rediscovers the same things, burning the same tokens.
You can paste some of it into a CLAUDE.md and hope it stays current. That works for rules you already know. It does not work for the knowledge your agents produce while they work: the decision they just made with you, the dead end they explored, the thing about your build that only becomes obvious at 2am.
Project Memory closes that loop. Your agents write what they learn into a persistent knowledge base, using MCP tools, as a normal part of doing the work. It lives with the project, not with your account, so the next agent reads it, and so does your teammate's agent on their machine.
Session amnesia, and what it actually costs
The symptoms are so familiar most people stopped noticing them.
You re-explain the same architecture
Every new session starts with you typing the same three paragraphs about how the project is wired. It is the single most repeated prompt in agentic coding.
Agents pay to relearn what they knew
An agent that has to re-read half the repo before it can act spends real tokens and real minutes rediscovering knowledge it already had yesterday.
The same trap gets sprung twice
A pitfall your agent hit and fixed in June is invisible in July. Nothing recorded it, so nothing stops the next agent from walking into it again.
Knowledge stays on one machine
What your agent learned lives in your session, on your laptop. Your teammate's agent knows none of it and starts the project from scratch.
What Project Memory gives you
A long-term memory layer for AI agents, built into the IDE where those agents already run.
Knowledge that outlives the session
Notes are stored server-side per project. Close the agent, quit the app, reboot the Mac, switch laptop: the memory is still there when you come back.
Written by the agents, not by you
Agents save through the memory_save MCP tool as part of normal work, with no confirmation prompt. You get a knowledge base that fills itself instead of documentation nobody updates.
Shared with everyone on the project
The memory is keyed to the project, not to your user account. Clone the repo, open it in AgentsRoom, and you read the same memory your teammates' agents have been writing.
Five folders that build themselves
architecture, decisions, conventions, pitfalls, features. Folders are created on first use, so the structure appears as the knowledge does. Nothing to set up.
Update over create, by default
Saving a note under an existing name updates that note in place. The memory gets deeper over time instead of sprawling into forty near-duplicate entries.
A real knowledge graph
Notes link to each other with [[wiki-links]]. Graph view draws those links, clusters notes by folder, and dims the ones going stale so you can see what your project actually knows.
Fuzzy search across everything
Search runs over note names, retrieval cues, full bodies and tags at once, so you find the decision you half-remember from two words of it.
Free, with no note limit
Project Memory is not a paid add-on and has no quota. There is no separate sync subscription to buy: memory and its graph are simply part of AgentsRoom.
The five folders your project fills in
Canonical structure, auto-created on first write. One topic per note, one note per idea.
architectureHow a module actually works and where its code lives. The note an agent reads instead of re-crawling twelve files.
decisionsOne note per decision: the context, the choice, and why. This is the part that stops someone quietly undoing it six months later.
conventionsThe rules discovered while working, not the ones you wrote down up front. Naming, patterns, the way this codebase does things.
pitfallsTraps, past incidents, never-do-this-again. A bug fixed once should never be paid for twice.
featuresThe functional state of each feature: what ships today, what is half-built, what was deliberately left out.
Three moments where knowledge gets captured
The hard part of any knowledge base is getting anything written into it. Project Memory attacks that from three sides.
As it happens, by default
Every agent in AgentsRoom gets the memory instruction in its system prompt: after a significant outcome, a decision made, a pitfall hit, a module understood, a feature shipped, write it down. Unlike saving a skill or a prompt, memory writes need no confirmation. It is a normal working gesture, so it actually happens.
Always memorize, per agent
Flip the Always memorize toggle on any agent and it gets a stricter rule: at the end of every turn that produced a durable learning, persist it before finishing. Useful on the roles that generate a lot of knowledge, like an architect working through a refactor or a QA agent mapping failure modes.
On the way out
When you close an agent that still has a live session, AgentsRoom asks whether to memorize first. Choose Memorize and the instruction goes into the running session so the agent writes down what it learned before you close the tab. The one moment where knowledge is usually lost becomes the moment it gets saved. Short sessions are skipped automatically, because a two-minute errand is not worth a memory, and you can opt out of the prompt for one agent, one project or everywhere.
See what your project knows
Graph view turns the memory into a map instead of a list.
Every note is a node. Folders form clusters. The [[wiki-links]] agents write inside note bodies become the edges, so the graph draws the actual shape of your project's knowledge rather than a folder tree.
Freshness drives the visuals. A note updated recently is bigger and brighter; one that has not been touched in weeks shrinks and fades, on a sixty-day horizon. Stale knowledge looks stale, which is exactly when you want to notice it. Click any node to open that note.
One memory per project, not per person
This is the part most memory tools get backwards.
Most knowledge tools scope everything to a user account: your notes, your vault, your sync. That model breaks the moment a second person joins, because the knowledge that matters is about the project, not about you.
AgentsRoom keys Project Memory to the project id committed in the repo. Everyone who opens that project reads and writes the same memory. A teammate clones the repo, opens it, and their agents inherit everything yours have learned. No invites to send, no vault to share, no export and re-import.
One consequence worth knowing: access is capability-based. Being logged in and having the project id is what grants access, so treat the memory of a public repository as public. Agents are instructed never to store secrets or machine-specific paths in it, and you should not either.
Three tools, and your agents do the rest
Project Memory is exposed to agents over MCP, so any connected agent CLI uses the same interface.
memory_listLists folders and notes with their retrieval cues and a content preview. Agents are told to call it at the start of any non-trivial task, before exploring the codebase: the module may already be explained.
memory_getReturns the full markdown body of one note, by id or by exact name. Names are how wiki-links resolve, so an agent can follow [[a-link]] from one note straight into the next.
memory_saveCreates or updates a note. Same name means update in place. Takes a name, a retrieval cue, the markdown body, an optional folder and tags.
Provider-agnostic by design: the tools are served by the AgentsRoom MCP server, so Claude Code, Codex CLI and the other agent CLIs you run in AgentsRoom all read and write the same project memory.
How it works
There is no setup step. The memory starts empty and fills itself.
Your agents start reading
From the first session, every agent is told to check the project memory before it starts digging through code. Early on it finds nothing and gets on with the work.
Your agents start writing
The first real decision, the first pitfall, the first module properly understood: the agent saves a note. Folders appear as they are needed. You can watch the count climb on the brain icon in the dock.
Every session after that is shorter
New agents open with a working understanding of the project. You stop writing the same three paragraphs of context, and the agent stops paying tokens to rediscover what it already worked out.
Where it earns its keep
The knowledge that used to live in one person's head, or nowhere.
Agencies juggling client codebases
Twelve client projects, each with its own quirks. Every project carries its own memory, so picking one back up after three months does not mean relearning it from the commit log.
Onboarding, human or agent
A new developer clones the repo and their agents already know the architecture, the conventions and the traps. The memory is the onboarding doc, except it is current because it was written while the work happened.
Legacy code nobody remembers
Point an agent at the crusty module, let it work out how it functions, and have it write that into architecture. The next person to touch it starts from an explanation instead of a mystery.
Handoffs between agents
A PM agent scopes, a dev agent builds, a QA agent verifies. Each writes what it learned, and the next one reads it, so the chain does not lose the thread between steps.
Memory, skills and prompts are not the same thing
AgentsRoom keeps three libraries because they answer three different questions.
Project Memory
What is true about this project?
Facts the agents discovered: decisions, architecture, pitfalls, conventions, feature state. Written by agents, shared with the whole project, specific to this codebase.
Skills Library
How do we do this kind of task?
Reusable procedures that load when relevant: a review checklist, a migration pattern, an accessibility audit. Portable across projects and exportable to other tools.
Explore the Skills LibraryPrompt Library
What do I want to ask, again?
The instructions you send often, saved and organized so you stop retyping them. Written by you, sent by you.
Explore the Prompt LibraryProject Memory is one answer to agent memory, not the only one. CLAUDE.md files, mem0, Letta, Zep, basic-memory and Obsidian with MCP each solve a different slice of the problem.
Compare AI agent memory toolsFrequently asked questions
What is Project Memory in AgentsRoom?
Project Memory is a persistent, shared knowledge base attached to a project. Your AI coding agents write notes into it while they work, using the memory_save MCP tool, and read from it with memory_list and memory_get. The notes cover architecture, decisions, conventions, pitfalls and feature state. Unlike an agent's context window, which is wiped when the session ends, the memory is stored server-side and survives sessions, restarts and machines.
How is this different from a CLAUDE.md or AGENTS.md file?
They complement each other. A CLAUDE.md is a static instruction file you write and maintain by hand: the rules you already know, loaded at the start of every session. Project Memory is dynamic and agent-written: it captures what your agents learn while working, note by note, and grows without you maintaining it. In practice CLAUDE.md holds your conventions and commands, while the memory holds the accumulated understanding of the codebase, the decisions and the traps. AgentsRoom lets you edit your CLAUDE.md from the UI too.
Do my teammates see the same memory?
Yes. Project Memory is keyed to the project id stored in the repo, not to your user account, so everyone who opens the project in AgentsRoom reads and writes the same memory. Your teammate clones the repo, opens it, and their agents inherit everything yours have learned. There is nothing to invite, export or import. Access is capability-based: being logged in and having the project id is what grants access, so treat the memory of a public repo as public and keep secrets out of it.
Is Project Memory free?
Yes. Project Memory is included in AgentsRoom at no extra cost and has no note limit. There is no separate sync subscription and no paid add-on for the knowledge graph. You do need to be logged in, since the memory is stored server-side so it can be shared across the project's users.
Which AI agents can use the project memory?
All of the agent CLIs you run inside AgentsRoom. The memory tools are served by the AgentsRoom MCP server rather than being tied to one vendor, so Claude Code, Codex CLI and the other supported CLIs all read and write the same notes. That is the point of putting the memory in the IDE instead of inside one provider: switching agent does not lose your project's accumulated knowledge.
Do I have to tell the agents to save things?
No, though you can. Every agent gets the memory instruction in its system prompt and saves after significant outcomes on its own, with no confirmation prompt. On top of that you can turn on Always memorize for a specific agent, which makes it persist a learning at the end of every turn that produced one, and when you close an agent with a live session AgentsRoom offers to have it memorize the session before you shut the tab.
Can I read and edit the memory myself?
Yes. The brain icon in the dock opens the memory, with a badge showing how many notes exist. You get a folder sidebar, fuzzy search across names, cues, bodies and tags, and a full editor to create, rename, duplicate or delete notes and move them between folders. There is also a graph view that draws notes as nodes, wiki-links as edges, and fades notes that are going stale.
Does Project Memory work offline?
Partly. The desktop app keeps a local cache of the memory in the project folder, so the AgentsRoom UI can still show your notes without a connection. The agents' memory tools do talk to the server on every call, so agents need connectivity to read or write. The cache file is gitignored, so it never pollutes your repository.
What should not go into the project memory?
Secrets, credentials, tokens and machine-specific paths. The tool description agents receive forbids storing them explicitly, and you should follow the same rule when writing notes by hand. Memory is for distilled, durable knowledge about the project: decisions and why they were made, how modules work, traps to avoid, conventions in force. Session chatter and one-off details do not belong in it.
Can I turn Project Memory off?
Yes, at several levels. Memory is on by default, and a single toggle in the project's agent defaults turns it off for that project: no memorize prompt when closing an agent, no memory instruction in system prompts, and agents are told the memory tools are unavailable. You can also keep memory on but silence the close prompt only, for one agent, for one project, or globally. Nothing is deleted when you turn it off, so switching it back on restores the notes you already had.
You may also like
Skills Library
Reusable procedures your agents follow, attachable to tasks and agents.
AgentsRoom MCP
The MCP server that exposes the backlog, prompts, skills and memory to your agents.
Context drift detection
Spot the moment an agent's context degrades, before it starts inventing things.
CLAUDE.md guide
How to write the static instruction file that pairs with your project memory.
Stop re-explaining your codebase
Download AgentsRoom and let your agents start remembering. Free, no note limit.
Companion app: monitor your agents on the go
Bring your own: Claude, Codex, Antigravity CLI, or other AI provider.
Push bugs and requests straight to your public backlog.
A glimpse of AgentsRoom in action.