Memory

Memory holds what is true: a fact, a preference, how something works. It is served back to every later session, on every client you have registered, so a thing said once does not have to be said again.

It has no status field. A fact does not finish, which is the whole reason tasks are a separate store rather than memory entries with a checkbox.

What your agent can do

Entries are also readable as an MCP resource at a stable address, memory://entry/{id}, for clients that read those.

Searching it

There is no index. One Markdown file per entry, frontmatter above the body, and nothing else, so listing and search read every entry and the audit annotation says how many were scanned.

That is a deliberate trade. An index would buy a cheaper listing at the price of a second copy of the truth, one that could disagree with the file it described and that nobody could open in an editor. At owner scale the scan is fine. If it ever had to serve tens of thousands of entries the fix is a derived cache that can be rebuilt from the files, never a second source of truth.

$ lanes link memory search "postgres" --profile personal --workspace local
$ lanes link memory get deploy-runbook --profile personal --workspace local
$ lanes link memory write deploy-runbook --profile personal --workspace local
$ lanes link memory forget deploy-runbook --profile personal --workspace local

The files are yours to edit

Frontmatter is optional on read. A plain Markdown file dropped into the directory is an entry titled after its id. The directory is one you are invited to open, and a parser that refused your file would make that invitation false.

Making memory read-only

This is the one risk in the built-ins worth an actual decision.

An instruction injected into memory once is re-served to every later session, including to a different agent on a different client. Nothing else in the system persists model-authored text and hands it back as context. A poisoned entry is not a bad answer once, it is a bad answer every time until you find it.

A read-only memory cannot do that, and it is one line:

$ lanes link policy deny memory.write memory.forget --profile personal --workspace local

You keep writing entries from the CLI, where you can see what you are writing. Your agents keep reading them. The only thing that goes away is a model's ability to author what it will later be told is true.

Keeping it in a repository

Memory, skills and entity files can live in a private GitHub repository instead, so they have a history and follow you between machines:

$ lanes link knowledge use github --repo <owner/name> --migrate --profile personal

That moves those three and nothing else. Tasks and assets stay where they are, and the vault, the credential store, and the audit log are never eligible. See Configuration for the block it writes and what it costs.

What is recorded

Ids and tags are kept. Entry text is withheld, and memory.search records nothing at all, not even the query: a search term is frequently more revealing than the result, because it says what somebody was looking for. See the audit log.

Next: Tasks for the store that does finish, or Built-ins for how the stores divide up.