Agents/The Agent Platform

Memory

Without memory, every conversation starts from zero. With it, the server distills each exchange into FACTS, persists them under a caller-chosen identity, and recalls the relevant ones as hidden context in later conversations, so the support agent's third session with a customer knows what the first two established. The design splits cleanly in two: the memory id says WHO is remembering; the store says HOW remembering behaves. Callers own the first; operators own the second.

1The memory id: identity, chosen by the caller#

memory on a chat request is an opaque id (letters, digits, dash, underscore) and the whole identity model: one id per customer gives per-customer memory, one per project gives project memory, one per team gives shared memory. The server never invents ids; scoping is a caller decision because only the caller knows what "the same conversation partner" means in its domain. Facts extracted from an exchange persist under its id; facts stored earlier under the same id come back as recalled context. An agent declaring memory intent tells clients to arm an id (the playground does it per conversation), and the agent's configured store applies even when the caller brings its own id.

2Stores: memory policy as configuration#

A store is a named policy bundle every memory id filed under it inherits, defined in the admin Memory section. The knobs, completely:

Knob	Governs
`max_entries`	Capacity per memory id; 0 is unbounded.
`eviction_policy`	What leaves a full memory first: `oldest`, `lowest-importance`, or `oldest-lowest-importance`.
`time_decay_half_life_hours`	Recall scores fade with age on this half-life; 0 disables decay, so facts stay evergreen.
`top_k`	How many facts one recall injects as hidden context.
`min_score`	The similarity floor a fact must clear to be recalled at all.
`extraction_mode`	`llm` distills each turn into facts; `none` makes the store recall-only (facts enter by other means, conversations only read).
`max_extractions_per_turn`	How many facts one turn may add, bounding runaway extraction.
`deduplication_threshold`	Similarity above which a "new" fact is recognized as already known and skipped.

Stores exist so DIFFERENT memories can behave differently without touching any caller: assistant memory might decay over weeks and keep five facts per recall; support-ticket memory might be recall-only, unbounded, and evergreen. memory_store on the request (or the agent's memory_store) selects one; absent, the default store applies, and defining a store named default re-shapes that default for the whole server.

3What gets remembered, and what it costs#

Extraction runs after the turn: the model distills what the exchange established ("prefers invoices summarized in French", "the contract renews in March") rather than transcribing it, deduplication keeps restatements from accumulating, and the per-turn cap bounds the write volume. Recall runs before the turn: the top facts by similarity (decayed by age when the store says so) enter as hidden context the model reads but the user never sees. The cost model follows: memory adds one bounded extraction per turn and a few hundred tokens of recalled context, not a growing transcript, which is what lets a memory span months without outgrowing the context window.

4Operating memory#

Memory is real user data, so it gets an operator surface, not just an API effect. The admin Memory section manages the feature switch and the stores, and the admin API inspects the contents: list a store's memory ids, list the facts under an id, delete a single fact, or trigger consolidation for an id. That is the toolkit for the questions production asks: "what does the agent know about this customer" (list), "forget that" (targeted delete, the data-subject request), and "clean up the accumulation" (consolidate). When the Memory feature is off, requests carrying memory fields proceed without memory rather than failing, so rollout and rollback are safe.

5Designing with memory#

Scope ids to the real continuity boundary. Per-user for assistants, per-case for support, per-project for research; an id too broad leaks context between contexts, too narrow forgets what it should know.
Let stores encode the domain's forgetting. Preferences should decay; obligations should not; tickets should close. That is three stores, not three codebases.
Recall-only stores are the injection path. Seed a store from your CRM export with extraction off, and the agent "remembers" facts no conversation ever taught it.
Memory is not retrieval. Facts about a counterpart belong in memory; knowledge shared by all callers belongs in Search as indexed documents. The support agent uses both: memory for THIS customer, retrieval for the product manual.

6Stated plainly#

The memory id is the caller's identity decision; the store is the operator's policy decision; the two compose per request or through the agent bundle.
Extraction is bounded and deduplicated, recall is scored and decayed: continuity without transcripts, priced in facts.
Memory is inspectable and correctable per fact from the admin surface, which is what makes it deployable where the remembered parties are real people.