Memory
Memory is what an agent knows from its own earlier runs without being told again. The axis covers two things: where those memories are stored, and — the part that changes behavior — how they are ranked and pulled into the next run's context.
Ranking is the lever. A keyword provider surfaces memories that share words with the current goal. A semantic provider embeds both and surfaces memories that mean something similar even when the wording differs. Same stored notes, different selection, different context window, different answer. An agent whose notes say "lot full by 7am" will recall that against a goal phrased "is parking tight?" under semantic ranking and miss it under keyword ranking.
This is the sense in which the axes are hyperparameters. Swapping the provider does not change what the agent is for. It changes what the agent notices, and that shows up in the output.
Providers in this deployment
Read from the memory-provider registry at page load — not a maintained list.
| Firestore (keyword) | Ranks memories by word overlap with the current message. No external calls; always available. | available · default |
| Firestore (semantic) | Ranks memories by embedding similarity to the current message (Gemini text-embedding-004). Falls back to keyword ranking if embeddings are unavailable. | available |
| Firestore (extracted facts) | Distills each save into atomic facts with a fast model — mem0-style extraction and same-entity consolidation, on this platform's own store — then ranks semantically at recall. One extra model call per save, on the order of a tenth of a cent; if extraction fails the raw note is stored unchanged, flagged, never lost. | available |
| Mem0 | Managed memory service (mem0.ai): extraction and consolidation on their side, semantic search at recall. Enabled by adding your Mem0 API key. | not configured |
How to choose
Start on the default. Keyword ranking is cheap, deterministic and easy to debug: you can look at a memory and predict whether it will be recalled. Move to semantic when your agent's notes and its goals use different vocabulary for the same thing — that is the specific failure keyword ranking has, and the only one semantic reliably fixes.
Two things worth knowing before you switch. Semantic ranking calls an embeddings model, so it costs a little per run and is not byte-reproducible. And if the required key isn't configured, the run falls back to keyword ranking with a logged warning rather than failing — an agent that recalls less, never a dead agent.
The extracted-facts provider goes one step further: at save time a fast model distills the note into atomic facts and supersedes stale facts about the same entity, so recall runs over a deduplicated fact base. That is one extra model call per save — on the order of a tenth of a cent — and if the call fails the raw note is stored unchanged, flagged, never lost.
Switching provider never moves or loses data. All the Firestore providers read the same store, so you can change your mind.
There is an automated experiment runner: each agent's Tuning page (under /u/agents) can sweep the model, memory, planning, retrieval and state axes on one fixed objective — the agent's own declared eval, which is never swept, while guardrails only observes. Its limits are stated plainly: a naive full grid, several runs per cell, stopped cleanly at a hard budget wall with partial results kept. It compares compositions; it does not invent them.