MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

An assistant that remembers a preferred meeting format can save a user time. An assistant that remembers an obsolete customer instruction can cause a mistake. Memory is useful when a retained fact has a clear purpose, reliable provenance and an appropriate lifetime. Keeping everything indefinitely is not a design strategy.

The word memory covers several different mechanisms. A conversation history, a saved preference, a task checkpoint and an authoritative customer record all preserve information, but they should not be governed in the same way. Start by naming what is being stored and why the system will use it later.

Four different things people call memory

Working context is the information available during the current model interaction. It can include instructions, messages and tool results. Anthropic’s context-engineering article treats the selection and maintenance of that information as an engineering problem. More retained text is not automatically more useful context.

Conversation history preserves previous exchanges so the application can continue a discussion. The OpenAI Agents SDK sessions documentation describes mechanisms for managing that history. The existence of a session does not establish that every fact in it remains current, nor that it should be reused for unrelated tasks.

Durable preferences are selected facts intended to improve later interactions, such as a user’s preferred briefing structure. They need a way to be reviewed and corrected. A preference should not silently become permission to perform an external action.

Task state records what has happened in a particular job: completed steps, pending approvals, artifact locations and unresolved questions. It should describe observable progress. “The user seemed happy” is not a substitute for a recorded approval or a verified completed action.

Use a purpose test before storing a fact

Consider a hypothetical account manager who asks an assistant to prepare a weekly client briefing. The assistant could remember the preferred section order. It might also retain a temporary instruction to exclude a confidential negotiation from this week’s draft. Those two facts have different lifetimes and consequences.

Before saving either, ask what later task requires it, where the fact came from and what would make it invalid. The section order may remain useful until changed. The temporary exclusion may expire after the specified briefing. A commercial restriction may belong in a controlled business system rather than a loosely managed preference store.

Avoid turning an inference into a durable fact. If a user asks for a short answer once, that does not prove they always prefer brief responses. If an employee mentions a customer in a discussion, that does not establish ownership of the account. Store explicit, useful information rather than a growing profile of guesses.

Attach provenance and time

A saved fact should have enough context to be challenged later. Record its source, when it was captured and any applicable scope. For a preference, the source may be an explicit user instruction. For task state, it may be a tool result or approval event. For a business fact, the authoritative system should remain identifiable.

When two memories conflict, the system needs a rule for resolution. A new explicit preference may supersede an old one. A fresh database result should not be overridden by an earlier conversational summary. If there is no trustworthy basis for choosing, ask or report the conflict rather than blending the facts into a plausible compromise.

Time matters even when nothing appears to conflict. A customer’s contact person, an employee’s role or a delivery address may change. Decide which facts must be refreshed at the moment of use. The cost of a lookup can be smaller than the cost of acting on stale remembered information.

Make correction a normal product feature

Users should be able to inspect and correct selected durable information without reverse-engineering a conversation. A simple preference view can show what the system will reuse and allow a user to remove it. Keep the language concrete: “Use this outline for weekly briefings” is clearer than a vague personality label.

Correction should reach the places that matter. Removing a saved preference while leaving the same instruction in an automatically retrieved summary can produce confusing behavior. Map the storage layers, including session history, structured memory, retrieval indexes and caches. Explain the product’s actual deletion behavior rather than promising that one click erases every copy everywhere.

Keep users and tasks separated

Memory can create cross-context leaks if unrelated users or projects share a storage key or retrieval scope. Use explicit identity and task boundaries. Test a second user with similar questions and verify that private preferences, documents and task notes do not appear.

The SDK sessions guide includes operational considerations for session identifiers and persistence. Treat those as implementation details requiring deliberate configuration, not proof that any application using the SDK has safe isolation. The surrounding system must connect each session to the correct authenticated user and allowed scope.

• Can a user see which durable facts will influence future work?
• Can they correct a fact without creating another contradictory memory?
• Does the system distinguish a temporary instruction from an enduring preference?
• Are approvals stored as explicit scoped events rather than inferred sentiment?
• Are business facts refreshed from their authoritative source when needed?
• Can one user’s conversation or task state affect another user’s answer?

Remember enough to resume, not enough to pretend

Long-running work benefits from concise records of verified progress. Anthropic’s long-running harness case study describes progress artifacts in coding tasks. The broader business lesson is an inference: a resuming assistant should receive evidence of completed work, not just a narrative that sounds complete.

Memory should reduce repeated effort while preserving the ability to question what was retained. Give each memory type a purpose, a source, a scope and a lifecycle. That makes continuity useful without allowing yesterday’s assumption to become tomorrow’s unexamined authority.

Sources and further reading

Anthropic: Effective context engineering for AI agents. Context selection and maintenance concepts; published September 2025.

OpenAI Agents SDK: Sessions. Conversation-history management and persistence documentation; checked October 2026.

Anthropic: Effective harnesses for long-running agents. Coding case study using progress artifacts; published November 2025. Business application is editorial inference.