Summary
Three facts — a team’s screen-layout preference, an organization’s finance-system connection pattern, and another customer’s invoice data — are all things an agent could remember, and they differ in how far the memory should reach; getting the first wrong annoys a team, getting the third wrong is a data-isolation failure. Neither extreme works: session-only memory carries no lessons forward and does not by itself establish isolation, while globally pooled memory can cross customer boundaries and retrieve lessons where they do not apply.
Opus scopes memory on two axes — a spatial axis of Workspace, Organization or Platform, and an actor axis of User, Agent or All actors — producing nine scope combinations, each illustrated with a plausible learning drawn from the invoice example. The article is careful about the platform row (whether a tenant contributes at all is governed by privacy configuration and contract, and abstraction alone does not guarantee non-attribution), about the user column (what is recorded about how people work is governed by privacy and HR configuration), and about the cells themselves, which are retrieval filters rather than storage buckets.
An agent never receives the matrix; it receives a composed memory view, selected for relevance, filtered by permission, merged across scopes and constrained by privacy and compliance configuration. Conflicts resolve by specificity — local overrides global — but only between learned patterns: memory is not designed to override mandatory policy and does not grant access, since guidelines and permissions are enforced separately and memory sits underneath both.
Promotion from a local scope to a broader one is selective, aiming to reduce repeated instruction within a trust boundary rather than to pool everything. The cost is filtering, merging, conflict resolution and lifecycle management, plus the honest admission that a composed view can contain a confident, well-scoped, out-of-date belief.