AI agents need three different kinds of memory: extracted atomic facts, typed structured properties, and sectioned markdown documents they can revise like notes. The discipline is picking the right modality for the kind of knowledge. The unified save surface is what makes all three composable at retrieval time, which is the only place that matters.
An agent reading a transcript has three different things to remember
A sales call transcript lands in the system. The agent reads it. It needs to remember three different kinds of things, and the same store cannot serve all three.
The contact's job title is now "VP of Engineering." That is a typed property. It has a single current value. It needs to be queryable by filter ("all VPs of Engineering in healthcare"). It is the source of truth for whatever workflow asks "what is Jane's role?"
The CTO mentioned that they evaluated three vendors and chose Personize because of the audit trail. That is an atomic memory. It is a self-contained fact, citable, retrievable by semantic similarity, useful when an agent later asks "why did Acme choose us?" There is no single typed slot for it. It is a sentence that captures a moment.
The summary of the deal (the chronology, the key objections, the playbook the rep followed, the next steps) is a markdown document. The agent will return to it. It will get appended to as the deal progresses. It is the kind of thing a human would write in a notes app under a heading per topic.
Three different kinds of memory. One transcript. If your storage layer offers one modality, your agent will either over-fit the data to the wrong shape or just lose it.
This article is about the three save modalities that the unified save surface exposes, why each one is right for a different kind of knowledge, and how the same call (memory/save or context/save) can produce more than one at a time.
Modality one: atomic memories
An atomic memory is a single extracted fact with its own ID. The five quality gates that govern its extraction are explicit: coreference resolved (pronouns replaced), temporal anchored (relative dates resolved to absolute), self-contained (readable without surrounding context), atomic (one claim per memory), complete (all entities and references intact).
From a transcript, the extractor produces things like:
"The CTO, James Chen, mentioned on the October 2025 call that they evaluated three cloud migration vendors and chose Personize based on the audit trail capabilities."
"The VP of Engineering raised concerns about API rate limits during peak load periods on the second discovery call."
Each is one fact. Each gets an ID like [M3] or [M7]. Each is stored once and retrieved by semantic similarity, by property filter (when atomic memories are tagged with properties), or by direct lookup.
The shape is right for:
- Things said in conversations that you want to surface later by similarity
- Signals you want to attribute to a specific moment ("she said this on the Q3 call")
- Facts you cannot anticipate in a schema (the hiring of two platform engineers, the casual mention of a competitor)
- Content that needs to be cited individually
The shape is wrong for:
- Values that have a single current state (job title, deal stage, ARR)
- Notes that evolve in place (a running playbook, a deal review doc)
- Large coherent prose (a strategy doc, a guideline)
Atomic memories land via memory/save with the content body as the extraction input. The extractor produces N atomic memories per content (typically 5-20 for a transcript) plus typed property values. Both come from one LLM call.
Modality two: typed properties
A typed property is a schema-enforced field on a record. It has a type (number, string, enum, array, boolean), a current value, a confidence score, and an extraction history. It is queryable by deterministic filter, stage = 'qualified' AND revenue > 1000000 returns records in milliseconds with no LLM involved.
buying_stage: "Evaluating" (type: options, confidence: 0.88)
competitor_count: 3 (type: number, confidence: 0.90)
pain_points: ["API reliability",
"vendor consolidation"] (type: array, confidence: 0.85)
budget_range: 450000 (type: number, confidence: 0.92)
The schema is your highest-leverage piece of prompt engineering. Each property carries not just a type but a description, extraction instructions, examples, and measurement criteria, the LLM uses your schema as the system prompt for what to look for. (We cover this in Schema-Guided Extraction.)
The shape is right for:
- Single-valued state per record (stage, score, segment, tier)
- Values used in workflow triggers and filters
- Values that need cross-record aggregation (count of qualified deals, average ARR)
- Anything the downstream CRM or analytics layer expects as a typed field
The shape is wrong for:
- Open-set facts the schema does not anticipate (a hiring signal, a competitor mention)
- Free-form narrative (a deal summary, a playbook)
- Citation-required content (an audit-relevant quote)
Typed properties land via the same memory/save call that produces atomic memories. Extraction is dual-modality: one LLM call produces both. The cost-per-LLM-call is paid once; the output covers both stores.
The combination of atomic memories and typed properties is the subject of an earlier piece on dual memory at the storage layer. The measured coverage: 38% of valuable information is open-set only, 12% schema-enforced only, 34% captured by both, 16% missed by either. Combined recall reaches 82.8%. Neither modality alone is enough.
Modality three: markdown documents
A markdown document is a typed, sectioned, version-tracked text body. It has a type (guideline, playbook, reference, template, brief, or a custom org-defined type), a markdown content payload, optional sections that can be addressed individually, and a history of revisions.
// One document save
{
"name": "acme-deal-review-2026q2",
"type": "brief",
"value": "# Acme Q2 Deal Review\n\n## Background\nAcme is evaluating...\n\n## Stakeholders\n- Jane (CTO)\n- Marcus (CFO)\n\n## Open Risks\n- API rate limits...\n",
"updateMode": "replace"
}The four update modes give agents the same revising primitives Claude uses for its memory files:
replace, write the whole document freshsection, replace a specific section by headingappend, append at the endappendToSection, append inside a specific section without disturbing the rest
This is the right shape when the unit of knowledge is bigger than a fact but smaller than a database. A running deal review. A guideline document the team revises monthly. A playbook for a specific segment. An audit log the agent appends to. A reference doc cited across many records.
Documents land via context/save. They retrieve via the same unified retrieve as memories and properties (the documents source in the four-source payload), chunked semantically and ranked alongside everything else.
When you turn on aiExtraction, one call produces all three
Here is where the unified save surface earns its name. The context/save endpoint accepts a flag:
{
"name": "acme-deal-review-2026q2",
"type": "brief",
"value": "# Acme Q2 Deal Review\n\n## Background\n...",
"aiExtraction": true
}With aiExtraction: true, the markdown body becomes extraction input. The same extractor that runs on memory/save runs against the document content. The document is saved as a document. The atomic memories extracted from the body are also saved as atomic memories. The typed properties extracted from the body are also saved as properties.
One call. Three modalities. One LLM cost.
For an agent that wants to maintain a sectioned playbook that also surfaces its key facts in semantic retrieval and updates the relevant record properties as it writes, this is the right shape. The agent writes the prose; the system extracts what is structurable.
The reverse direction (atomic memories produced by memory/save later being assembled into a document) is the agent's job to orchestrate. The system gives both endpoints; the agent decides whether what it is about to save is a fact, a value, a document, or all three.
The retrieval consequence
The three save modalities map cleanly to three of the four sources the unified retrieve returns. Properties become the properties source. Atomic memories become the memories source. Documents become the documents source. The fourth source, graph, is the cross-record relationship layer that all three modalities can write into via the three channels.
The reason the modality discipline matters is that retrieval depends on it. A retrieval system cannot return clean typed values for a property that was stored as a paragraph of prose, or precise semantic citations for a fact that was buried in a long document chunk, or a coherent reading of a playbook from atomic memory fragments.
If the agent asks "what is Jane's stage?", the answer comes from properties.stage with no LLM in the read path. If the agent asks "why is Jane qualified?", the answer comes from atomic memories about the qualification round, cited individually. If the agent asks "what does our playbook say about vendor consolidation conversations?", the answer comes from a document chunk with its source heading and its position in the doc. Three different questions, three different storage shapes, three different retrieval mechanics, all served by one retrieve call.
The discipline at write time is what makes the retrieval surface clean. The unified surface enables it, but the modality choice is the architect's.
A decision rule
When an agent is about to save knowledge, run it through three questions in this order.
Is this a single current value for a typed slot on a record? (stage, score, role, ARR.) If yes, it is a typed property. Even if the source content is prose, the value belongs as a property and will be extracted into one. Use memory/save with the schema doing the work.
Is this an atomic fact with provenance worth keeping? (Something said in a moment, a signal, a quote, a discrete observation.) If yes, it is an atomic memory. Use memory/save. The extractor will produce N of these from one content body.
Is this a coherent body of prose that will be read in sections and revised over time? (A playbook, a deal review, a guideline, a brief.) If yes, it is a document. Use context/save with the right type and updateMode.
Is it both, a coherent prose body whose facts should also be extracted? Use context/save with aiExtraction: true. One call, three modalities.
The mistake to avoid is the modality monoculture. Teams new to memory systems often pick one storage shape (usually free-text chunks in a vector store) and try to make everything fit. The system holds together while the use cases are narrow. It falls over the first time a downstream workflow needs a typed value and gets prose, or the first time an audit asks for a quote and gets a paragraph that contains five different facts.
The unified surface is what lets the agent code stay simple while the storage layer stays correct. One call writes whatever shape the knowledge actually has. The retrieval layer reads it in the shape the consuming question needs.
The principle
Modality is a property of the knowledge, not the agent and not the API. A fact is a fact. A value is a value. A document is a document. The agent's job is to recognize which one it has. The save surface's job is to accept all three at the same URL with the same auth, the same identity model, and the same cost mechanics. The retrieval surface's job is to expose all three through the same call, with clean separation between them so the consuming agent can ask precisely what it needs.
If the storage layer mixes the three together (atomic facts buried in long chunks, typed values trapped in prose, documents fragmented into floating sentences) no retrieval API can recover what was lost. Modality discipline at write time is the precondition for everything that comes after.
The good news is that the discipline is small. One decision per save call, made from the shape of the knowledge in front of you. Pick the modality. Let the schema and the extraction handle the rest.
Companion pieces: Dual Memory on the storage layer behind atomic memories and typed properties. Documents Are Memories Too on the markdown-document modality in depth. One Call, Four Sources on the retrieval payload that exposes all three.