Memory

Memory is the lab that curates what your agents have learned, so they stop relearning it. Where the Ontology Layer holds the *structural* knowledge of a system — code, graph, docs — memory holds the *earned* knowledge: the decisions, conventions, and gotchas discovered while doing the work.

An agent that consults memory before it acts spends fewer tokens rebuilding context it already had, and stops repeating a mistake the team already solved.

What a memory item is

A memory item is one atomic, reusable fact. It records not just *what* but *why* and *where*:

axis:         "project"  (shared with the project's members)
              "agent"    (private to one agent + user pair)
memory_type:  a project-defined type, e.g. decision | convention | gotcha
what / why / where / learned:  the fact, its rationale, its location, its origin
status:       active | superseded | needs_review | archived

Types, schema, and the spine

Each project has a memory schema — the set of types it uses, inherited from the workspace base or overridden per project. A type can be marked canonical, which materializes its items into git-versioned chiron-memory/*.md files in the repo (the "spine"); non-canonical types stay retrieval-only. This is why memory can live *in* the codebase and survive the person who wrote it.

The lab

The Memory frontend visualizes a project's memory: a health dashboard (active / needs-review / superseded), a browsable searchable table, a 3D semantic map of the graph, usage analytics, a flow view of how queries reach items, and the spine's file tree. It also drives LLM-powered curation — judging, consolidating, and cleaning items.

Reaching it programmatically

Agents read and write memory through the Memory API and the memory_search / memory_stats MCP tools. To set an agent up end-to-end, see Give an agent project memory.

Next: Project chat.