Consolidate memory with explicit lifecycle controls

Learning objective

Implement memory consolidation, TTL, retention, auditability, and deletion.

Core idea

For an architect operating long-term agent memory, the goal is a lifecycle you can explain and enforce: what became memory, how it changed, when it expires, and how you remove it. Consolidation improves the usefulness of stored knowledge; it does not establish that the knowledge is correct or that its retention satisfies policy.

Microsoft Foundry Memory and the Memory Store API are preview features. The service extracts and consolidates conversation information, while item-level operations let you inspect, correct, and delete individual records. Store defaults provide time to live (TTL), but an update can change the expiration basis. Treat extraction, retention, and erasure as separate decisions.

See 2.2.5 for the choice of memory strategy and 2.2.6 for authorization and consistency. This lesson focuses on operating the selected memory through its lifecycle.

How it works

Consolidate with observable results

Foundry Memory uses a chat model and an embedding model configured on the memory store. Its documented consolidation can merge similar or duplicate topics and resolve conflicting information. The concept page cautions that consolidation behavior varies by memory type and can change during preview. Do not treat the output as a deterministic merge of business records.

Use MemoryStoreDefaultOptions to choose extraction behavior, including chat_summary_enabled and user_profile_enabled. The user_profile_details parameter describes relevant information to retain and sensitive or irrelevant information to avoid. These instructions focus extraction; they do not replace validation of a consequential fact. A remembered delivery preference can personalize an answer, while an asserted entitlement still needs its authoritative record.

For explicit conversation ingestion, the Python operation is project_client.beta.memory_stores.begin_update_memories(name=..., scope=..., items=..., update_delay=...). Setting update_delay=0 triggers processing without the inactivity wait. It does not turn the operation into a synchronous write: the documented example waits with update_poller.result().

The result exposes memory_operations, including each operation’s kind and memory_item.memory_id. Preserve these identifiers in your operational record so you can connect an input batch to the records it affected. To extend an earlier update with more turns, pass previous_update_id=update_poller.update_id; do not confuse that operation identifier with an individual memory identifier.

Set expiration at the correct scope

The store option default_ttl_seconds sets the default lifetime for memory entries. The documented Python example uses timedelta(days=30); the REST example expresses the same interval as 2592000 seconds. A value of 0 means no expiration.

TTL covers memories created by direct commands, extraction and consolidation, and item-level CRUD operations. When memory is updated and consolidated, the service resets its last-updated time. A frequently refreshed preference can therefore remain available beyond one original retention interval. If your policy requires an absolute date measured from initial collection, retain that policy date separately and execute deletion at that date rather than relying only on sliding expiration.

Each update and consolidation resets the sliding lifetime, while a separately retained policy date keeps the absolute deadline fixed.

TTL applies only to stores created after TTL support was introduced. Defaults can be creation-time settings, so verify post-create update support for your API version; see 2.2.6 for these scope constraints.

Retention also includes copies outside the memory store. A transcript, application cache, exported update result, or audit record can carry the same personal information. Define each copy’s purpose and lifetime. Foundry’s memory TTL is the mechanism for memory entries, not proof that your whole application has erased every copy.

Inspect and correct individual records

The Python item operations include create_memory, get_memory, list_memories, update_memory, and delete_memory under project_client.beta.memory_stores. For example, update_memory accepts the store name, memory_id, and corrected content. Inspect the record you intend to change rather than regenerating an entire memory store to repair one preference.

A correction should preserve its operational provenance: who requested it, which memory identifier was changed, and whether the service confirmed the operation. That record is application-owned. Microsoft recommends a tamper-evident deletion audit trail, but the cited memory pages do not define a built-in immutable lifecycle ledger. Avoid collecting raw sensitive content merely to prove that a correction happened.

Delete at the requested granularity

Choose the operation that matches the request. delete_memory(name=..., memory_id=...) removes one item. delete_scope(name=..., scope=...) removes the memories associated with one user or group while retaining the store structure. delete(memory_store_name) irreversibly removes the entire store across scopes and can disrupt dependent agents.

Coordinate deletion with your ingestion owner. Stop pending application writes and prevent a retained transcript from being ingested again after erasure. Record the deletion outcome, invalidate application copies, and verify the appropriate remaining records through item inspection. These are application controls around the documented delete operations; a delete call alone does not coordinate all your writers.

Key distinctions and trade-offs

Consolidation versus correction: Consolidation reduces redundant extracted knowledge. An item-level correction explicitly changes a known record. Model-based consolidation is not an approval process for disputed facts.

TTL versus retention policy: TTL is a service expiration mechanism. Retention policy specifies the permissible lifetime and handling of all relevant copies. A sliding lifetime can conflict with an absolute retention deadline.

Item, scope, and store deletion: These operations have different affected populations. A scope reset preserves the store for other users; deleting the store removes their memory too.

Automatic extraction reduces manual maintenance, but makes validation and operation evidence more important. Item-level control improves explainability at the cost of application ownership for corrections, audit records, and coordination with ingestion.

Architecture / decision scenario

A travel assistant stores preferences in a preview memory store configured with a 30-day default TTL. The extraction policy in user_profile_details favors dietary and airline preferences and excludes credentials. After each accepted conversation batch, the ingestion worker calls begin_update_memories, waits for its result, and records operation identifiers and affected memory IDs without duplicating the full conversation.

A traveler corrects a meal preference. The application inspects the relevant item and uses update_memory to change its content. It treats the refreshed last-updated time as an expiration change, not evidence that the original collection date changed. A separate absolute retention deadline remains in the application’s policy record.

When the traveler requests erasure, the application blocks further ingestion for that request, calls delete_scope, clears its cached preferences, and records the outcome in its tamper-evident audit trail. It does not delete the store used by other travelers. Scheduled expiration handles ordinary aging; explicit deletion handles the user’s request and any absolute policy deadline.

Common exam traps

• Assuming consolidation produces an authoritative or lossless business record.
• Treating update_delay=0 as proof that an asynchronous update has completed.
• Interpreting default_ttl_seconds=0 as immediate expiration.
• Applying TTL expectations to a store outside the documented support scope.
• Treating a refreshed memory’s lifetime as an absolute collection-based deadline.
• Deleting a whole store when the requested operation concerns one scope.
• Keeping unrestricted raw memory content in an audit trail indefinitely.

What to remember

Observe consolidation through update results, set supported store TTL defaults, and inspect or correct records by memory ID. Separate sliding expiration from absolute retention requirements. Delete at item, scope, or store granularity, and coordinate application writers and copies so erased information is not recreated.

Knowledge check

References

• Microsoft, What is Memory?
• Microsoft, Create and use memory in Foundry Agent Service