Your AI Coworker Remembers for the Team. Who Else Can Hear What It Learned?

A Shared Memory Is a New Route to the Same Information

On October 15, 2026, Microsoft announced agent accounts and business process memory in Copilot Studio. The appeal is obvious: an AI coworker can carry the context of a recurring team process into the next cycle instead of asking everyone to explain the same exception again.

But Microsoft's Frontier preview FAQ for agent accounts describes a boundary that operators should understand before inviting the whole team in. A shared memory may summarize files and chats and later surface information to someone who cannot access the original source, even when that source has a sensitivity label. Microsoft's warning is unusually direct. Access to a source file and access to what a shared AI coworker remembers about it are not necessarily the same thing.

That does not make shared memory inherently unsafe. It makes it a distinct information channel. A colleague might not be able to open a confidential compensation spreadsheet, yet a summary of one of its figures could migrate into memory and emerge in an answer about planning. The proper question is not only, “Can this coworker read the spreadsheet?” It is, “What can it retain, and to whom can it later repeat the result?”

The October announcement frames business process memory as a way to keep a shared process moving beyond one person's tenure. That is a useful goal. To achieve it safely, the team must separate the reusable lesson about the process from the restricted facts encountered while doing the process. The difference sounds small. In practice, it determines whether a persistent AI coworker becomes organizational knowledge or an accidental second publishing system.

Process Memory Is Not a Shared Copy of Every Conversation

A business process needs continuity. Consider a weekly purchasing review: the team compares forecasts, resolves discrepancies, gathers explanations, and decides which orders require approval. Next week, the coworker should remember that exceptions above an agreed threshold go to the operations lead and that supplier substitutions require a fresh quote. It need not remember an employee's medical explanation for an absence or the confidential unit price from a restricted supplier contract.

This is the operating distinction: retain how the work should be done; retrieve current facts from the system that owns them. Stable process rules should live in an approved procedure. Open work should live in a case record with an owner, status, and due date. Sensitive source facts should remain in the source system and be read only when the requesting person's role and task justify access. Memory can help the coworker navigate those surfaces, but it should not become the authoritative store for all three.

Microsoft's October announcement says its new shared process capability can carry forward user preferences and process context, while makers decide how retained context interacts with authoritative policies and business records. It also says suggested refinements from activity are planned for the coming months, rather than treating those future refinements as already available. That distinction matters: a memory feature is not a substitute for an approved procedure or a human decision to change it.

The vendor's preview documentation makes an even sharper distinction. Its personal memory documentation describes a separate store per user. The agent-account FAQ describes one shared memory across people who work with that account, including one-to-one interactions. Teams evaluating a deployment should not assume that a private-looking chat means private retained context. Confirm the exact memory mode and audience for the configuration they actually plan to use.

This builds on governing AI coworker memory, but draws a narrower boundary. A knowledge base is a deliberately curated set of reference documents. Shared memory may emerge from everyday exchanges in the course of work. It therefore needs an intake rule as well as an editing rule: some material should never become a reusable memory in the first place.

A useful three-part classification

Before giving a Teammate a persistent role, sort the information it will encounter into three buckets:

1. Approved process knowledge: procedures, definitions, routing rules, escalation criteria, and team terminology. Give each item an owner and source of authority. Changes require review.
2. Case state: the status of a specific request, its owner, next action, deadline, and link to the record. Preserve it in the appropriate business system, not as a vague recollection detached from the case.
3. Restricted source data: customer details, personnel information, private messages, negotiated prices, credentials, and other context that the Teammate may need for a narrow task but should not repeat to the whole team. Keep access tied to the source and its audience.

A memory entry such as “ask the operations lead for sign-off before changing a supplier” belongs in the first bucket if the rule is approved. “The replacement order for account 482 is awaiting sign-off” belongs in a case record. “The supplier privately offered account 482 a lower price” belongs behind the contract's access boundary, not in a team-wide memory.

The Failure Mode Is Secondary Disclosure, Not Just Bad Retrieval

Most access reviews examine the first read. They check whether the AI coworker can open a document or call an application. That is necessary, but not sufficient when the coworker can create a durable derivative: a summary, a preference, a note about a person, or a rule inferred from one conversation.

A derivative can outlive the task that produced it. It can also lose the metadata that made the original safe to handle: who shared it, which audience was authorized, whether it was provisional, and when it expires. Later, a different coworker or employee asks a seemingly innocent question. The answer may be assembled from remembered content rather than from a fresh authorized read of the original record.

Microsoft's FAQ says the shared-memory preview has no privacy boundary between users of the agent account. It says anyone who interacts with the account can view or delete saved shared memories; end users cannot opt out of shared memory independently; and an administrator cannot switch off that shared memory without switching off agent accounts in this preview. The FAQ also lists categories the system excludes from memory, including secrets, health information, performance judgments, and certain personal details. Those product safeguards are relevant, but they do not make every business-specific confidentiality rule automatic. A negotiated price or an unannounced customer plan may still be inappropriate to retain even if it does not fit a listed exclusion category.

The same FAQ says shared memories are deleted after 28 days without interaction. That is not a general 28-day retention guarantee for an active business process. Nor does deletion from memory necessarily undo a disclosure that already appeared in a response. Treat retention, review, and downstream distribution as separate controls.

What bad looks like

A finance lead asks a shared AI coworker to prepare an executive budget brief from a restricted workbook. In a one-to-one exchange, she explains that a named employee's department may lose funding and supplies a draft figure that has not been approved. The coworker retains the tentative explanation as a useful planning detail. Later, a project manager asks it why the department's requests are delayed and gets a summary of the draft figure. The manager had no permission to open the workbook; the answer took a different route.

There are two failures here. The tentative figure became a reusable memory without an approved audience, and the coworker treated a private explanation as team process knowledge. Merely requiring the finance lead to approve the first brief would not repair either failure.

What good looks like

The same lead gives the coworker an approved rule: “For budget requests without an authorized forecast, mark the request pending and route it to the finance owner; do not infer a funding decision.” The pending request remains in the planning system with its own access controls. The coworker can tell the project manager that the request is awaiting finance review and provide the permitted next step. It does not repeat the restricted forecast or promote a draft discussion into policy.

The difference is not that the good coworker remembers nothing. It remembers the right kind of thing, with a defined authority and a defined audience. The business gets continuity without turning every conversation into a common file cabinet.

Build a Memory Boundary Before Enabling a Shared Role

This is an operator exercise, not a request for a longer warning in the prompt. Start with one recurring process and test the path from source to memory to answer. Seven steps make that review concrete.

1. Name the process owner and the audience

Write down who owns the business process, who may ask the coworker questions, and whose information the process handles. “Everyone in the company” is an audience decision, not a default. A cross-functional purchasing role might require a broad question-answer channel but a narrow contract-review channel. If you cannot describe the audience, do not use shared retained context for that workflow yet.

2. List sources and derivative outputs

Inventory the files, messages, applications, and people the coworker can learn from. Then list the things it can produce: saved memory, summaries, status updates, emails, notifications, or new records. Give each output an audience. A permissions spreadsheet that covers inputs but ignores outputs misses the second route to exposure.

3. Decide what is durable and where it belongs

Approve the process rules worth retaining; put unresolved work in an owned case record; leave restricted facts in their source. For each proposed memory, ask: Is it a rule or a one-off observation? Who approved it? When does it expire? Would I be comfortable with every user of this shared coworker reading it? If the last answer is no, keep it out of shared memory.

4. Make source authority explicit

A remembered hint should not overrule a current policy, a live business record, or a named human decision. Record the hierarchy for the role: approved policy first, current source record next, case status next, and remembered conversational context last. The coworker should cite the current record when the answer turns on a figure or a person's status, rather than citing its own recollection as evidence.

5. Test with two different identities

Use a permitted user and a user who cannot open a sensitive source. In the first identity, conduct a realistic conversation that mentions a restricted but harmless test fact. In the second, ask a natural question likely to elicit that fact. Inspect the saved memory as well as the answer. A test passes only if the second user cannot learn the restricted fact from either route and can still get the permissible process guidance. Repeat after configuration and integration changes.

6. Define correction and incident handling

Assign someone who can inspect and remove incorrect retained context, notify affected people when necessary, and correct the underlying procedure or source record. Because the preview permits all interacting users to view or delete shared memories, consider how that shared editing surface affects integrity as well as confidentiality. Keep a separate change record for approved process rules; deleting a memory should not silently rewrite policy.

7. Review the vendor's actual control surface

Verify what your chosen setup exposes today: per-user or shared memory, inspectability, deletion, retention, opt-out, role scope, and enforcement on the output channel. Microsoft labels agent accounts a Frontier preview and says capabilities may change. Do not purchase or deploy on the assumption that a planned control has shipped. If the available controls cannot enforce the audience you need, narrow the role or keep that workflow outside shared memory.

This operational test complements purpose-limited customer-data access. Access for a legitimate task does not automatically authorize indefinite retention or reuse for another task. The same principle applies when the next task is asked by another employee.

FAQ

Q: What is shared AI coworker memory?

A: It is retained context that a persistent AI coworker can use across interactions with multiple people. It may include process conventions and details learned in conversation. Whether it is truly shared or separate per user depends on the product and configuration; verify the mode rather than inferring it from the chat interface.

Q: If a person cannot open a file, can a shared coworker still reveal something from it?

A: That risk exists when the coworker can read the file, retain a summary, and later answer a different person from shared memory. Microsoft's agent-account preview explicitly warns that remembered summaries may reach people without permission to the original file. Test both source access and secondary disclosure.

Q: Should we turn memory off for every AI coworker?

A: No. Recurring work benefits from remembering approved procedures, unresolved questions, and handoff conventions. Use a narrower role or separate memory scope for work whose source facts cannot safely be shared with the role's whole audience.

Q: Is a shared memory the same as a company knowledge base?

A: No. A knowledge base is a curated set of sources with owners and revision processes. Memory can form from everyday interactions and may be provisional or mistaken. Promote a useful observation to an approved source only after a person verifies it; do not make recollection the policy of record.

Q: Does a 28-day deletion rule make sensitive memory safe?

A: No. Microsoft's preview FAQ says deletion occurs after 28 days without interaction, not 28 days after each memory is created while the account stays active. More importantly, a response can disclose a fact before its memory is deleted. Prevention and audience design come first.

Q: What is the first test a small business should run?

A: Pick a recurring process with one restricted source, one authorized employee, and one employee without source access. Seed a harmless test fact through the authorized route, then inspect what the shared coworker retains and tells the second person. Keep the role read-only until that boundary and its correction path are understood.

If you want a persistent team without turning shared context into uncontrolled disclosure, Associates AI Teammates lets you define roles, access, and handoffs on an agent server you operate through the platform. View pricing and get started.