save_memory
Store lasting user memories across sessions, filtered by a quality gate to keep only important state like identity, projects, or preferences.
Instructions
Save a durable memory about the user through the Jamgate quality gate. Only call this for things worth remembering across sessions — identity, projects, preferences, lasting state — not chatter. Trivial or duplicate input is rejected by the gate.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The memory, as a clear standalone statement. Canonical field — always prefer it; `content` and `memory` are accepted as aliases for clients that send the memory under another name. | |
| type | No | Which memory layer this belongs to (RULES §4). | |
| scope | No | Optional namespace to save into, e.g. 'amir/greek'. Memories in different scopes never interfere — the gate (dedup, supersession, conflict) applies per scope, and recall/forget are per scope. Omit for the single default namespace, which is the normal single-user behaviour. | |
| source | No | Where this memory came from. Defaults to agent-inferred. | |
| subject | No | What this memory is about, e.g. 'operating-system', 'location', 'current-project'. If a newer memory shares a subject with an older one, the newer replaces it (time-aware supersession). ALWAYS pass this when the memory updates something already tracked — a progress figure, a balance, a status, a current choice — and reuse the EXACT subject string the earlier memory used. Without a matching subject the gate cannot tell an update from a new fact and both stay active. If omitted, the gate derives a best-effort subject from the text, and declines to guess when the text is long or covers several topics. |