remember
Store one or more new memories (concepts, decisions, findings). Before filing, search for related content first — use the search results to infer the domain: if related memories exist in a domain, file there. Prefer existing domains over creating new ones; only propose a new domain if no related content is found anywhere. Single: pass fields directly — returns {memory, suggested_connections, applicable_standing_rules}. Batch: pass {items:[{label,domain,...},...]} — returns {memories:[{memory,suggested_connections,applicable_standing_rules},...]}. After filing, review applicable_standing_rules first — these are domain-scoped standing rules surfaced independently of semantic distance so they cannot be crowded out; any with a linkback directive (e.g. "connect each shipped story back here") must be connected immediately. Then review suggested_connections for agreement or contradiction with what you just filed — not only for connect opportunities. Semantic similarity reflects aboutness, not agreement; the server surfaces candidates that may warrant your review but never asserts they conflict. When a filed memory is close enough to an existing memory that they may be worth comparing, the response also includes possible_contradicts=true and possible_contradicts_candidates (id, node_kind, semantic_distance, authority_severity) — same aboutness-not-agreement caveat: the server flags these as worth your attention, never as confirmed contradictions. Review them and call connect(relationship=contradicts) if you judge they actually conflict. ALWAYS call connect for any suggested_connections you accept before ending your session (batch: connect each accepted candidate). On failure, content[0].text is JSON: {"error_class": "conflict|retryable|forbidden|validation|internal", "message": "..."}. Switch on error_class: retry on retryable, surface message on validation, treat conflict as duplicate.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional caller-supplied id instead of an auto-generated one. For idempotent external imports: if a memory with this id already exists, remember fails with error_class=conflict rather than overwriting it — call recall(id) to check first, or treat a conflict response as already-imported. | |
| tags | No | ||
| items | No | ||
| label | No | ||
| domain | No | ||
| node_kind | No | Classification of this memory. One of: 'transient' (temporary, will expire), 'decision' (a specific decision made, default), 'standing' (a durable rule or principle), 'reference' (a person, system, or org — referential rather than propositional knowledge), 'issue' (an open question or problem), 'option' (a considered alternative), 'assumption' (an unverified premise), 'finding' (an observed fact or result), or 'goal' (a desired outcome). Absent defaults to 'decision'. Takes precedence over the transient bool field when both are supplied. | |
| transient | No | ||
| related_to | No | ||
| description | No | ||
| occurred_at | No | When this event actually happened (not when it is being filed). Format: YYYY-MM-DD or RFC3339. Two cases: (a) Events you directly witnessed during the current session (e.g. a decision made in the live conversation) — set occurred_at without asking; if the user did not specify a date, use today. (b) Inferred or back-dated historical events you did not directly observe — propose+confirm: state the date and your reasoning, ask the user to confirm, and only set occurred_at once confirmed. Never guess a historical date and never infer it silently from context. Turn-boundary rule: when proposing to file something as significant, the proposal must be the only action in that turn — do not include occurred_at in any remember or revise call in the same message as the proposal. Only set occurred_at in a subsequent call, after the user has replied. Always set why_matters when using occurred_at. | |
| why_matters | No |