A returning customer says, “Use my usual delivery arrangement.” Remembering the preference could save a conversation. Remembering a previous customer’s arrangement could create a privacy incident. Remembering an outdated instruction could send an order to the wrong place.

Long-term memory makes an AI assistant more useful only when the application can distinguish a preference, a current fact, an old fact, and an authorization decision. The first implementation task is to define what each category means for the business.

Start with the feature that exists

Microsoft introduced memory in Foundry Agent Service in public preview in November 2025. The announcement describes extracting and retrieving user information and conversation summaries across interactions. That offers a managed foundation for continuity, with preview terms that teams need to evaluate before adopting it.

Keep the scope of that announcement clear. This design uses the documented memory concept and application controls; it does not assume that every retention, correction, or identity requirement is automatically solved by enabling memory.

The broader Agent Framework architecture provides orchestration and session building blocks. A workflow checkpoint, a conversation history, and a remembered customer preference serve different purposes. Treating them as one unstructured store makes retention and testing unnecessarily difficult.

The research argues for explicit evaluation

LongMemEval, introduced in 2024, uses 500 curated questions to examine long-term conversational memory. Its abstract reports an approximately 30% accuracy drop across sustained interactions in evaluated commercial assistants and long-context models. The benchmark tests extraction, cross-session reasoning, time, updates, and abstention. These findings describe its tested systems and conditions, not Foundry performance.

The older Lost in the Middle study also found that access to a long context did not ensure reliable use of relevant information, particularly when its position changed. A larger input window is therefore an option to evaluate, not proof that a memory problem has disappeared.

For an enterprise architect, the implication is practical. Test what the assistant recalls, when the remembered fact was true, and when it should decline to answer. Storage success alone is a weak acceptance criterion.

Separate business records from conversational memory

Imagine a hypothetical distributor using a support agent for repeat customers. The order-management system owns shipping addresses and account permissions. The memory layer might retain a preference for concise status summaries or a usual delivery-time discussion. It should not become an alternative system of record for the customer’s authorized receiving address.

For a new order, retrieve the current address from the authoritative system and ask for confirmation when the workflow requires it. The remembered preference can make the conversation smoother without bypassing the transaction’s normal validation.

This distinction also helps with data quality. If a customer says an address changed, the assistant can propose the appropriate account-update process. It should not silently write a conflicting address into memory and later present that as verified operational data.

Bind scope to authenticated identity

Derive memory scope from the application’s authenticated tenant and user identifiers. Never allow a natural-language request such as “use the profile for user123” to select a different person’s memory.

Decide how shared accounts work before launching. An account-level purchasing preference may be visible to a team, while a person’s accessibility preference should remain personal. Those are different scopes with different access rules.

Test isolation at retrieval and update boundaries. A successful test proves both that another user’s facts stay hidden and that the current user cannot overwrite them indirectly. Include tenant changes, reassigned accounts, and recycled application identifiers in the test plan.

Preserve origin and time

A useful memory item needs enough provenance to explain why it exists. My recommended record includes its source interaction, time recorded, applicable scope, fact type, and any validity period. Avoid retaining sensitive raw conversation content merely because it is convenient.

Represent corrections explicitly. If a customer first prefers phone calls and later requests email, retrieval should prioritize the current preference while respecting the chosen retention policy. A vague summary containing both statements leaves the model to guess which one governs.

Some memories should expire because the business meaning expires. A travel preference for a particular week is not a lifelong customer attribute. Where the chosen preview interface lacks a required lifecycle control, implement that control in the application or postpone that memory category.

Let users correct the assistant

Provide a practical way to inspect or challenge remembered information. “That is no longer correct” should trigger a defined correction path. The agent should acknowledge the change without promising deletion across every system unless the application has completed that operation.

Deletion needs its own verification. Check that removed information no longer appears through direct lookup, semantic retrieval, derived summaries, or copied application caches within the scope you control. Document any separately retained audit record and its purpose.

A support team also needs a way to investigate a disputed memory without unrestricted access to private conversations. Use narrowly scoped diagnostics and log metadata rather than exposing all remembered content by default.

Build a memory-specific test set

Create multi-session cases with known facts, deliberate corrections, similar customers, and questions with no answer in the history. Include temporal questions such as which instruction applied before a change.

Compare memory enabled and disabled on the same task set. Score correct recall, stale-fact use, unsupported recall, cross-user exposure, and appropriate abstention separately. An overall average can hide a serious isolation defect behind better preference recall.

Keep the retrieved memory items with the evaluation evidence when permitted. That lets engineers distinguish extraction failure from retrieval failure and reasoning failure. Changing the model when the wrong memory was retrieved may make the symptoms harder to reproduce.

Decide whether continuity is worth its cost

Measure avoided clarification turns and successful task completion alongside retrieval latency, storage, model calls, correction effort, and privacy operations. Use the business task as the denominator rather than the number of memories stored.

A sensible pilot begins with low-risk preferences in one authenticated application. Expand the scope after demonstrating useful recall, reliable correction, and effective separation between users.

The strongest memory design is selective. It remembers information with a clear purpose, retrieves it within the right identity boundary, and knows when a fresh business record or another question is more reliable.

References

Microsoft: Memory in Foundry Agent Service, November 25, 2025

Microsoft: Agent Framework architecture, February 19, 2026

Wu and colleagues: LongMemEval, 2024

Liu and colleagues: Lost in the Middle, 2023

A service agent has diagnosed an incident and prepared a production change. The operations manager opens the approval request after lunch. By then, the deployment has changed, the original session has expired, and another engineer has already resolved part of the problem. What exactly does clicking Approve authorize?

That question belongs in the workflow design. A message asking for permission is only the visible part of approval. The application also needs a durable record of the proposed action, an authenticated decision, and a controlled path from that decision to execution. Otherwise a cautious user interface can sit on top of an unsafe transaction.

A durable pause is an architectural boundary

Microsoft’s February Foundry update describes a pattern combining Azure Durable Functions, Microsoft Agent Framework, and SignalR for workflows that wait for human input. The orchestrator can persist progress while an external approval event is pending. This is an application architecture pattern, rather than a claim that every Foundry agent automatically receives transaction-safe approvals.

The framework’s February release-candidate announcement documents checkpointing and human participation in graph-based workflows. By April, Microsoft had announced Agent Framework 1.0. Those building blocks help coordinate execution. The application still decides which person may approve a particular action and whether the action remains valid when work resumes.

For a production change, I would divide the flow into analysis, proposal, approval, validation, execution, and reconciliation. Each transition needs an explicit state. A conversational response such as “looks good” should become an approval only when the application can associate it with a specific proposal and authorized reviewer.

Measure the final state, not the conversation

The 2024 τ-bench paper evaluated tool-using agents through simulated user conversations, domain policies, and final database state. Its tested agents, including GPT-4o configurations, succeeded on fewer than 50% of tasks; retail reliability across eight trials, measured as pass^8, was below 25%. These are historical benchmark findings, not measurements of current Foundry models.

The useful lesson is methodological: an agent can sound cooperative and still leave the business system wrong. Approval testing should inspect the resulting record, including whether an unauthorized or duplicate change occurred. Testing only the wording of the approval question misses the outcome that matters.

What belongs in the approval record?

Consider a hypothetical service-management agent that proposes increasing capacity for one application. Its proposal should identify the environment, resource, current configuration, intended configuration, estimated financial effect, expiry time, and evidence used to recommend the change. This is an illustrative design, not a report of a client deployment.

Give the proposal an immutable identifier and a version. Store a canonical representation of its executable arguments. The approval decision references that version, rather than a mutable chat message. If the agent revises a target or parameter, require a new decision.

Capture the reviewer’s authenticated identity separately from model-generated text. A model may explain who should approve, but it must not establish that person’s authority. Authorization should be checked against the same identity and policy systems used by the application outside the AI workflow.

Make rejection and expiry ordinary terminal outcomes. Teams often implement the approval branch carefully and leave the other branches ambiguous. An expired request must not become an invitation for the agent to find a different route to execution.

Resume with fresh checks

A persisted workflow can resume correctly from its own perspective while the outside world has changed. Before applying the approved change, retrieve the current resource version and compare it with the proposal’s preconditions. Recheck permissions, policy constraints, and any material financial assumptions.

If those conditions differ, return a revised proposal for review. Do not silently reinterpret the previous approval as permission to achieve the same general goal by different means. The business owner approved one intervention under a particular set of facts.

Separate this validation from the language-model step. Deterministic application code should reject a mismatched resource version or expired approval. An explanatory prompt can help users understand the rejection; it should not be the enforcement mechanism.

Design the uncertain-outcome path

A tool call can time out after the downstream service has accepted a change. Blindly retrying risks a duplicate action. Assign an operation identifier before the write and use downstream idempotency support where available.

Where the target system lacks that support, implement a reconciliation query that checks the business record and operation evidence. Mark uncertain outcomes explicitly. A workflow waiting for reconciliation is more honest and easier to operate than an agent announcing success based on a missing response.

Keep the execution worker separate from proposal generation. Give it only the approved operation and necessary credentials. This limits the chance that unrelated conversation content influences a privileged write during recovery.

Test approval as a complete process

Build cases for approval after a restart, duplicate approval events, rejection followed by a late approval, revoked reviewer access, changed resource state, and timeout after a successful write. Include a hostile instruction inside retrieved incident data that asks the agent to bypass review.

For each case, specify both the expected workflow state and permitted downstream changes. Repeat tests because a single successful conversation does not establish consistent behavior. Preserve the failed cases as regression fixtures after correcting the implementation.

The platform team should own orchestration reliability. The application team should own transaction correctness and reconciliation. The business owner should define approval authority, expiry, and acceptable impact. Put those responsibilities in the runbook so an interrupted workflow has an accountable operator.

Report useful business measures

Track elapsed time from proposal to verified completion, reviewer correction rate, expired approvals, duplicate actions prevented, and unresolved outcomes. Separate time spent waiting for a person from time lost to technical recovery.

For an initial rollout, use a narrow action with a clear reversal procedure and observable final state. Compare the full process with the existing manual workflow, including review and recovery effort. An agent that drafts changes quickly but creates reconciliation work may increase the team’s workload.

The release decision should rest on whether the approved action is executed once, within its intended scope, under valid conditions. Durable orchestration makes the wait manageable. A precise approval contract makes the resulting action trustworthy.

References

Microsoft: February 2026 Foundry update

Microsoft: Agent Framework release candidate, February 19, 2026

Microsoft: Agent Framework 1.0 and the developer journey, April 22, 2026

Yao and colleagues: τ-bench, 2024