On August 25, Anthropic shipped a memory update that makes Claude's memory work across both chat and Cowork sessions, per reporting from Engadget and TechCrunch. SiliconANGLE covered the same release as adding customization and protections around sensitive topics. TechCrunch's headline framing is the tell: Cowork "finally remembers what you told the app in chat."
That's a small-sounding change with an unpleasant amount of design underneath it, and it's the exact wall most teams building memory hit in month three.
Per-surface memory isn't memory
If you've shipped a chat assistant and an agentic surface separately, you almost certainly built two memory stores, because the write paths look nothing alike. Chat memory is cheap to extract: turns are short, user-authored, and mostly declarative — preferences, project names, constraints. Agent-session memory is the opposite. A long autonomous run produces thousands of tokens of tool output, intermediate reasoning, and dead ends, and almost none of it is a durable fact about the user. Naively running the same extractor over both floods the store with transient artifacts: file paths from one repo, an API error that got fixed, a hypothesis the agent abandoned.
So unifying the two surfaces isn't a database merge. It's a write-policy problem. You need a classifier or heuristic that distinguishes *stable user state* from *episode state*, and you need episode state to expire or stay bound to its task. The teams that skip this ship a system that gets worse the more it's used.
Sensitive topics is a write-time decision, not a filter
The "protect sensitive topics" element matters more than it reads. There are two places to enforce it: suppress at retrieval, or never persist in the first place. Retrieval-side filtering is far easier to build and far weaker — the data is still in the store, still in backups, still in whatever gets exported under a subpoena or a DSAR. Write-side exclusion means running classification before persistence, on every candidate memory, at write latency, and accepting that you'll silently drop things a user might have wanted kept.
For anyone building this in an enterprise context, that's the decision to make explicitly and document. Users will eventually ask what the system remembers about them, and "we filter it at query time" is not an answer that survives a compliance review.
The plumbing note
Separately, MCP's spec cadence continues — revision 2026-07-28 landed after a release candidate posted the same day, and the roadmap page has seen updates in the past week. If you maintain connectors, the practical read is that spec churn is now regular enough to warrant version pinning in your server implementations rather than tracking head.
Who should care: if you're building memory for a product with more than one surface — chat, IDE, agent runner, browser extension — decide now whether they share a store, and what each is permitted to write into it. Retrofitting that boundary later is a migration, not a feature.