Stele vs the usual ways to give agents memory

The question that sorts them

Nearly everything in this space ships under the word memory, which has stopped carrying information. Three narrower questions separate the options cleanly, and every real difference below is one of these three wearing a costume.

1. Who is the memory for? One agent, one person, one team, or the users of a product you are building.
2. What can read it? One vendor's tool, any tool, or only your own application code.
3. What happens when a fact stops being true? Nothing, somebody edits it, or the system does something about it.

Stele's answers: a project and everyone working on it, any agent that speaks a tool protocol, and a lifecycle that retires facts on its own. Whether that combination is worth anything depends entirely on which row of the table below you are in.

A file in the repo

Genuinely good at: costing nothing, working in every tool, being reviewed in the same pull request as the code it describes, surviving your vendors, and working on a plane. That last set is not a small list, and nothing else on this page replicates all of it.

Where it stops: the file has no opinion about which of its lines are still true, retrieval means guessing the word it was written with, and when the agent cannot find the right paragraph it loads the whole thing. Those three failures arrive together, roughly when the pile outgrows one person's head.

Stay here if one person can keep the folder honest by hand. That is a real answer, not a consolation prize, and it covers a lot of projects. We went through the three failure modes in detail separately, including how to tell when you have hit them.

Notion, Obsidian, or a team wiki

Genuinely good at: long-form writing for humans. Onboarding guides, architecture essays, design proposals with diagrams and comment threads. Better at that than a knowledge graph will ever be, and your team is already in it.

Where it stops: your coding agent does not open the wiki before answering you, and it does not open the wiki before editing a file. Retrieval requires a human to remember the page exists and go and paste it in.

A polished knowledge base the agent never opens is documentation you hope someone finds. It is not agent memory, and the polish does not change that.

There is a second problem that is nobody's fault. Wiki pages are written as documents, and documents get updated when someone reorganises them, not when a decision inside them reverses. The unit is too big. A page called Authentication can be simultaneously current in three sections and wrong in a fourth, and nothing about the page can express that.

Keep it for the human-readable half. The two are not mutually exclusive and we use both.

Memory built into the harness

Genuinely good at: zero setup, and knowing things about the tool it lives in that no external system can see. If you use one agent and only one agent, this is likely to be enough, and it is free.

Where it stops: the memory is scoped to the vendor. Which means it has a property worth naming plainly: the better it gets, the more you lose when you switch. It is also usually per-person, so on a team you end up with several private, divergent pictures of one shared project, and no mechanism by which any of them would discover the others.

The thing to watch as vendors ship here is not whether they built memory. Everyone will. It is whether you can get it out.

Stay here if you use one tool and work alone. Move when you notice you are re-explaining the same architecture to a second agent every week.

Memory APIs: Mem0, Zep, and the rest

Genuinely good at: being memory infrastructure for an application you are building. If you are shipping a support agent or a consumer assistant and you need it to remember users across sessions, this is the correct category and we are not an alternative to it.

These are the most technically overlapping systems on this page, and some of the ideas are close to ours. Zep's Graphiti tracks when a fact was valid and invalidates it on contradiction rather than deleting it, which is a real retirement model rather than a marketing claim about one. Anyone telling you that nobody else handles stale facts has not looked.

The difference that matters is authorship, and it shapes everything downstream. These systems mostly extract facts from conversation: an entity pipeline reads a transcript and infers what should be remembered. Stele's entries are written on purpose, typed at the moment of writing, by whoever knew the thing.

extracted     "user prefers dark mode"          inferred from a transcript
              "project uses postgres"           inferred from a transcript

authored      decision · "Rate limiter goes in front of auth"
                reason:   Nov 2025 outage, unauthenticated traffic
                          reached the metered path
                anchors:  src/middleware/index.ts, buildMiddlewareChain
                retires:  when superseded, with the reason recorded

Extraction scales to conversation volume and gets you facts nobody would have bothered to write down. Authoring gets you a reason, a type, a set of anchors, and a retirement condition, none of which can be reliably inferred, because the person deciding is the only one who knows why.

Buy a memory API when you are building an AI product. Do not buy one when you want a record your coding agents share.

Coding agents that are memory-first

Genuinely good at: deep integration. When memory is a first-class part of the agent rather than a plugin on top of it, the agent can do things a plugin cannot, and the experience is more coherent than anything bolted on.

Where it stops: it is a harness, so adopting it means adopting that harness. If the tool you want is the tool you are already using, the memory is not available to you.

This is a real fork in the road rather than a flaw. The bet on that side is that memory is important enough to pick your agent around. Our bet is the opposite: that people will keep using several agents and changing them, so the record should sit underneath and outlive whichever one is connected today. Both bets are defensible. Ours is worse if the field consolidates onto one tool.

Not a replacement for Linear or Jira

Stele has tasks, so this comes up. The tasks exist for one reason: agents need a unit of work that can be atomically claimed, or two of them do the same thing at once. That is coordination primitives, not a planning suite.

There is no roadmap view, no sprint planning, no stakeholder reporting, and there should not be. Those tools own how a company plans. Reach for a shared record when the missing piece is what agents know between sessions.

Side by side

The bet, stated so you can disagree with it

Nothing in the middle column above is unique to us, and we are not going to pretend otherwise. Retirement on contradiction exists elsewhere. Cross-tool access exists elsewhere. Task coordination obviously exists elsewhere.

The specific bet is that these three belong in one record:

• Knowledge that is authored and typed, with a reason and a retirement condition chosen when it is written.
• Work that is claimable, so several agents can run without colliding.
• Both of them readable by whichever agent you happen to be using, and by a person on a phone.

Split those across three products and the connections between them disappear, and the connections are where most of the value is: a risk that retires because the task fixing it closed, a decision that surfaces because you touched the file it is anchored to, a completion note that explains a feature nothing else documents.

If you think agents will consolidate onto one tool with excellent native memory, this bet is wrong and you should not take it.

When to skip us entirely

• A file and an occasional prune covers your project. Keep it. It is simpler and it is free.
• You need memory inside a consumer AI product. Buy a memory API.
• You need planning for a large organisation. Buy a planning tool.
• You cannot take a hosted dependency. An open, self-hostable path is planned, and we will say so here when it exists rather than before.

What is left is narrower than a landing page usually admits, and it is also the case we are best in the world at: teams whose facts go out of date, who use more than one agent, and who need to know which parts of what they wrote down still hold.

For that case the answer is not a wish. A reversed decision stops being served the moment something replaces it, and comes back marked, with its reason, ranked below its replacement. A lesson anchored to a file fires when somebody edits that file. A risk bound to a task retires itself when that task closes. Work is claimed atomically, so two agents never do it twice. All of that is running today, in ten harnesses, on one record your whole team reads.