Inside Opus · Part 5 of 13
This series follows a hypothetical supplier-invoice exception workflow. Part 4 showed design agents retrieving prior learnings before proposing edits. This article is about what governs that retrieval. Part 1, “A piece of work through Opus”, is the map.
Three facts, three different reaches
The finance team that owns the invoice workflow likes its review screens laid out a particular way, with the extracted fields on the left and the source document on the right. That is a preference of one team in one workspace.
The organization has, over several projects, settled on a reliable pattern for connecting to its finance system: a particular authentication flow, a particular way of paging through results. That is knowledge the whole organization should benefit from.
A second customer, on the same Opus platform, processes its own invoices. Nothing about its suppliers, amounts or corrections may reach the first customer’s agents.
All three are things an agent could remember. They differ in how far the memory should reach. Get the first one wrong and a team is mildly annoyed. Get the third one wrong and you have a data-isolation failure.
The requirement
Reuse is useful only when the remembered information belongs in the present context. The system therefore needs a definition of “belongs” that is explicit enough to enforce, and a way to compose, for any given agent in any given session, the set of memories that pass it.
The scope problem
Neither extreme satisfies the requirement. Session-only memory, where nothing persists beyond the current design session, cannot carry lessons into later sessions; it does not by itself establish isolation. Globally pooled memory, where everything learned anywhere is available everywhere, can cross customer and workspace boundaries and retrieve lessons where they do not apply.
Between them is scoped memory: knowledge is tagged with where it came from and who it concerns, and retrieval is filtered on both. Our design principle is that Opus should only need to be told something once per trust boundary. The phrase “per trust boundary” is the whole design.
The three-by-three matrix
Opus scopes memory along two axes.
The spatial axis is where the knowledge applies: a Workspace (a project, team space or workflow-building context), an Organization (the enterprise across its departments and teams), or the Platform (across all of Opus, as governance and privacy permit).
The actor axis is who the knowledge is about: a User, an Agent, or All actors together.
Crossing them gives nine scope combinations. Here are illustrative kinds of knowledge for each, using the invoice example where it fits. These examples describe possible learnings, not measured results.
Workspace
User: This reviewer prefers explicit approval checkpoints and flags missing regulatory steps.
Agent: The extraction agent has learned that this supplier’s invoice date is in the header and its service period is in the line-item table.
All actors: Cases in this workspace fail when the vendor ID is missing, so a pre-validation step became standard.
Organization
User: This user reviews cases across several departments and is offered the complex cross-functional ones.
Agent: The integration agent has learned the organization’s finance-system connection pattern.
All actors: A shared document-verification step helps onboarding workflows across teams and became an organizational default.
Platform
User: General guidance about review workload, such as when batching or pauses may help.
Agent: General guidance on structured prompts for clearer handoffs between agents.
All actors: General guidance on separating extraction, validation and decision into distinct stages.
Three things about the table. First, the platform row represents governed, abstract guidance for broader use. Whether a tenant’s activity may contribute to it at all is a separate question governed by its privacy configuration and contract. Abstraction alone does not guarantee that a pattern cannot be attributed to a customer; its suitability for broader use has to be assessed under those conditions. Second, the user column describes patterns about how people work; what is recorded there, and whether it is recorded at all, is governed by the customer’s privacy and HR configuration. Third, the cells are not storage buckets in a database sense; they are the scope labels that retrieval filters on. We describe these as nine dimensions of learning. I will call them nine scope combinations, which I find clearer.
Scoped memory supplies context to an invocation; retrieving that context does not itself train model weights. Optional contribution to broader guidance is distinct from ordinary workspace or organization retrieval, and neither implies permission for Opus or a model provider to train on customer data. Customer-directed fine-tuning, discussed in Part 10, and provider training are separate uses with their own applicable terms and controls.
Composing the context
When a design agent joins a room, or a runtime agent begins an invocation, it does not receive the matrix. It receives a composed memory view: the subset of knowledge that is relevant to the task and valid in its scope and permissions.
Composition works in stages. Knowledge is selected for relevance to the task. It is filtered by permission, so an agent acting for a user in one workspace sees only what that workspace, its organization and the platform permit. It is merged across scopes, so the workspace preference, the organizational integration pattern and the platform-level design guidance can all be present. And it is constrained by privacy and compliance configuration.
The result for the invoice workflow’s integration agent is a view containing the team’s layout preference, the organization’s finance-system pattern and the platform’s structural guidance, and nothing that belongs to the second customer’s scope.
Precedence, carefully stated
When memories conflict, the more specific one wins. If the organization’s default is a two-stage review and this workspace has learned that its cases need a third stage, the workspace’s learning takes precedence for this workspace. Local overrides global.
What that does and does not mean deserves a clear line. Precedence resolves conflicts between learned patterns. Memory is not designed to override a mandatory policy, and it does not grant access. Guidelines and permissions are enforced by separate mechanisms, described in Part 3 and Part 7, and memory sits underneath both.
Selective promotion
The matrix also describes how knowledge moves. A pattern learned in one workspace may be useful more broadly. The pre-validation step for missing vendor IDs, for instance, might help every workspace in the organization that processes invoices.
Promotion from a local scope to a broader one is selective. It happens only under the relevant scope and permission conditions, and only for patterns judged valuable enough. The aim is to reduce repeated instruction inside a trust boundary, not to pool everything. How a pattern earns promotion is the subject of Part 6.
The alternative, and the cost
Session-only memory can fit work that does not need learning across sessions, or policy that forbids retaining learned context. It leaves no persistent learning to retrieve or go stale. Inputs, session context and retained traces still need their own access and retention controls.
Broadly pooled memory is attractive when everything belongs to one team and the cost of an inappropriate recall is low. It makes reuse trivial.
Scoped memory sits between them and pays for its position. Retrieval has to be filtered and merged. Conflicts between scopes have to be resolved. Knowledge has a lifecycle: it can be wrong, it can go stale when the finance system changes its API, and something has to retire it. Memory represents learned patterns, not guaranteed correctness. A composed view can contain a confident, well-scoped, out-of-date belief; later reviews and execution outcomes can help surface the need to reassess it.
Next
Scope determines where knowledge may be used. It says nothing about what qualifies an observation to become knowledge in the first place. A reviewer corrects one invoice date. What has to happen before that correction helps the next case? Part 6.