Project memory
Project memory is the shared record of what your project decided, what it learned, what it risks, and what it is working on. In Stele, every agent reads it before it acts and writes back what it found, so the next session, the next tool, or the next teammate starts from what the project already knows.
How it differs from a chat's or a tool's memory
Two other kinds of memory get called by the same name, and it helps to separate them.
- A chat's memory is the conversation itself. It ends when the session ends. A new session starts blank, and you explain the project again.
- A tool's memory is what one coding agent saves for itself, usually on one machine. It survives the session, but a different agent, a second laptop, or a teammate never sees it.
- Project memory belongs to the project. Claude Code, Cursor, Codex and any other MCP client read the same record, and your teammates see it in the web app. What one of them learns on Tuesday is there for the others on Wednesday.
What goes in it
The record is a graph of small, typed entries, each filed under a part of your system and linked to the entries it relates to.
- Components
- The parts of your system, nested into a tree:
billing,auth,api/webhooks. Everything else lives under one, which is what lets the record answer "what do we know about billing?" - Knowledge
- Short facts with a category. The ones you will see most:
- Decision: "Webhooks are retried from a queue table, not in the request handler."
- Lesson: "Mocking the payment client hid a timeout bug in production. Integration tests hit the sandbox."
- Risk: "The nightly export holds a lock on the orders table; a migration run during it will stall."
- Architecture: "Search reads from a replica that lags up to a minute."
- Tasks
- The work in flight, claimed by one agent or person at a time, and closed with a note of what actually happened.
- Documents
- Longer material that does not fit in one fact, such as a design spec or an audit, linked to the tasks and decisions it explains.
The links are what make it memory rather than a notes folder. From a task you can walk to the risk it carries, and from a decision to the work it shaped. Core concepts covers the full model.
How agents read it
You do not ask for context. Once your agent says what it is working on, Stele walks the graph alongside the conversation and hands it the decisions, lessons and risks that bear on that work, before it answers. A note tied to specific files also surfaces the moment an agent edits one of those files.
Agents can also search the record directly when they need something specific. How agents use Stele walks through both.
How agents write to it
The record fills up as a side effect of the work. When an agent starts a change, it finds or creates the task and claims it. When it learns something the code does not show, such as why an approach was rejected or what broke, it writes that down as knowledge, linked to the task. When it finishes, it closes the task with a note of what changed. You can also bring existing material in: past history through backfill, and meeting notes or design docs through ingest.
How it stays true
A memory that serves an outdated fact with confidence does more harm than no memory. So every fact carries a way to stop being served, chosen when it is written:
- Supersede. A new decision retires the old one. The old one stays in the graph, marked as replaced and pointing at what replaced it, so the history remains readable.
- Expire. A fact that is only true for a while carries a date and retires itself when it passes.
- Bind to a task. A risk that a task will resolve is archived when that task closes.
- Review. Facts that have not been checked in a long time are flagged, and a review pass verifies them against the code.
When facts conflict and the self-repairing graph cover the mechanism in full.
Who can see it
A project's memory is visible to the project's members and no one else. Projects are private by default. You can make a project public, which puts its record on a public page anyone can read and ask questions of, without being able to change it. Your source code never enters the record: it stays on your machine, and only what your agents write down is stored. Your data has the details.
You do not need to seed the record before it helps. Connect one agent, work as usual, and let the first week of tasks and decisions accumulate. Backfill can fill in the history later.