That is the argument behind Dr. Usman Zia’s opinion piece in Digital Pakistan—and it raises a practical procurement question for Microsoft-focused IT teams: can you change the model without losing control of what the agent remembers? Microsoft’s Copilot Studio documentation makes that question particularly relevant, while also revealing an important complication: different agent configurations have different memory boundaries.
The concern deserves attention, but not panic. Persistent memory, document retrieval and an authoritative business record are not interchangeable. Before declaring memory the next great source of vendor lock-in, administrators need to establish which of those things they are actually buying.
The context layer is becoming a product
Digital Pakistan identifies several developments across 2026: Couchbase’s reported October 20 availability of managed Agent Memory on AWS, Microsoft’s October 21 memory documentation update, and Box’s November 5 announcement of a new enterprise context layer. It also points to Redis Iris, Notion’s shared-memory work and Anthropic’s memory-import capability.
Those developments support a broader architectural discussion, but they do not all describe the same technology.
Redis’s May 18, 2026 announcement, for example, positioned Iris as a context engine containing several components. Its Agent Memory component preserves context across tasks and agents, while other components handle retrieval, integration, caching and search. Even within one product family, “context” is a collection of functions rather than a single notebook.
Box’s announcement makes another distinction clear. Box Context Retrieval is primarily a retrieval layer over enterprise content, using NVIDIA Nemotron Retriever models to find relevant information within users’ existing permissions. That is different from an agent retaining a preference learned during an earlier conversation. Box says the engine is planned for general availability to Enterprise Advanced customers in early 2027.
Box reports potential token reductions of 90%; Digital Pakistan separately attributes a 33–45% reduction to Couchbase. These should not become a procurement league table. The Box figure is a vendor claim about its retrieval approach, and the reporting does not establish a common workload or methodology for comparing the two.
The useful takeaway is narrower: investigate where context resides, how it is selected and what dependencies it creates—not just the headline percentage.
Copilot Studio memory needs configuration-specific scrutiny
Microsoft’s documentation updated on October 21, 2026 describes a production-ready preview for agents using the GitHub Copilot harness. It explicitly distinguishes this from the Customer Conversation harness’s separate memory capability. The 28-day rule should therefore not be applied indiscriminately to every Copilot Studio deployment.
For that GitHub Copilot harness feature, Microsoft documents:
- Separate, private memory for each user in Microsoft-managed storage.
- Deletion after that user stops interacting with the agent for 28 days.
- No user memory in group chats or Teams channels.
- A crucial distinction: switching Memory off stops its use but does not delete it.
For makers working with this specific feature, the documented control is straightforward: open the agent, select Build, then use the Memory toggle in the components panel. Users can request individual corrections or forgetting in chat, and review or delete all memories through the memory portal. Disabling the toggle is not a substitute for a deletion request.
That last point is an immediate administrative contribution beyond the portability debate: “disabled” and “erased” are different states.
Agent accounts have a different privacy boundary
Microsoft’s Frontier preview FAQ describes another configuration: agents with their own Microsoft Entra account. These use shared memory across the people interacting with them, including in one-to-one conversations. Anyone interacting with the agent can view or delete its saved shared memories.
More importantly, Microsoft warns that remembered summaries of files or chats can surface in responses to people who lack permission to access the originals, regardless of sensitivity labels. The FAQ says there is no privacy boundary between users for this shared memory.
In that preview, users cannot opt out, and administrators cannot disable shared memory independently of agent accounts. Shared memories are deleted after 28 days without anyone interacting with the agent. Microsoft lists exclusions for credentials and several sensitive information categories, but those exclusions do not negate its explicit sharing warning.
Administrative implication: record the harness and agent-account configuration before approving a deployment. A generic inventory entry saying “Copilot memory enabled” is not enough.
Portability exists—but completeness is another question
Anthropic provides a useful example of both progress and limitations.
Its documented import process asks users to obtain remembered context from another service, copy the resulting text and paste it into Claude’s import flow. Contrary to the simplest description of this as merely requesting a summary, Anthropic’s suggested prompt asks for individual entries without summarising or omitting them. Claude then extracts information into memory.
That is still not proof of a lossless migration. Anthropic calls memory imports experimental, warns that some memories may not be incorporated successfully and says Claude may omit personal details unrelated to work. It also documents exporting Claude memory through its memory interface or by requesting the stored text in chat.
The distinction matters: copyable text is useful portability, but it is not automatically a complete, structured transfer of provenance, permissions, timestamps and decision history.
For enterprise evaluation, the right question is not simply “Does export exist?” Ask what the exported material preserves—and test what the receiving system actually uses.
The valuable asset may be the decision record
Foundation Capital investors Jaya Gupta and Ashu Garg describe a more ambitious category: “decision traces.” Their argument concerns records connecting inputs, policies, exceptions, approvals and resulting actions. They distinguish these business records from a model’s internal chain of thought.
This is an investment thesis, not proof that every memory product already captures such records.
Nevertheless, it exposes an important design choice. A preference about answer formatting and a documented approval for a business exception have very different consequences if they disappear. Treating both as disposable conversational memory would be an architectural mistake.
Digital Pakistan also highlights Notion’s August shared-memory work and reports its engineers’ findings about duplicated and low-value memories. The precise percentages should not be generalized across platforms. The operational lesson is useful without them: assign responsibility for reviewing remembered information rather than assuming accumulation equals improvement.
A bigger notebook is not necessarily a better notebook. Sometimes it is just yesterday’s mistake with excellent persistence.
A practical memory-control checklist
The following is an architectural recommendation drawn from these documented differences, not a claim that every platform supplies the same controls.
1. Inventory memory separately from knowledge sources
For each agent, record:
- What it retains between interactions.
- Whether memory is personal, shared or workflow-specific.
- Where it is stored.
- Who can read, change and delete it.
- What inactivity, expiry and deletion rules apply.
- Whether export is documented and has been tested.
Keep this separate from the inventory of connected documents and business systems. Box-style permission-aware retrieval and Microsoft’s documented shared-memory behavior demonstrate why those boundaries cannot be assumed to match.
2. Keep authoritative decisions outside disposable memory
For consequential workflows, consider maintaining approvals, policy versions and exception records in a governed business system. Let an agent retrieve those records rather than relying on its conversational recollection as the only evidence.
This recommendation follows from the difference between Microsoft’s inactivity-based deletion and Foundation Capital’s concept of durable decision traces. They serve different purposes.
3. Test a migration, not a promise
Use an approved test environment and non-sensitive representative context. Move one bounded workflow to another model or platform, then compare:
- Required facts retained.
- Corrections and preferences preserved.
- Access boundaries maintained.
- Missing context and manual reconstruction effort.
- Deletion behavior in the original system.
Define success before starting. An agent producing a plausible answer is not sufficient evidence that migration preserved the information the workflow requires.
4. Ask procurement questions early
Request clear answers about usable exports, deletion confirmation, retention controls, administrator visibility and model-training use. These are evaluation questions, not universal legal requirements.
For custom systems, separately assess control of storage and the effort needed to replace retrieval or memory-processing components. Owning a database does not, by itself, prove that a replacement agent will interpret its contents correctly.
5. Give memory an accountable owner
Assign someone to review stale facts, conflicting entries, sensitive information and unsuccessful deletion or migration tests. Scale that effort to the workflow’s consequences; a formatting assistant should not require the same machinery as an agent participating in approvals.
Control matters more than the slogan
Digital Pakistan’s central warning is persuasive as a risk to investigate, not a universal verdict. Memory does not automatically become more valuable—or harder to replace—than the model. That depends on what it contains, whether it can be reconstructed and how closely it is tied to the surrounding platform.
For Microsoft administrators, the immediate task is concrete: distinguish personal from shared memory, verify the applicable retention behavior and avoid confusing an off switch with deletion. Microsoft’s documentation already demonstrates why those details matter.
The best purchasing question is therefore not “Which agent remembers the most?” It is “Can we inspect, correct, govern and move the information our business needs?”