Memory
What your agents have learned. Memory holds durable insights a later session can recall: patterns, gotchas, decisions, task summaries, and importantly, things that were tried and failed.
Part of the brain.
Where memories come from#
You rarely write these by hand:
- After a coding run. The final step of
code-taskrecords what it learned about the project. - After any session. When a worker session ends, its transcript is summarized into project-scoped learnings and failed-approach notes, out of process, so even a quick one-off leaves a trace.
- During a session. An agent can record something the moment it learns it.
- By hand, from board or the CLI.
Disputes, or negative knowledge#
A dispute records "we tried X, it failed because Y". It is the most valuable kind of memory and is treated differently from the rest:
- It never decays.
- It outranks every positive memory type in recall.
- It is tagged with the files it concerns, so an agent about to edit a file can find out what already failed there.
This is what stops an agent from confidently re-attempting the approach that broke last month.
Recall#
A query is embedded and matched semantically, then re-ranked on more than similarity: how important the memory is, how recent, how often it has been useful, whether it shares code identifiers with what you asked, and whether it has been useful before. That last signal is real feedback, since a memory that helped a run that merged gets rated up, so recall improves with use.
If the local model host is unavailable, recall falls back to keyword matching rather than returning nothing.
The gate on global writes#
A memory scoped to one project is stored immediately. A global memory, one claiming to be true everywhere, is judged first by a local model. A confident accept stores it; a confident reject discards it; anything less lands in a review queue you work in board.
The gate fails closed. If the judge cannot run, the write still succeeds but lands pending, never silently approved.
Near-duplicates are rejected too: a write very close to something already stored in the same scope is skipped rather than stored twice.
The judge needs a chat model pulled locally. The embedding model is not enough. A host serving only it will embed fine and fail every judgement, and because the gate fails closed you will see a growing review queue rather than an error.
toryo doctorchecks for this specifically. Once the model is present,rejudgedrains the backlog.
Decay#
Memories fade on a schedule set by their type: a passing note fades in weeks, a real learning persists for months. Past its window a memory loses importance, and eventually is soft-deleted.
Anything you want kept permanently can be pinned, which exempts it from decay entirely. Disputes are pinned automatically.
Decay runs nightly on the scheduler's system lane.
In board#
The Memory screen browses and filters everything stored, works the global review queue, and lets you pin, rate, edit, or forget individual memories.
Full command surface: CLI & contract reference.