Memory architecture: what should an agent remember?

Memory has different lifetimes

Session context helps an agent follow the current interaction. Long-term memory retains selected information across sessions. Neither should be confused with training the underlying model. A business application also has operational state, such as whether an approval is pending. That state needs reliable storage and explicit rules, even when a conversational summary exists.

What Microsoft currently provides

Microsoft documents managed long-term memory in Foundry Agent Service as a preview. Its memory stores support retention and individual item management. The documentation distinguishes knowledge curated by an organisation from information learned through interactions. Availability and preview conditions should be checked for the target deployment before a team depends on the feature.

Remember preferences, recheck facts

A fictional purchasing assistant might remember that a user prefers concise summaries. It should still retrieve the live purchase-order status for each operational decision. A remembered delivery date can become wrong after the next supplier update. Treat memory as context with an owner, source and lifetime; do not quietly promote a past conversation into the system of record.

Design forgetting before remembering

Decide which information is useful enough to retain, who can access it and how users correct or remove it. Avoid persisting credentials, unnecessary personal details or unsupported claims. Test isolation between users and organisations, stale memories and malicious instructions embedded in conversations. In a workshop, begin by asking what continuity the workflow actually needs; a stateless assistant may be sufficient.

Microsoft sources and further reading

• Microsoft Learn: Foundry Agent Service memory — preview