A customer asks for Friday. The assistant writes a draft mentioning Friday. Later, a summary says, “Friday appointment arranged.” The next assistant treats the summary as a confirmed booking.
Nobody opened the calendar. A request became a promise as the information moved through the system.
Useful memory preserves what is known, where it came from, who may access it, and what still needs a decision. Your work product is a context map and a small memory record with explicit status and source references.
The practice pack contains fictional Mesa and Cedar records. No real customer, employee, or appointment information is included, and no memory update changes an operational system.
Separate four kinds of context
“Memory” can refer to several different things. Keep them distinct when designing a workflow.
| Kind | Purpose | Example |
|---|---|---|
| Current working context | Information needed for the present step | The request, allowed task, and selected policy |
| Reference knowledge | Maintained documents used across tasks | Current inspection policy and booking procedure |
| Business state | Authoritative status of a real-world process | Whether an appointment is recorded as confirmed |
| Notes and proposals | Summaries, hypotheses, and suggested next actions | A draft reminder to check Friday availability |
A model-generated note is not automatically a business record. An approved policy is not a live inventory count. A conversation that mentions a payment is not proof the payment settled.
Give each kind an owner and an update path. The workflow may read the current policy, but only the appropriate document process should replace it. The calendar owns actual booking status. The model can propose a question or next step without being allowed to alter either source.
Bring in the information needed for the next step
More text does not automatically make a better answer. A large collection may contain old versions, irrelevant cases, conflicting instructions, or private details the task does not need.
Anthropic's context engineering discussion describes selecting useful context, summarizing longer work, and keeping structured notes outside the immediate context window. It also discusses the risk of losing important details during compaction. Those techniques help manage working information; they do not establish that a note is true or authorized.
For Mesa's fee question, bring in the current fee policy and relevant booking boundary. You do not need payroll files, every prior complaint, or another business's records to explain the inspection fee.
Keep source references with the extracted facts. If a reviewer cannot find the document supporting a claim, a compact answer may have discarded the information most needed to check it.
Filter access before exposing content
A search result should not reveal private content and then ask the model not to repeat it. Apply the appropriate entity and permission rules before the content is provided to the model or user.
OWASP's authorization guidance recommends least privilege, denying access by default, and validating permissions on each request. Apply those ideas to document retrieval, stored notes, exports, and result lookups, not just to the final write action.
The practice retrieval method selects documents by business identity, allowed role, and current approved status. A Mesa service actor receives SERVICE-01. It does not receive the superseded SERVICE-00, a synthetic personnel document, or Cedar's separate record.
The private fixtures contain harmless marker strings so the test can detect accidental inclusion without using actual secrets. This verifies the supplied filter logic. It does not test the access controls of a search platform, vector database, or cloud document service.
Keep permission and relevance as separate questions
A document can be accessible but irrelevant. It can be relevant but inaccessible. It can also be relevant and accessible but out of date.
Start with the permitted collection, then find the information that addresses the question, and check its status. Do not let a relevance score override access rules or a document's authority.
A real retrieval evaluation should include answerable questions, missing-answer questions, conflicting sources, older versions, and records the caller must not see. Inspect both which documents are returned and whether the final answer uses them accurately.
The local demonstration uses exact source IDs and simple filtering. It does not implement semantic search or rank documents by similarity. Its purpose is to make the access and status boundary visible before a more complex retrieval system is introduced.
Preserve uncertainty in the memory record
The fixture MEM-901 records that the customer requested Friday and that no booking confirmation is supplied. Its appointment_confirmation value is null.
That is different from false in some business models: null here means the packet does not supply a confirmation record. Do not invent a rejected appointment either. Use the status vocabulary of the actual source system when implementing a real workflow.
The packet also contains MEM-DRAFT, an unsupported model proposal claiming Friday is confirmed. Its status is model_proposal, and it lacks a supporting source. The normal recall method excludes it.
The correct remembered fact is the customer's request, not the assistant's optimistic restatement. When later evidence arrives, update the authoritative record through the appropriate process and preserve the reason for the change.
Decide what deserves to persist
Keep information because it serves a defined future task, not merely because the model can summarize it.
A useful operational note might preserve the case ID, requested next step, unresolved evidence, responsible role, and review date. Avoid storing unnecessary personal details or speculative judgments about customers and employees.
For preferences, distinguish an explicit statement from a one-time request and from an inference. “Customer asked for email for this case” does not establish permanent consent for every future marketing message. A preference record should include its scope, source, and any review or expiry rule appropriate to the use.
Do not store credentials in general agent notes. Use the application's proper secret mechanism, and keep references to credentials separate from their values. A memory search should not become an accidental way to reveal an account key.
Review memory writes as changes to information
A proposed memory update should show the old value, proposed value, source, purpose, scope, and required reviewer. The application should enforce who may make the change and what fields may change.
For example, a model may propose: “Add an unresolved task to check availability for AUTO-901.” That is a different operation from changing appointment status to confirmed. Design separate fields or actions so the distinction survives implementation.
The demonstration has no memory-write interface. Its reviewed and proposed records are supplied fixtures, and tests verify which ones can be recalled. Adding persistence, editing, approval, and retention would be additional work requiring its own checks.
This boundary is intentional. It is easier to understand a memory system when the source of each remembered fact remains visible and the model cannot silently promote a guess into operational truth.
Keep summaries from erasing important conditions
A summary should preserve the details that control the next decision. For Mesa, that includes the current fee, the credit condition, unknown availability, and any unapproved exception.
A short but misleading summary might say, “Customer can use the inspection payment toward repairs and come Friday.” A useful one preserves that the credit applies to a repair approved within thirty days and that Friday still needs checking.
Ask the summarizer to separate source-supported facts, requests, proposals, decisions, and completed actions. Have it identify missing evidence explicitly. Check a sample of summaries against the underlying records, especially after changing the prompt or model.
A shorter record can be easier to use without being sufficient for every decision. Preserve a route to the original evidence so the next reviewer can recover omitted context when necessary.
Handle corrections, expiry, and deletion
When a source changes, decide which derived notes or cached answers depend on it. A corrected policy should not leave an old answer circulating indefinitely because it was copied into a different memory store.
Maintain source IDs and versions so affected records can be found. Mark a note superseded or invalid when appropriate, and make the retrieval path respect that state. Do not leave conflicting versions equally authoritative.
Define retention and deletion for the actual business purpose and applicable requirements. Include working notes, source copies, search indexes, exports, and backups in the design. Deleting one visible record is not proof that every derived copy has disappeared.
A record needed for an audit or dispute may have different handling from a temporary drafting note. Resolve the policy with the appropriate owner rather than asking the model to choose a universal retention period.
Test the boundaries with contrasting cases
The supplied checks verify that a Mesa actor can recall MEM-901 with its unknown confirmation, cannot recall the unsupported proposal as reviewed memory, and cannot retrieve Cedar's separate record. A Cedar actor also cannot retrieve Mesa's note.
Those cases test a narrow but important relationship: permission and status determine what the recall interface exposes. They do not prove the fixture's facts through external evidence; the facts are constructed inputs.
For a production system, extend the evaluation to permission changes, stale caches, deleted sources, conflicting records, and summaries that omit critical conditions. Test each actual store or integration involved. Avoid testing only the friendly question from the product demonstration.
Give the model a clear memory task
Prepare a proposed case note from the supplied records.
Separate source-supported facts, customer requests, unresolved questions,
proposed next steps, approved decisions, and completed actions.
Keep source IDs and versions. Preserve unknown values. Do not infer
appointment confirmation, consent, payment, approval, or personal traits.
Return the proposal for review; do not modify the authoritative records.
A reliable memory record helps the next person or process continue without guessing. It preserves useful context and the limits of that context together.
Next: Monitor the workflow, evaluate changes, and recover from failures in Chapter 36.