Design an Agent Memory Schema That Can Be Corrected
An agent memory schema should describe what was learned, who it applies to, where it came from, and whether it is still valid. A text field and a user ID can support a prototype, but they leave correction, conflict resolution, and audit behavior undefined. Design those fields before memory becomes a dependency for important answers.
Separate the observation from the claim
A source observation might be a message saying, “Use the new billing address from Monday.” The memory claim is the structured interpretation: a billing address, its subject, and its effective date. Preserve a reference to the observation so a reviewer can check whether the interpretation was justified.
Useful application-level fields include a stable memory ID, subject scope, claim type, value, source reference, observed time, effective time, and status. These are design suggestions, not a claim that every memory provider uses the same internal schema.
Model correction without erasing meaning
Suppose an address was extracted incorrectly. A correction should mark that claim as superseded and connect it to the replacement, while respecting the product's retention rules. If the user withdraws the information entirely, deletion may require removing both source and derived representations.
Do not treat every later statement as a permanent update. “Send this one shipment to the office” can be a task-specific exception. Keep scope and duration explicit so a single instruction does not overwrite the default address for every future interaction.
Make unsupported states difficult to create
Require a source or a clearly marked user-authored entry. Distinguish confirmed, inferred, disputed, and superseded claims where the product needs those states. Keep authorization outside model-generated fields: the model should not assign itself access by producing a tenant ID.
Version the schema and validate incoming records. If a field changes meaning, migrate old entries deliberately. A renamed field that keeps old values can silently change retrieval filters and memory eligibility.
Test the schema with awkward examples
Try a renamed organization, two people with the same name, a temporary preference, contradictory sources, and a removed permission. Check whether the representation supports the intended answer without special cases scattered throughout the application.
Exercise the schema through the save, retrieve, correct, and remove contract tests before it becomes a product dependency.
When records are connected, define their relationship semantics. Keep those storage decisions separate from which memories enter the next prompt.
Read the write-policy guide to decide what should become a record. To test a managed implementation, start with Supermemory and verify the metadata, source references, correction behavior, and deletion paths your schema requires.