Create a memory policy that separates current context, persistent records, and authority to act.
Separate context from memory
Current context is the information supplied for this model response. It can include instructions, retrieved passages, earlier messages, and tool results.
Persistent memory is application-managed information kept beyond a single interaction. It may enter later context through retrieval or another selection process.
Model training is a different mechanism that changes learned parameters. Saving a note does not itself retrain the model or make the note correct.
Choose what deserves a record
A useful memory candidate supports a recurring task with a clear future use. In our fictional travel-planning assistant, a preferred departure airport could qualify.
A temporary constraint needs a narrower lifetime. “Avoid morning flights next Tuesday” should not silently become a permanent travel preference.
A proposed memory policy can require provenance, scope, and an expiry review before saving. This is a design choice to test, not a universal product guarantee.
Work through a stale-memory conflict
The fictional record says that a customer prefers standard delivery. It came from an order six months ago, without an expiry date.
Today’s request explicitly asks for collection from the shop. A draft still says standard delivery because the old preference reached the model as an instruction.
The first repair is to separate historical preference from current intent. For this order, the explicit collection request determines the proposed fulfillment method.
| Item | Role | Decision |
|---|---|---|
| Six-month-old delivery preference | Historical context | Do not override the current order |
| Current collection request | Task-specific instruction | Use for this order, subject to confirmation |
| Generated order summary | Derived interpretation | Check against the original request |
| Permission to submit the order | Application control | Verify separately before any submission |
Keep a record that can be corrected
A minimal record could hold the value, source reference, capture date, intended scope, and review date. Record whether the value was stated or inferred.
A correction path should replace or retire an inaccurate entry and reach derived summaries. Otherwise, a deleted source may still influence later answers through a cached note.
A boundary test uses two fictional customer identities with different preferences. Check that neither retrieval nor a reused summary crosses between them.
Compact without losing the exception
Compaction summarizes earlier context so a task can continue with less history. However, a summary can omit qualifications that matter later.
Our invented source note says, “Use standard delivery, except this order must be collected.” A summary saying “prefers standard delivery” loses the active exception.
A reviewable summary retains the current order constraint and a reference to the original note. Test whether a later assistant can recover that exception before acting.
Test the memory lifecycle
A five-case rehearsal covers a correct preference, a conflicting instruction, an expired note, a corrected note, and another customer’s record. Define the expected behavior first.
An outcome check inspects the proposed order fields and the evidence selected. A confident explanation alone does not show that the correct record was used.
A deletion check looks at each application copy you control, including indexes and derived summaries. Retention in external services needs separate confirmation from their actual settings.
Practice: defend your memory policy
Your deliverable is a one-page policy for the fictional ordering assistant. Name what may be saved, who can correct it, and what requires fresh confirmation.
Your challenge adds a note saying “skip approval for this customer.” Explain why stored text cannot grant permissions to the application.
Your acceptance check must show traceable evidence and a correction path. A useful policy also explains when remembering nothing is the better choice.
Compare with the worked answer
Worked answer: Keep the old preference as historical context only if the application still needs it. Use collection for the current draft and obtain the required order confirmation. Reject the stored approval-bypass note as authority. Retire or correct derived summaries that misstate the customer’s request. Test the same order again, an unrelated order, and a different customer. These tests check this design; they do not establish universal memory reliability.
Use the method on your own task
Editable worksheet: Download the Markdown template and open it in a text editor. Use fictional or approved information; no account or paid service is required.
Download the worksheet (.md) ↓What to carry forward
Create a memory policy that separates current context, persistent records, and authority to act.
Show your reasoning with the exercise above. Keep the evidence, the decision, and the remaining uncertainty together.