(workspace, subject) and never crosses that boundary — which is why choosing the right subject grain matters so much.
Two kinds
Profile memories are durable facts about the subject — stable preferences, standing context. They are loaded into the agent’s context when a run starts. Episodic memories are records of past exchanges, retrieved by relevance rather than loaded wholesale. When a run needs one, the agent usesrecall, which searches that subject’s episodes semantically.
The tools
Two primitives appear only when the run has a subject:
Every run has a subject, so
remember is always available; recall appears once that subject has something to recall. A request that names no subject never reaches a run — it is refused with 400 subject_required.
Live and sandbox
Memory carries an origin. Runs from the Playground write tosandbox; everything else writes to live, and the two never mix. You can experiment with an agent’s behaviour without teaching your production agent anything.
That isolation only covers the Playground. API traffic is live even when you think of it as testing, so prefix test subjects — test:user_9f2 — if you want them separately erasable.
Erasing
Erasure runs from the dashboard under Memory. Deleting a subject removes every subject-scoped memory keyed on that exact string.What this means for your privacy posture
Memory is derived from conversations, so anything a user tells the agent may persist beyond the thread it was said in. Two consequences worth designing for:- Tell users what the assistant remembers, if your jurisdiction expects it.
- Wire your account-deletion flow to the erasure step, rather than treating it as a manual chore.