Stele vs the usual ways to give agents memory
When people ask what Stele is “like,” they usually mean one of five different jobs. A file in the repo. A wiki. Memory built into the IDE. A memory API for product builders. Or a coding agent that keeps its own notes. Those are not the same problem, and treating them as peers makes the comparison nonsense.
What Stele actually is
Stele is a shared project record for work you do with AI agents. Decisions, lessons, risks, and tasks live in one place. Every agent on the project can read that record before it acts, and write back what it learned. Humans see the same thing in the web app.
If that sounds like “memory,” fair. Half the market is shipping under that word right now. The useful question is narrower: who is the memory for, which tools can see it, and what happens when a fact stops being true?
A CLAUDE.md (or AGENTS.md) in the repo
This is the right starting point for a lot of people. You write notes next to the code. Any agent that can open a file can read them. No account, no server, no new product.
The failure mode shows up later. Nothing marks which files are still true. Finding the right note means already knowing what to grep for. The pile grows, rules go stale, and you end up with a graveyard of instructions nobody trusts. If one person can keep that folder honest by hand, stay there. When you cannot, the file stopped being a system.
Notion, Obsidian, or a team wiki
Great for humans writing docs. Weak as agent memory for a boring reason: your coding agent does not open the wiki before every prompt, and people do not update the wiki every time a decision flips.
A polished knowledge base the agent never reads is not project memory. It is documentation you hope someone finds. Use it when people are the primary readers and agents are occasional.
Memory inside Cursor, Claude Code, Codex, and friends
Harnesses are adding memory of their own. That is good news for the category. It also tends to stay inside one vendor. Claude’s project memory is for Claude. Cursor’s is for Cursor.
If you live in one tool, that may be enough. If you plan in one agent, build in another, and switch when a quota fills, each silo recreates the continuity gap you were trying to close. Stele treats native memories as inputs when they are readable. The thing to watch as vendors ship is not whether they built memory. It is whether you can export it.
Mem0, Zep, and other memory APIs
These are loud and well funded, and they sell to a different buyer: teams putting memory inside their own AI product. Chatbots, support agents, multi-agent frameworks. The pitch is “add memory in a few lines of code,” with integration lists full of LangChain, CrewAI, and AutoGen.
Some of the ideas are close. Graphiti (from Zep) tracks when a fact was valid and invalidates it on contradiction instead of deleting it. That is a real supersession model. The difference that matters for coding teams is authorship. Those systems usually extract entities from conversation. Stele’s nodes are written on purpose as typed project facts (decision, lesson, risk, architecture), with a lifecycle you choose when you save them.
Mem0’s OpenMemory MCP is the overlap with coding agents today. It stores preferences for Cursor and Claude Code. Useful, single-player, and not a shared project graph with tasks and provenance. Buy a memory API when you are building an AI product. Do not buy one when what you need is a ledger your coding agents share.
Memory-first coding agents (like Letta Code)
Some products put memory at the center of a different coding agent: a CLI you run instead of Claude Code or Cursor, with its own remember commands and memory store. That is a real alternative if you are willing to switch harnesses.
Stele makes a different bet. It is a plugin and a hosted graph on top of the agents you already use. The record is shared across them, with tasks and claims in the same place as the knowledge. Private long-term memory for one agent is a harness problem. Shared decisions and open work for every agent on the project is a ledger problem.
And no, Stele is not “Linear for agents”
Stele has tasks. Agents claim them so two sessions do not do the same work. That is coordination, not a product-management suite. Linear and Jira own issues, roadmaps, and how companies plan. Use those for the company’s planning surface. Reach for Stele when the missing piece is what agents remember between sessions, and how that memory stays honest.
Side by side
| Approach | Who reads it | Shared across agents? | Who keeps it true? | Best fit |
|---|---|---|---|---|
| Repo markdown | Whoever opens the file | Yes, if committed | You, by hand | Small solo notes |
| Wiki / Notion / Obsidian | Humans | Only if you wire agents in | Whoever edits the wiki | Human documentation |
| Native harness memory | One vendor’s agent | Usually no | Varies | One-tool workflows |
| Memory APIs (Mem0, Zep, …) | Your product’s users | Inside your app | Vendor-claimed; mixed evidence | Building AI products |
| Memory-first coding agent | That agent | Per agent / harness | Varies | Switching to that harness |
| Stele | Your agents and your team | Yes, across harnesses | Lifecycle, supersession, review | Shared project ledger |
What you get if Stele is the right fit
Same graph when you change tools. Plan with one agent, build with another, hand off when a quota fills.
A loop, not a store. Free graphs and RAG libraries give you storage or retrieval. You still have to operate the rest: read context before every prompt, write mid-task, claim work, retire stale facts. Stele is that loop, hosted.
Maintenance that is part of the product. Expiry, task-binding, supersession, and review exist so the record does not quietly rot the way a growing markdown folder does.
When to skip Stele
If a CLAUDE.md and a weekly prune cover your life, keep that. It is simpler. If you need a memory backend inside a consumer AI product, buy a memory API. If you need full product management for a large org, buy a PM tool. An open, SQLite-backed path for self-hosting is on the roadmap. Until then, Stele is the managed loop for teams that want the graph everywhere, not only in one checkout.
Further reading
- Core concepts: the model behind the ledger
- When facts conflict: how supersession works
- The self-repairing graph: how the record stays honest
- Install and first run