When Should an Agent Save a Memory? Design the Write Policy

An agent should save information because a defined future task needs it, not simply because a message was generated. A write policy determines which events become durable context, which remain temporary, and which need confirmation before reuse.

Retrieval quality starts at capture. If the store mixes confirmed decisions, speculative answers, and copied instructions without provenance, ranking alone cannot restore the missing distinctions.

Choose the source event

Useful triggers include an explicit user preference, a confirmed decision, an accepted source revision, or a completed workflow outcome. A model's proposed next step is not the same as a completed action.

Preserve the event's identity and source. If the workflow retries, the repeated event should remain recognizable. A new random memory ID on every attempt can turn transient delivery failures into persistent duplicate facts.

Separate capture from promotion

An incident trace can be worth preserving without becoming a general procedure. A repeated pattern can suggest a preference without establishing that the user wants it applied everywhere. Keep observed, inferred, and confirmed records distinguishable.

The memory-types guide explains why an event, a fact, and a procedure carry different authority. Define any promotion step explicitly rather than relying on repetition to imply approval.

Choose the timing of the write

If the next action depends on the new fact, the application may need to wait for the relevant readiness boundary. Bulk extraction can run asynchronously when the product tolerates a delay. Tell the answer path what remains pending.

A successful request to a provider proves only the operation's documented acceptance semantics. Verify when the selected record becomes available to the retrieval path your application uses.

Evaluate both over-capture and missed capture

Use cases where a preference should persist, a task exception should expire, a speculative answer should not become evidence, and a correction should replace current behavior. Inspect stored records as well as later answers.

A system that captures everything may appear to have high recall while burdening users with irrelevant or incorrect personalization. Include a task where no stored context is needed.

For a managed implementation, start with Supermemory and a small explicit write policy. Pair it with the lifecycle guide so the first release covers correction and removal, not only capture.