Microsoft's October 26, 2026 Foundry architecture guidance separates remembering, retrieving, revalidating, and forgetting into operations with explicit policy owners and executing components. The article distinguishes useful remembered context from authoritative business information. This is new implementation guidance, not a general availability announcement. Microsoft architecture article.
My proposed adoption test starts after the impressive first conversation. Change something important, open another session, and check whether the application still makes the right decision.
The earlier agent-memory overview on this blog introduced continuity and governance. This follow-up focuses on repeatable acceptance tests against the new implementation guidance.
Keep Product Status in the Release Record
Microsoft Learn currently labels Foundry Agent Service memory and the Memory Store API as preview. The documentation describes item-level operations and retention controls, while noting limitations such as explicit scope for low-level API requests and no VNet integration for memory stores. Verify these constraints against the intended environment. Memory overview.
I would record the chosen API version, store configuration, and tested application build together. A review should be able to identify exactly which combination produced the observed behavior.
Keep preview evaluation approval separate from a decision to depend on the capability in a customer-facing workflow. The latter needs the application's normal release evidence and an owner for the resulting dependency.
Build a Test Around a Changed Service Ticket
For an original pilot scenario, create a synthetic service ticket and let the assistant discuss its status. Then change the ticket in the designated business system before the next conversation.
Ask the same status question and inspect both the answer and the evidence behind it. Define the expected result with the ticket owner before running the test.
Next, make the business system unavailable in the test environment. Evaluate the application's agreed fallback rather than accepting any fluent answer as success.
Record whether the response clearly communicates what could be verified. The useful evidence is the behavior under changed conditions, including a refusal or an incomplete answer when that is the approved outcome.
Make the Write Decision Observable
The new architecture article assigns durable-memory eligibility to an application policy layer and calls for authorization before retrieval ranking. It also separates revalidation from deletion and tracks derivative copies when forgetting information. Implementation responsibilities.
I would add a pilot review screen showing a small set of synthetic candidate memories and the application's decision for each. Include an explicit user preference, a speculative assistant statement, and text copied from an untrusted test document.
Have the product owner specify the expected treatment before executing the cases. Compare the recorded decision with that expectation so a prompt that sounds cautious cannot substitute for observable enforcement.
Use test identifiers in the evidence. The review should demonstrate the decision without collecting production conversation content merely to make a dashboard look complete.
Test Changes to Identity and Ownership
My isolation exercise would use two synthetic users with deliberately similar requests. Give each a distinct, harmless preference and then ask questions likely to retrieve it.
Include a changed team membership and a delegated workflow in the test matrix. For each case, state the allowed result and inspect the actual retrieval path, not only the final wording.
After a failed case, preserve enough configuration information to reproduce it. Re-run the same case after the fix and retain both outcomes in the release evidence.
Give Deletion a Measurable Exit Condition
I would define deletion acceptance with the application and data owners before enabling durable memory. List the stores and derived artifacts the application actually creates, then specify what must happen to each test record.
Run a deletion request using one synthetic identifier and check the agreed destinations. Repeat the request to evaluate retry behavior, and deliberately fail one downstream step to see whether incomplete work remains visible to operators.
Only claim the result that was verified. A successful API response is useful evidence, but the release record should explain which application-level outcomes were also checked.
Practical Cloud Engineer Takeaway
Record preview status and the exact tested configuration.
Test a changed business fact across sessions.
Review observable memory-write decisions.
Exercise identity changes with synthetic users.
Verify deletion outcomes and incomplete-work handling.
Who Should Care?
Foundry developers, AI platform engineers, and application owners evaluating durable agent memory.
Bottom Line
Continuity is valuable when the application can still handle change correctly. A convincing memory pilot should demonstrate what happens after information, access, or user intent changes.
No memory store was created, customer conversation uploaded, agent deployed, or Azure evaluation executed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments